[TLS] Some missing context (was: Confirming consensus for ALPN)

Yoav Nir <ynir@checkpoint.com> Fri, 15 March 2013 23:46 UTC

From: Yoav Nir <ynir@checkpoint.com>
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: Some missing context (was: Confirming consensus for ALPN)
Thread-Index: AQHOIddUmC2U+PwnV061JDLgmuI55w==
Date: Fri, 15 Mar 2013 23:46:36 +0000
Message-ID: <E4EACC43-359D-40DF-933A-ED2DB678469A@checkpoint.com>
References: <CABcZeBOFkcW6XvFqWivn4+WSac727iNVQYBumRBmagwBRv1UXg@mail.gmail.com>
In-Reply-To: <CABcZeBOFkcW6XvFqWivn4+WSac727iNVQYBumRBmagwBRv1UXg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <3D1B9C4D4EF23F48A2D3C0E2F743B1A5@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: [TLS] Some missing context (was: Confirming consensus for ALPN)
Precedence: list

Hi

I think some of the people who were not in the room are missing the context for this decision.

Both NPN and ALPN accomplish the same thing. It is to negotiate the application level protocol that is going to run on top of TLS. Currently such negotiation is planned to distinguish between HTTP/1, HTTP/2, and draft versions of HTTP/2, but future applications may use this for other protocols (such as SSL-VPN tunneling clients)

The difference between them, is that in ALPN the client proposes a list of applications, and the server chooses - all in the clear. With NPN, the server advertises a list of applications in the clear, while the client picks one after the CCS - in an encrypted handshake record.

There is no question that adding NPN to an existing implementation of TLS requires more lines of code. 

Concerns were raised that middleware might block connections when it doesn't like the application chosen by the server in ALPN. With NPN, middleware that is not a full TLS proxy won't know just by looking at the handshake which protocol was chosen.

At the meeting there was no rough consensus for either proposal. There was, however, rough consensus that making either decision is better than not making a decision. As someone (Sean?) put it, "deciding is more important than winning". This was also the position of the proponents of both proposals. Given this, we went to an alternate means of making the decision (although one that was not described in RFC 3929) and voted. The result was 25:!2 in favor of ALPN.

There was also some discussion on the need to encrypt significant parts of the TLS handshake. This was viewed as orthogonal (no need to encrypt this particular piece of data, when other, more sensitive things are still sent in the clear) and may or may not be taken up by the group separately.

I hope this helps those who were not in the room respond to Ekr's call.

Yoav

On Mar 15, 2013, at 5:45 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> At today's TLS WG f2f meeting we had rough consensus to adopt
> ALPN as the solution to the upper-layer protocol negotiation problem
> posed to us by the HTTP WG.
> 
> if you have an opinion on this topic and were not at the meeting,
> please send a message to the mailing list and/or the chairs by
> Friday March 29.
> 
> -Ekr
> [For the chairs]

Re: [TLS] Confirming consensus for ALPN Mohamad Badra
[TLS] Confirming consensus for ALPN Eric Rescorla
Re: [TLS] Confirming consensus for ALPN Mohamad Badra
Re: [TLS] Confirming consensus for ALPN Juho Vähä-Herttua
Re: [TLS] Confirming consensus for ALPN Nico Williams
Re: [TLS] Confirming consensus for ALPN Mohamad Badra
Re: [TLS] Confirming consensus for ALPN Juho Vähä-Herttua
Re: [TLS] Confirming consensus for ALPN Juho Vähä-Herttua
[TLS] Some missing context (was: Confirming conse… Yoav Nir
Re: [TLS] Some missing context Sean Turner
Re: [TLS] Confirming consensus for ALPN Hill, Brad
Re: [TLS] Confirming consensus for ALPN Adam Langley
Re: [TLS] Confirming consensus for ALPN =JeffH
Re: [TLS] Confirming consensus for ALPN Adam Langley