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

"Stephan Friedl (sfriedl)" <> Thu, 22 August 2013 21:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5EFD521F9E6C for <>; Thu, 22 Aug 2013 14:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S3ZdQouIokBC for <>; Thu, 22 Aug 2013 14:19:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 72A3121F9E62 for <>; Thu, 22 Aug 2013 14:19:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4013; q=dns/txt; s=iport; t=1377206342; x=1378415942; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kZBmmz76s3zqwx/svk3ozReBJ5UyFHtMe7fLFHBsC8w=; b=gjJDacxbgokXJfz10aWYxt71Nw3SKFShzwXVPb5DN3z90XKERg4lVRrO BUxoRDRwFpQGb4rQ3FtophRqF/ZIITiNtomJA+mmLP0tdNKu8wxgddfzU eGoi39qs95GMqz0zvxiuElsyFC68BSrp3DNb+bmIHOAXLhNrcQKrrgF/A 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.89,936,1367971200"; d="scan'208";a="250675738"
Received: from ([]) by with ESMTP; 22 Aug 2013 21:19:02 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r7MLJ17Q001306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Aug 2013 21:19:01 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 16:19:01 -0500
From: "Stephan Friedl (sfriedl)" <>
To: Yoav Nir <>, Martin Thomson <>
Thread-Topic: [TLS] WGLC comments on draft-ietf-tls-applayerprotoneg-01
Thread-Index: AQHOnQaJiiNSmnaz+UqY440lb15QR5mdfoCAgABuvoCAALg6gIAAFx8AgAAQr4CAABA3gIAAFtiAgAK+wFA=
Date: Thu, 22 Aug 2013 21:19:01 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [TLS] WGLC comments on draft-ietf-tls-applayerprotoneg-01
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Aug 2013 21:19:07 -0000

If I roll up the comments I think we have settled on just about everything:

1.	We will fix the typos.
2.	We will remove the HTTP/2.0 registration.  Martin can add the registration to the IANA Considerations section of the HTTP/2.0 draft.
3.	We will leave the lower-case HTTP/1.1 protocol ID as it is.

The one open issue is the 'exp' prefix for experimental ALPN protocol IDs.  In reviewing RFC 6648, it seems to speak more directly protocol parameters and not so much to arguments supplied to those parameters.  In our case, ALPN specifies that a new parameter for the TLS protocol - "application_layer_protocol_negotiation" be entered into the IANA TLS extension registry.  The ALPN draft does not propose any experimental extensions or specify prefixes for experimental extensions.  It is fully aligned with RFC 6648 in that respect.  The registry of "Application Layer Protocol Negotiation protocol byte strings" requested from the IANA is a set of identifiers for ALPN to serve as arguments to the new extension.  Those identifiers then map to specific protocols, much the same as port numbers mapping to protocols.  It is certainly a great idea to have the ALPN protocol byte string identically match the protocol name - but that is not a requirement. 

With regard to the 'exp' prefix for ALPN protocol byte strings, RFC6648 identifies leakage of experimental protocol parameters into the protected, standardized namespace as the primary problem with 'X-' prefix notation.  I think this may be less of a problem for the ALPN opaque protocol identifiers, as they are protocol identifiers and do not map to unique features or functions within a protocol.  Interop is simple, either an implementation supports the protocol or not.  An 'exp' prefixed protocol identifier does not change the behavior of the TLS protocol, all it does it impact the identity of the service which terminates the TLS connection.  If an experimental protocol ends up being promoted to a standard, then the appropriate opaque identifier will be registered at that point.  Also, there is no recommendation in the draft against registering experimental protocols either.

I'd suggest that we leave the 'exp' namespace in the draft and add a statement urging anyone choosing to avail themselves of an 'exp' prefixed opaque protocol identifier to review RFC6648 and make sure they are doing the right thing.  The 'exp' namespace has been explicitly requested by a number of TLS working group members, so I'm hesitant to remove it without more voices calling out for its removal.

Does this sound reasonable?



-----Original Message-----
From: [] On Behalf Of Yoav Nir
Sent: Tuesday, August 20, 2013 3:36 PM
To: Martin Thomson
Subject: Re: [TLS] WGLC comments on draft-ietf-tls-applayerprotoneg-01

On Aug 20, 2013, at 11:14 PM, Martin Thomson <> wrote:

> On 20 August 2013 12:16, Andrei Popov <> wrote:
>> 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.
> Sounds like a good enough reason to keep the http/1.1 registration 
> lowercase.  Doubling up is almost guaranteed to cause more confusion 
> than a mere case shift.


TLS mailing list