Subject: Re: [TLS] ALPN or NPN ?

From: Peter Gutmann <[email-masked]>
Date: Thu, 14 Mar 2013 05:10:23 +0000

Nico Williams <[email-masked]> writes:
>On Wed, Mar 13, 2013 at 1:17 PM, Xiaoyong Wu <[email-masked]> wrote:
>>> I'm not at all against NPN and the reasons behind it; I just feel a bit
>>> uncomfortable with releasing a spec with a known security issue.
>>
>> +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 can't be entirely after the Finished message.  The server at least has to
>signal willingness to negotiate an application protocol after the Finished
>message exchange, and we should not use a handshake record for it (because
>then the presence of either re-nego or app protocol nego will be obvious to
>middleboxes.

This got discussed to some extent among some TLS folks at the RSA conference a
week or so back, rather than having a specific NPN facility we should really
be thinking about a generalised mechanism to allow extensions to additionally
be specified once the handshake has entered the encrypted phase.  In other
words there's an insecure-extensions negotiation during the handshake, and a
secure-extension negotiation after the handshake has completed.  The analogy
used was STARTTLS, you negotiate any initial options before you switch to TLS,
and then renegotiate anything critical inside the TLS security envelope.  The
use of the standard extension mechanism allows them to be handled identically
to the way extensions are already done, and doesn't limit things to only
dealing with NPN.

Peter.