Re: [TLS] Questions about ALPN

Martin Thomson <martin.thomson@gmail.com> Wed, 09 April 2014 20:04 UTC

Return-Path: <martin.thomson@gmail.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 13C4E1A01B3 for <tls@ietfa.amsl.com>; Wed, 9 Apr 2014 13:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 gRC8q2sxJRxg for <tls@ietfa.amsl.com>; Wed, 9 Apr 2014 13:04:14 -0700 (PDT)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDBB1A00DC for <tls@ietf.org>; Wed, 9 Apr 2014 13:04:13 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id t61so3000613wes.30 for <tls@ietf.org>; Wed, 09 Apr 2014 13:04:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GuhQJdIt5D8gyoeRzAvbFbYlhEFeapmQeONflLa1fL4=; b=vrz9B06dk43QcmF0ZH4sxHR8bwtfFRp48xPwP3HU5OUPIVqzaBDvhI/QHas9rw/F38 CB2AfiXyLa7VbQMjdt0HOpenqTgF01mvipzoWFSbG9q/DqJug2EwjNaWouNMHGuFEden qO8g+nqSbbfaGzcsyKYq92924rWeGoqX2+dBSm9Lz7e0Om9lfSLhC0Ei1UEIeEk0qNf0 cNqzdzw8QPQFmrCLNFcD3os9/3uImUD6fyZQweLe9bLj+wjman/twu+32rxy/5cm8ym+ inRF2uL8AzQT3Z7fpLOdL6vRZq6TaiSjlf7gu/KRMc3YwSFMoK4ssh9GA6IP04OV19sP BngA==
MIME-Version: 1.0
X-Received: by 10.180.89.211 with SMTP id bq19mr38752186wib.58.1397073853030; Wed, 09 Apr 2014 13:04:13 -0700 (PDT)
Received: by 10.227.144.132 with HTTP; Wed, 9 Apr 2014 13:04:12 -0700 (PDT)
In-Reply-To: <5c4a4616b1d34efbb85643d1f26e5410@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>
Date: Wed, 09 Apr 2014 13:04:12 -0700
Message-ID: <CABkgnnX7W8axLhhVg1wUmaUSmHZ_0F+=0ypKC=sN4utp9iD04g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uQLYOzyOh1iLV_atNDbXV0PFPIE
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:04:16 -0000

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.