Re: draft-ray-tls-encrypted-handshake-00.txt
Marsh Ray <marsh <at> extendedsubset.com>
2012-05-16 22:08:41 GMT
On 05/16/2012 03:52 PM, Eric Rescorla wrote:
> On Wed, May 16, 2012 at 1:01 PM, Nikos Mavrogiannopoulos
> <nmav <at> gnutls.org> wrote:
>>
>> 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.
>
> Why? If I'm on-path, I can just generate the same address as the client.
Yes, EH does not attempt to protect against active attacks.
Up until recently I believed that unauthenticated encryption was bad
because it was did not resist active attacks and could even lend a false
sense of security. On any given network segment, an active attack is
usually just as practical as a passive one.
But then I considered the sheer volume of traffic flying around the net
in aggregate. Some unknowable huge amount of it is subject to
eavesdropping. But what we do know that only a very very small amount of
it will be non-consentually MitM'd.
So now I believe that converting a passive attack to a
possibly-detectable active attack can be very valuable.
>> Also SRP and PSK usernames.
>
> Neither of these are in wide use, especially on the Web (more on this shortly).
Chicken, meet egg.
Note: I am specifically not calling anyone a chicken. 
> Moreover, it's not clear that these can be bootstrapped into this framework.
> For instance, SRP requires a salt that is stored with the username, so
> you must reveal the username to the server prior to doing the key
> exchange, which means you somehow need a preexisting DH exchange
> secured by the server.
There are options for SRP, but I agree with Eric that SRP shouldn't be
the defining use case for the evolution of TLS.
>>> 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.
Have these all been merely solutions chasing nonexistent problems?
Or is there possibly some demand for something better?
>>> However, given the extremely low use of client
>>> certificates,
Chicken-egg, to some degree.
>>> 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.
Yes, EH involves some cost and it does not solve everything.
>> 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.
>
> The attacker simulates being a server which doesn't support this
> extension, and unless clients hard fail (which is problematic),
> then the client will send the certificate in the clear.
I agree with Eric, an active attack will remain possible for all
maximally interoperable TLS client applications.
Again, EH does not attempt to protect against active attacks.
> We already have a perfectly good alternative plan: do simple TLS handshake
> to establish a secure channel and then renegotiate inside that channel
> with any fancy extensions you want.
Everyone knows how much I value secure renegotiation.
But it seems that our users are speaking with their feet and saying that
the status quo is not, in fact, perfectly good.
> Note that this would have the advantage
> that it works with basically any TLS enhancement without any special
> per-enhancement engineering. The only real downsides of this
> are performance in the forms of latency and computational cost. As
> has been widely observed the computational cost of TLS relative
> to CPU power is shrinking fast, so this primarily leaves latency, which is
> principally an issue in the Web environment and even that for a relatively
> small number of servers.
I suppose web servers run by admins who value low latency are still a
minority in absolute terms. But some of these sites are pretty darn
successful (famously Amazon) and others of them are pushing TLS protocol
innovations into half the world's web browsers (Google, Mozilla).
> Since basically none of the features that you're claiming leak a lot of
> information (client certs, SRP, PSK) have significant deployment on the Web,
> this seems like classic premature optimization.
I think you're slicing it too thin.
The TLS handshake leaks a lot of metadata. So much so that people are
reluctant to trust it for user credentials, standardize new upper-level
features like NP(N), and even the talented developers behind Tor feel
the need to migrate away due to TLS's susceptibility to selective DoS.
Many of us have had the experience of looking at Wireshark and
diagnosing connectivity issues. We shouldn't be able to do this!
Useful as this may be, one of the properties of an ideal security
protocol is that it will be annoyingly difficult to analyze passively.
This means taking stuff that's now sent in the clear and moving it under
encryption. EH is an attempt to achieve that goal with minimal disruption.
- Marsh
RSS Feed