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

[Nikos Mavrogiannopoulos <[e-mail]>]

On 05/16/2012 07:54 PM, Eric Rescorla wrote:


> - You can fingerprint the server actively cheaply, so hiding that
>   information from a passive attacker doesn't buy you much.


You cannot always fingerprint the server cheaply. What if the server
presents different identities depending on where you connect from? In
that case passive protection of the server credentials is an advantage.

> - Fingerprinting the client is often possible if it does
>   any HTTP at all (just based on the client's HTTP headers).
>   Moreover, the cipher suite list is one of the most
>   powerful fingerprinting tools and that lives in
>   ClientHello, not ClientHello2.
> This leaves us with SNI and the client's certificate. SNI can often be


Also SRP and PSK usernames.

> Finally, we have the client certificate. The idea of protecting the
> client certificate has been discussed many times over the years, most
> recently in Paris. However, given the extremely low use of client
> certificates, the rather significant level of changes to the
> protocol to protect it, and the fact that all the proposed changes
> are vulnerable to active attack, these proposals seem of limited
> value.


Interestingly this proposal isn't vulnerable to active attacks. The
client only sends its certificate, encrypted, after the server has
presented a signed serverkeyexchange. If the client verifies that
serverkeyexchange on reception he can be sure that the only the
legitimate server knows the key to read it.

In any case certificates, and usernames typically contain e-mails and
that makes them a prime target for eavesdropping. Thus even protection
against passive attacks is an interesting property for several
use-cases.

> I don't see that this draft has a significantly different cost/benefit
> tradeoff. It's true that it protects more than the certificate,
> but (a) it still doesn't protect against active attack (b) most
> of the data it protects can be inferred by other means and (c)
> it does a lot more damage to the TLS state machine in the process.


I believe (a) isn't true. (c) is an unfortunate side-effect and by
checking the EH protocol closely, several things could be simplified
if TLS had privacy features designed in from the beginning.

My opinion is that a redesign of TLS is needed to account for privacy
as this draft does. I see this draft being as the first steps for TLS
1.3 which should include privacy protection by default. Dismissing it
without suggesting an alternative plan seems like a step backwards for
TLS and privacy.

regards,
Nikos