Re: [TLS] Questions about ALPN

Andrei Popov <Andrei.Popov@microsoft.com> Wed, 09 April 2014 20:24 UTC

Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6551A01BA for <tls@ietfa.amsl.com>; Wed, 9 Apr 2014 13:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CflkxOCBOZK for <tls@ietfa.amsl.com>; Wed, 9 Apr 2014 13:23:59 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0710C1A0234 for <tls@ietf.org>; Wed, 9 Apr 2014 13:23:58 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.0.913.9; Wed, 9 Apr 2014 20:23:57 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0913.002; Wed, 9 Apr 2014 20:23:56 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [TLS] Questions about ALPN
Thread-Index: AQHPVAwD6prj8AzZTkKDdBgq+zM49ZsJcpOAgAAG2gCAAAXYgIAACgUwgAAKrgCAAAH9MIAAB3aAgAADWwCAAADc8IAACOqAgAAAgsCAAAqZAIAAAW9g
Date: Wed, 09 Apr 2014 20:23:56 +0000
Message-ID: <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com>
References: <53456D1B.1010804@alum.mit.edu> <CAL9PXLzF5AZ4WuTdCUBu3BY0BDRBj=120DnJefMd7hs-0hcU5w@mail.gmail.com> <CABkgnnUvfHUwHH-BKQjHqToao4FqzRTRhHZBw7cROFXoq1Ftiw@mail.gmail.com> <CAL9PXLw1Z-MBU0N=BWdiXW=C9rjG7pXc7zhnOdzwMUavSb-GwQ@mail.gmail.com> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <CABkgnnUPM=AQTk6y2juQoEcPksNWSTCkgPe4846FWDwm5waxPQ@mail.gmail.com> <e01a57761d5d4776968b0d26e86b44b9@BL2PR03MB419.namprd03.prod.outlook.com> <CABkgnnUSU_R2DmCjLV2FPFVX4TCfOfFEZ7ta5bVdakc3bsVkZA@mail.gmail.com> <53459638.50309@alum.mit.edu> <f6cfbd996c9c4456bcfb2fbec10f9f13@BL2PR03MB419.namprd03.prod.outlook.com> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <CABkgnnX7W8axLhhVg1wUmaUSmHZ_0F+=0ypKC=sN4utp9iD04g@mail.gmail.com>
In-Reply-To: <CABkgnnX7W8axLhhVg1wUmaUSmHZ_0F+=0ypKC=sN4utp9iD04g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e0:ee43::2]
x-forefront-prvs: 01762B0D64
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(199002)(189002)(377454003)(24454002)(76576001)(77982001)(92566001)(85852003)(80976001)(19580395003)(19580405001)(83322001)(46102001)(74662001)(31966008)(80022001)(74502001)(86362001)(83072002)(81542001)(79102001)(33646001)(76482001)(20776003)(99396002)(87936001)(74316001)(4396001)(81342001)(2656002)(50986999)(76176999)(54356999)(77096999)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:BBEDC1D5.9FC9436A.FDD111B7.2F1D8AD.20355; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OCNE-0FFd22VC7PUiQXpj6zktDE
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Questions about ALPN
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 09 Apr 2014 20:24:01 -0000

At the time when the protocol negotiation is being performed via ALPN, the choices between copper and radio, Ethernet and token ring, TCP and UDP, TLS and DTLS have already been made. At the time ALPN negotiation is in progress, it is too late to negotiate lower-level protocols. It makes sense, however, to negotiate higher-level protocols to run within the (D)TLS channel.

This is why I feel that "HTTP/2 over TLS" makes little sense specifically in the context of ALPN, and "HTTP/2 over TCP" makes even less sense in this context. Both of these protocol stack identifiers may be useful outside the context of ALPN, as you correctly explain.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Wednesday, April 9, 2014 1:04 PM
To: Andrei Popov
Cc: Paul Kyzivat; tls@ietf.org
Subject: Re: [TLS] Questions about ALPN

On 9 April 2014 12:40, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> things like "HTTP/2 over TLS" and "HTTP/2 over TCP" aren't IDs of 
> individual protocols because they describe entire stacks of protocols

A protocol that is layered on another protocol includes all the properties of that protocol in the same way that I gain all the advantages (and disadvantages) of a library when I link to it.  But that protocol presents a new API that completely subsumes the included protocol.  To the users of that protocol, they see HTTP/2 (over TCP, over IP, over 1Gb Ethernet, over copper) and that is similar, but necessarily different to HTTP/2 (over TLS, over TCP, etc...).
Therefore they can - and should - be identified differently.

It might be that we use a single identifier to refer to things that are, in all the aspects we care about, identical.  That's called generalization, and it might not always be appropriate.

The idea that X over Y and X over Z might be nice in theory, but it's rare that this abstraction isn't leaky at some level.  There are cases that we might not care to distinguish between, particularly below the IP layer, but even there the effects can be visible.  We just pretend really hard that we're properly insulated by all those layers.  Better to call X over Y = X1 and X over Z = X2 and avoid the confusion issue.