[messaging] The Trouble with Certificate Transparency

[Ben Laurie]

On 26 September 2014 12:34, Emre Yuce <e132740 at metu.edu.tr> wrote:
>> Date: Thu, 25 Sep 2014 12:32:11 +0100
>> From: Ben Laurie <ben at links.org>
>> To: Tao Effect <contact at taoeffect.com>
>> Cc: messaging <messaging at moderncrypto.org>
>> Subject: Re: [messaging] The Trouble with Certificate Transparency
>> Message-ID:
>>       <CAG5KPzzeWGZtqwPemB+HBG=7PPdpiT-T_Yz+DfpCBYsAD2+c9A at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> On 24 September 2014 22:15, Tao Effect <contact at taoeffect.com> wrote:
>>> On Sep 24, 2014, at 12:55 PM, elijah <elijah at riseup.net> wrote:
>>>
>>> On 09/24/2014 11:08 AM, Tao Effect wrote:
>>>
>>> I've finally taken the time to explain via diagrams and many words how
>>> undetected MITM attacks can happen with Certificate Transparency.
>>>
>>>
>>> It strikes me that you are not allowing for any distinction between a
>>> MiTM attack that happens once, and a MiTM attack that is only successful
>>> if it can be carried off from the moment a computer first contacts the
>>> internet (and carried on forever if the attacker doesn't want to be
>>> detected). What scenario do you have in mind where the latter is
>>> possible?
>>>
>>>
>>> Well, I'm primarily focusing on MITM attacks that happen more than once,
>>> and
>>> are undetected, but not in the sense that you've presented it (MITM
>>> attack
>>> 24/7 from beginning of time).
>>>
>>> A 24/7 MITM attack from birth to death simply goes undetected in all
>>> systems, and it's probably impossible to do anything about that.
>>>
>>> However, the issue with CT is as I pointed out several months ago back
>>> in
>>> May, that detection depends on successful gossip.
>>>
>>> Sure, it's possible, if the gossip succeeds, that proof of failure (not
>>> misbehavior) has occurred. The problem here is:
>>>
>>> 1. Gossip could be blocked.
>>
>> Blocking our proposed mechanism == blocking all TLS. So, it could be,
>> but it would be kind obvious...
>
> @Ben: 2 questions:
> - What happens if a client is allowed to talk to a just one specific log
> server? I mean in the case that it tries other log servers and the
> connection is blocked.
>
> - Is it defined somewhere what happens when there is a contradiction in
> the logs?

I suspect these questions are based on a misunderstanding of CT - logs
cannot be contradictory, each log is independent of the others.
Clients only need to talk to logs they see SCTs from. If they can't
talk to the log, eventually the client should take some kind of
action. Exactly what is TBD.

> @Greg: Is a similar case valid for DNSchain when DNS queries are
> blocked/manipulated or just a few pre-defined DNS servers are allowed to
> be used?
>
> Best wishes,
> Emre
>
>>
>>> 2. If Gossip isn't blocked, and you're able to prove failure... so what?
>>> What then? The RFC is rather silent on this.
>>>
>>> The blockchain, on the other hand, doesn't have problem #2.
>>>
>>> Even if MITM suddenly starts blocking all new blocks and only showing
>>> blocks
>>> it creates, the node has a giant store of accurate data that the MITM
>>> cannot
>>> modify. Not so with CT.
>>
>> Why not? If clients want to download the whole log, they can.
>>
>>> Also, if browsers contain auditors, why can't these auditors be
>>> pre-seeded with the hash of different logs at the time the browser was
>>> compiled?
>>>
>>>
>>> Sorry, what is this referring to? The post acknowledges that browsers
>>> have
>>> public keys of logs.
>>
>> If the browser has some known hash for a log, then it can detect a
>> forked log (because there cannot be a consistency proof for the fork's
>> hash).
>>
>>>
>>> Kind regards,
>>> Greg
>>>
>>> --
>>> Please do not email me anything that you are not comfortable also
>>> sharing
>>> with the NSA.
>>>
>>>
>>>
>>> -elijah
>>>
>>> _______________________________________________
>>> Messaging mailing list
>>> Messaging at moderncrypto.org
>>> https://moderncrypto.org/mailman/listinfo/messaging
>>>
>>>
>>>
>>> _______________________________________________
>>> Messaging mailing list
>>> Messaging at moderncrypto.org
>>> https://moderncrypto.org/mailman/listinfo/messaging
>>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Messaging mailing list
>> Messaging at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/messaging
>>
>>
>> ------------------------------
>>
>> End of Messaging Digest, Vol 143, Issue 1
>> *****************************************
>>
>
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging