> Date: Thu, 25 Sep 2014 12:32:11 +0100
> From: Ben Laurie <[email protected]>
> To: Tao Effect <[email protected]>
> Cc: messaging <[email protected]>
> Subject: Re: [messaging] The Trouble with Certificate Transparency
> Message-ID:
>       <CAG5KPzzeWGZtqwPemB+HBG=7ppdpit-t_yz+dfpcbysad2+...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 24 September 2014 22:15, Tao Effect <[email protected]> wrote:
>> On Sep 24, 2014, at 12:55 PM, elijah <[email protected]> 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?

@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
>> [email protected]
>> https://moderncrypto.org/mailman/listinfo/messaging
>>
>>
>>
>> _______________________________________________
>> Messaging mailing list
>> [email protected]
>> https://moderncrypto.org/mailman/listinfo/messaging
>>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Messaging mailing list
> [email protected]
> https://moderncrypto.org/mailman/listinfo/messaging
>
>
> ------------------------------
>
> End of Messaging Digest, Vol 143, Issue 1
> *****************************************
>


_______________________________________________
Messaging mailing list
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging

Reply via email to