Re: [TLS] Next Protocol Negotiation 03

[Paul Hoffman <[e-mail]>]

On Nov 14, 2012, at 3:30 PM, Andrei Popov <[e-mail]> wrote:

> Here is an example active attack which could reveal the negotiated protocol:
> - MITM downgrades the cipher during TLS handshake.
> - MITM can decrypt EncryptedExtensions message and find out which application protocol has been negotiated between the server and the client.
> - Finished messages are exchanged, at which point the attack is detected and the session is aborted. But the attacker knows the application protocol that is likely to be negotiated between this server and this client in the future.

This is arguing that the EncryptedExtensions message might be misnamed, in that an active MITM who doesn't mind breaking the exchange can view it. This is similar to identity-exposing attacks in IKEv1. It's a design tradeoff.

> Negotiating in the client and server hello messages (in the clear) achieves the goal of reducing round trips. The added complexity of EncryptedExtensions does not provide much security value.

I like the current design of NPN better than negotiating in the clear (and thus giving passive MITM firewalls another place to block based on policy). It doesn't feel that EncryptedExtensions is complex and it forces an MITM who wants to know the protocol being used to become noticeable active attackers.

> In those situations where the next protocol negotiation needs to be confidential, one could use TLS renegotiation. Alternatively, the next protocol can be negotiated after exchanging Finished messages, outside of the TLS handshake.

Renegotiation adds round trips and complexity, as we have seen in this WG. "Outside of the TLS handshake" just pushes this off to layer 7 and forces a change to all application servers and clients to do the negotiation. It seems cleaner to keep this in TLS.

--Paul Hoffman