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

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

Return-Path: <ynir@checkpoint.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9055221F88A3 for <tls@ietfa.amsl.com>; Fri, 15 Mar 2013 16:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.335
X-Spam-Level:
X-Spam-Status: No, score=-10.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNHezLdK2P1b for <tls@ietfa.amsl.com>; Fri, 15 Mar 2013 16:46:41 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id DF70E21F888B for <tls@ietf.org>; Fri, 15 Mar 2013 16:46:38 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2FNkaL1016753; Sat, 16 Mar 2013 01:46:37 +0200
X-CheckPoint: {5143B1EB-0-1B221DC2-2FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sat, 16 Mar 2013 01:46:36 +0200
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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.24.85]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
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)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Mar 2013 23:46:41 -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

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]