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

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?

Thanks,

Stephan

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

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

> On 20 August 2013 12:16, Andrei Popov <Andrei.Popov@microsoft.com> 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.

+1

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls