Re: [TLS] WGLC comments on draft-ietf-tls-applayerprotoneg-01

Andrei Popov <Andrei.Popov@microsoft.com> Tue, 20 August 2013 19:31 UTC

Return-Path: <Andrei.Popov@microsoft.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 02DD911E8260 for <tls@ietfa.amsl.com>; Tue, 20 Aug 2013 12:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.599
X-Spam-Level:
X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
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 Uv7lpfJS9yEk for <tls@ietfa.amsl.com>; Tue, 20 Aug 2013 12:31:27 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id B995311E8153 for <tls@ietf.org>; Tue, 20 Aug 2013 12:31:27 -0700 (PDT)
Received: from BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) by BL2PR03MB196.namprd03.prod.outlook.com (10.255.230.155) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 20 Aug 2013 19:16:22 +0000
Received: from BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.159]) by BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.218]) with mapi id 15.00.0745.000; Tue, 20 Aug 2013 19:16:22 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Yoav Nir <ynir@checkpoint.com>, Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [TLS] WGLC comments on draft-ietf-tls-applayerprotoneg-01
Thread-Index: AQHOnQaaN1TNnQyJLEe2jldO/oM6xJmdHa2AgAB7v4CAALg6gIAAFx8AgAAF99A=
Date: Tue, 20 Aug 2013 19:16:21 +0000
Message-ID: <073b3285216c4e7b8879cd9cefc4c423@BL2PR03MB194.namprd03.prod.outlook.com>
References: <CABkgnnXUwLQnVNt19Advb3s7ZGoc_Mrmr7AodigxZKyEZmPYwg@mail.gmail.com> <3651ef9088a147dd8e8d887f769a9538@BL2PR03MB194.namprd03.prod.outlook.com> <48F1B141-16C5-448E-887F-6D91E7535A2D@checkpoint.com> <CABkgnnXC9r8Son7TgAtp=oOBb9Je7_=9Fwnfv=v_VgeSRhyeDA@mail.gmail.com> <42699D1B-62E4-4E90-BF35-2C56A7520403@checkpoint.com>
In-Reply-To: <42699D1B-62E4-4E90-BF35-2C56A7520403@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:ed31::2]
x-forefront-prvs: 09443CAA7E
x-forefront-antispam-report: SFV:NSPM; SFS:(52314003)(13464003)(377454003)(189002)(199002)(24454002)(51704005)(74876001)(69226001)(56776001)(53806001)(4396001)(81542001)(74316001)(31966008)(74662001)(80976001)(81342001)(47446002)(76482001)(81816001)(74706001)(54316002)(74502001)(50986001)(77096001)(56816003)(63696002)(54356001)(59766001)(74366001)(77982001)(51856001)(83322001)(76576001)(46102001)(65816001)(79102001)(49866001)(33646001)(47736001)(80022001)(19580395003)(19580405001)(76796001)(81686001)(47976001)(76786001)(83072001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB196; H:BL2PR03MB194.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::2; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 03
X-MS-Exchange-CrossPremises-AuthSource: BL2PR03MB194.namprd03.prod.outlook.com
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-BCC:
X-MS-Exchange-CrossPremises-originalclientipaddress: 2001:4898:80e8:ed31::2
X-MS-Exchange-CrossPremises-avstamp-service: 1.0
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0;
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1
X-OrganizationHeadersPreserved: BL2PR03MB196.namprd03.prod.outlook.com
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] WGLC comments on draft-ietf-tls-applayerprotoneg-01
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: Tue, 20 Aug 2013 19:31:33 -0000

The convenience of harmonizing the HTTP/1.1 protocol ID is clear to me. Unfortunately, the current lower-case ID is already used, e.g. by MS clients and Google servers. We could add an alternative, upper-case version of the ID in the draft, but in practice the lower-case version will remain deployed/supported for years to come. I doubt that the benefits of "harmonization" would outweigh the resulting confusion and the extra bytes in the ClientHello, so perhaps it's better to keep the existing lower-case HTTP/1.1 protocol ID.

-----Original Message-----
From: Yoav Nir [mailto:ynir@checkpoint.com] 
Sent: Tuesday, August 20, 2013 11:17 AM
To: Martin Thomson
Cc: Andrei Popov; tls@ietf.org
Subject: Re: [TLS] WGLC comments on draft-ietf-tls-applayerprotoneg-01


On Aug 20, 2013, at 7:53 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 19 August 2013 22:54, Yoav Nir <ynir@checkpoint.com> wrote:
>> It's not meant to be displayed to the end user, as in my mother surfing the web. But it's nice to be able to see a recognizable string in Wireshark. So yes, keep HTTP/1.1 (and HTTP/2.0). SPDY, however, should be experimental or some such. There's no reason to keep it in the registry forever, or place it in the registry in the first place.
> 
> I have no trouble keeping "HTTP/1.1".  I do have a concern that the 
> string "http/1.1" will cause confusion though.  Is it really so 
> difficult to register an uppercase string?

Well, uppercase letters tend to be bigger, which may be an issue for constrained devices.

+1 on harmonizing with the string we all know and love.

>> I agree with the RFC. I prefer a private space that has an "owner".
> 
> Rather than inventing a new semantic-free, structured identifier 
> space, which the RFC in question specifically recommends against, why 
> don't we just do what RFC 6648 recommends and create a registry.
> Registration is cheap.  And if you feel the urge to experiment without 
> registering your codepoint, that's cool too.

This tends to make registries fill up with failed and obsoleted experiments. For example, if all goes well, there will be no need to ever again use "spdy/1", "spdy/2", and "spdy/3" in a year or so from now. "spdy/1" and "spdy/2" can probably already be pulled out of the proposed initial assignment. But there is never a procedure to remove stuff from registries.

Anyway, registration is cheap or not based on policy. I've just noticed that this draft does not specify an IANA policy (RFC 5226). So I propose that the following sentence be added to section 6: "The assignment policy for this new registry shall be 'First Come, First Served'." 

Yoav