Re: [TLS] ALPN or NPN ?

[Andrei Popov <[e-mail]>]

NPN draft (http://tools.ietf.org/id/draft-agl-tls-nextprotoneg-04.txt) says:
"  ... after a handshake has been performed for a
   given connection, renegotiations on the same connection MUST NOT
   include the "next_protocol_negotiation" extension."

So NPN extension cannot be used as part of a renegotiation on the same connection.
It looks like one can't have true confidentiality guarantees with NPN, as defined.

There is a broad spectrum of opinions in the WG regarding the need for hiding application protocol information:
- List of protocols and\or the negotiated protocol need to be truly confidential.
- It is enough to protect  application protocol data from passive MITM attack.
- Application protocol data should be visible to the network elements for optimal routing/accounting/filtering etc.

Clearly there are multiple scenarios that need to be supported. Perhaps it will be easier for all the parties involved to come to an agreement if we decouple the problem of negotiating an application protocol from the problem of making various contents of the TLS handshake confidential (or protected from passive attack, obfuscated, etc.)

There are separate proposals that address the confidentiality issue in a systemic way, such that the protection would apply not only to the application protocol data, but also the client cert, SNI information, etc. (see http://tools.ietf.org/id/draft-ray-tls-encrypted-handshake-00.txt is an example).

Cheers,

Andrei

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Daniel Kahn Gillmor
Sent: Wednesday, March 13, 2013 12:06 PM
To: Xiaoyong Wu
Cc: Paul Hoffman; Alfredo Pironti; [e-mail]
Subject: Re: [TLS] ALPN or NPN ?

On 03/13/2013 02:17 PM, Xiaoyong Wu wrote:
> +1 on this. A false sense of security is no better than no security. If we believe the NPN information is sensitive and should be protected, we should have this after the Finished message.

It's worth remembering that there is actually a practical, real-world distinction between "in the clear" and "accessible to a MITM who is willing to cause a connection handshake to fail".

Client software can at least observe that the information leaked in the latter case, and can advise the user.  (how helpful this is in the face of a malicious adversary might be hard to assess without thinking through the full user experience)

Note also that moving the NPN information after the Finished message is already possible in some sense by doing a second handshake.  Or is there some restriction on renegotiation that says you MUST not supply NPN on subsequent handshakes if it was not supplied initially?

However, moving the NPN info after the handshake means that the server won't have an opportunity to select different credentials based on the NPN info.

	--dkg