Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)

[Brian Smith <[e-mail]>]

On Wed, Dec 11, 2013 at 7:16 AM, Yoav Nir <[e-mail]> wrote:
> 2b. The server replies with TLS 1.0, and some certificate. The certificate may or may not fit the site. Makes no difference for now.
> 3b. The client completes the exchange, and immediately begins a renegotiation
> 4b. In this renegotiation, the versions offered are just TLS 1.0 to TLS 1.2, and all extensions are present (though encrypted).
> 5b. The renegotiation completes at TLS 1.0 with all extensions.
>
> This solves the issue of hiding extension. If TLS 1.3 is not supported by the server, it means an extra handshake with all associated costs. It may be possible, if the server presented the correct certificate to have session resumption with the renegotiation, although that is usually not recommended.

Thanks for trying to find a solution. However, it is not acceptable to
add any new round trips to hide information in the ClientHello, and
also we can't add whatever compatibility risk there would be in
depending on renegotiation (the compatibility issues with even initial
handshakes are a huge drain). If/when we have ~99% adoption of TLS 1.3
with encrypted ClientHello information, we could revisit this kind of
approach. But, that is several (10?) years away. Until then, we'd need
an approach that doesn't add any round trips to the handshake.

Keep in mind that if it were acceptable to add new round trips to the
handshake, we wouldn't need ALPN or NPN at all.

In fact, we don't need ALPN or NPN for the case of a 1-RTT handshake,
if we standardize a way to allow protocol-neutral prefixes of the
application data, like I showed at the end of this message:
http://www.ietf.org/mail-archive/web/tls/current/msg10888.html

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)