Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt

[Marsh Ray <[e-mail]>]

On 05/06/2012 03:49 AM, Mohamad Badra wrote:
>
> I was reading "no need to have an (EC)DH certificate to authenticate the
> first CCS". In that case, active attacks are possible.

Right, EH does not resist active attacks. It is possible for an active 
attacker to learn what the client or server would have sent in the 
handshake. But any such attack causes the handshake to fail in all the 
scenarios where TLS currently provides integrity protection, i.e., 
everywhere except for anon-anon DH connections or a pwned trusted root CA.

It may be possible to get better guarantees for messages that are sent 
after the Client Key Exchange or Server Key exchange (such as RFC 4680 
'Supplemental Data' messages). But some TLS implementations reportedly 
do not check these signatures until the Finished messages and many 
non-browser clients do not even look at the name on the server cert 
until the handshake is complete.

This means that the protections offered by EH to client certs is 
limited. Applications requiring serious security for the content of 
client certs should still use renegotiation.

If the client has an interest in protecting the client cert he MUST NOT 
transmit the client cert until he's fully authenticated the server. 
Generally this requires renegotiation, but many servers will not allow 
the client to initiate that.

Consequently, general purpose clients like web browsers can be tricked 
into transmitting the client cert to an active attacker. The only thing 
that can fix that is to change the client behavior to be more strict. In 
order to avoid breaking existing applications, clients can only become 
more strict if they are given positive indication to do so. Most forms 
of negotiation can be falsified by an active attacker at the point the 
client cert must be sent.

So AFAICT the only way that a client cert used by web browsers can be 
protected from active attackers is to encode a positive indication in 
the client cert itself to require such protection. This must take the 
form of an authorization mechanism defining which server identities are 
allowed to receive the plaintext client cert and how they may be 
authenticated.

If such a mechanism is ever put in place, EH may be able to optimize out 
the renegotiation. But we would have to approach that very carefully 
because the signature on the Server Key Exchange does not provide the 
same security properties as that of the server Finished.

- Marsh