Subject: [TLS] Confirming consensus for ALPN

From: Eric Rescorla <[email-masked]>
Date: Fri, 15 Mar 2013 14:45:40 -0700

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]

---

From: Mohamad Badra <[email-masked]>
Date: Sat, 16 Mar 2013 02:10:16 +0400

Hi,

It is still not clear totally clear to me, is ALPN designed to:

(a) multiplex several application data over a single TLS session, or
(b) negotiate the use of an application level protocol on port 443 (to
mainly to avoid firewall)?

Best regards,
Badra

On Sat, Mar 16, 2013 at 1:45 AM, Eric Rescorla <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Sat, 16 Mar 2013 00:31:29 +0200

On 16.3.2013, at 0.10, Mohamad Badra <[email-masked]> wrote:
> (b) negotiate the use of an application level protocol on port 443 (to mainly to avoid firewall)?

The discussion here might have been a bit misleading recently. My understanding is that the main goal of ALPN is the same as with NPN: allowing the use of "next-gen" HTTP versions (mainly SPDY and HTTP/2) on the same port as HTTPS, because they serve the same content anyway. So (b) would be closer.

http://tools.ietf.org/html/draft-friedl-tls-applayerprotoneg-02

Juho

---

From: Mohamad Badra <[email-masked]>
Date: Sat, 16 Mar 2013 02:41:32 +0400

On Sat, Mar 16, 2013 at 2:31 AM, Juho Vähä-Herttua <[email-masked]> wrote:

> The discussion here might have been a bit misleading recently. My
> understanding is that the main goal of ALPN is the same as with NPN:
> allowing the use of "next-gen" HTTP versions (mainly SPDY and HTTP/2) on
> the same port as HTTPS, because they serve the same content anyway. So (b)
> would be closer.
>

But HTTP allows version negotiation, why should be this brought to the TLS
level?

Best regards,
Badra

---

From: Nico Williams <[email-masked]>
Date: Fri, 15 Mar 2013 17:46:29 -0500

On Fri, Mar 15, 2013 at 5:41 PM, Mohamad Badra <[email-masked]> wrote:
>> allowing the use of "next-gen" HTTP versions (mainly SPDY and HTTP/2) on the
>> same port as HTTPS, because they serve the same content anyway. So (b) would
>> be closer.
>

To save a round trip?

Nico
--

---

From: Mohamad Badra <[email-masked]>
Date: Sat, 16 Mar 2013 03:01:56 +0400

> > But HTTP allows version negotiation, why should be this brought to the
That you want to sacrifice it to avoid traffic analysis :)

I don't see how a round trip is saved here: HTTP allows their clients to
advertise the major version they support in the first request the client
send to the server (e.g. HTTP request). The server replies with the lower
of that suggested by the client and the highest supported by the server.
This version negotiation is part of HTTP request/response exchange, so
where is the saved round trip?

Badra

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Sat, 16 Mar 2013 01:02:14 +0200

On 16.3.2013, at 0.41, Mohamad Badra <[email-masked]> wrote:
> But HTTP allows version negotiation, why should be this brought to the TLS level?

SPDY usually serves HTTP content, but it is not HTTP compatible on the wire. This means HTTP version negotiation is not relevant in that case. And as Nico already said, negotiating the version on TLS level saves one extra round trip, which speeds up things.

Juho

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Sat, 16 Mar 2013 01:07:48 +0200

On 16.3.2013, at 1.01, Mohamad Badra <[email-masked]> wrote:
> I don't see how a round trip is saved here: HTTP allows their clients to advertise the major version they support in the first request the client send to the server (e.g. HTTP request). The server replies with the lower of that suggested by the client and the highest supported by the server. This version negotiation is part of HTTP request/response exchange, so where is the saved round trip?

This negotiation only works if the first request is HTTP/1.0 compliant. If the request format changes, the client has to re-send its request data on version downgrade.

Juho

---

From: Yoav Nir <[email-masked]>
Date: Fri, 15 Mar 2013 23:46:36 +0000

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

---

From: Sean Turner <[email-masked]>
Date: Sun, 17 Mar 2013 17:44:33 -0400

Hums were taken on ALPN or NPN.  After everybody chuckled about it being 
close.  I agreed with Joe that there was a discernible preference for ALPN.

I guess the next bit is where we differ.  I think a show of hands is 
just another method the WG chairs can use to determine rough consensus, 
as documented in RFC 2818.  Sure I counted 'em but just standing there 
looking at the room it was a clear 2/1 ratio for ALPN and that I'd argue 
that was rough consensus in the room.

Then, the chairs took it to the list to confirm it on the list.

spt

---

From: "Hill, Brad" <[email-masked]>
Date: Thu, 21 Mar 2013 21:41:32 +0000

I was at the meeting, but didn't speak up. I expected the "running code" part of the IETF motto would carry more weight in the vote.

NPN is here today and is right at the point where large web properties (that aren't Google) can start deploying it.  As it is linked with SPDY, it is now available in major browsers representing ~50% of market share, supported in several web servers, on at least one major web accelerator appliance, and CDNs are rolling out experimental support.

If we start over with ALPN, it will take years for the "supply chain" to get us back to the point of viability that NPN is at today.

Going forward I don't have a strong preference, but if the consensus is strong that ALPN is the technically correct way to do this, I would prefer that we do NPN as informational and make ALPN-style negotiation part of TLS 1.3, since that is the deployment timeframe most of us would realistically be facing anyway.

-Brad Hill

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Friday, March 15, 2013 2:46 PM
To: [email-masked]
Subject: [TLS] Confirming consensus for ALPN

-Ekr
[For the chairs]

---

From: Adam Langley <[email-masked]>
Date: Thu, 21 Mar 2013 19:58:56 -0400

On Thu, Mar 21, 2013 at 5:41 PM, Hill, Brad <[email-masked]> wrote:
> If we start over with ALPN, it will take years for the “supply chain” to get
> us back to the point of viability that NPN is at today.

Note that the existing NPN wasn't what I was advocating: the NPN draft
differs from the current code. The NextProtocol message changed into
an EncryptedExtensions message for one in order to be more general
etc.

Cheers

AGL