Re: [Trans] Question regarding new gossip protocols [Was: Certificate transparency on blockchains]

[Tao Effect <[e-mail]>]

> Perhaps this can be reflected in an update on the okturtles blog.

That is my intention as soon as I am clear on one more question, prompted by something Dmitry just pointed out.

>> I suspect that a smart enough attacker will be able to send native certificates back to server instead of the ones he sent to client. Or
>> am I missing something?
> 
> If the attacker fools the client with certificates, it is those
> certificates that the client wil send back to the server once
> the attacker is gone. It does not matter what the attacker do.

I am realizing that this may or may not happen, depending on which part of the TLS handshake these exchanges occur.

To illustrate:

A = server's real certificate
B = malicious MITM certificate

T1. Client receives A.
T2. Client receives B, sends back A.
T3. MITM pretends to leave, sends A. Client sends B.

At T3, if B is handled by MITM _outside and before_ the channel is encrypted by A, then the MITM can prevent the server from seeing B.

So, my question is: does your document properly take that into account and state that the data sent in 3.1.3 *must* be sent after a fully encrypted TLS connection has been established?

Scanning through it, this distinction doesn't seem to be mentioned.

Thanks,
Greg

P.S. FYI Paul, any time I CC your email I get a bounced "Undelivered Mail" response:

Final-Recipient: rfc822; [e-mail]
Original-Recipient: rfc822;[e-mail]
Action: failed
Status: 5.1.1
Remote-MTA: dns; 193.110.157.102
Diagnostic-Code: smtp; 550 5.1.1 <[e-mail]>: Recipient address
   rejected: User unknown in local recipient table

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

On Mar 27, 2015, at 12:21 PM, Paul Wouters <[e-mail]> wrote:

> On Fri, 27 Mar 2015, Dmitry Belyavsky wrote:
> 
>>      The document does say that clients MUST send the certificate chain back to servers, and that's good, because if that's
>>      the case, shouldn't that be enough on its own for servers to detect that a MITM attack occurred (after the MITM
>>      leaves)?
>> If that is so, it seems like a point worth highlighting in the document. It would completely address our concerns about CT's
>> ability to detect MITM attacks post-facto.
> 
> It is.
> 
>> I suspect that a smart enough attacker will be able to send native certificates back to server instead of the ones he sent to client. Or
>> am I missing something?
> 
> If the attacker fools the client with certificates, it is those
> certificates that the client wil send back to the server once
> the attacker is gone. It does not matter what the attacker do.
> 
> The attacker can forever keep sending whatever certificates
> to the server. Once they are no longer attacker the client,
> the client will note a different (the real!) certificate
> of the server and send its previous (attacker's) certificate
> to the server.
> 
> Perhaps this can be reflected in an update on the okturtles blog.
> 
> Paul
> 
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans