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

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Aug 2013 11:04:01 -0700

I have read the draft and think that it is largely ready for
publication, though there are a few minor issues that should be
resolved regarding application strings.

(I sent some of these comments to the authors privately.)

Can I request that when you create the registry in ALPN that you do
not register HTTP/2.0?  More likely than not, ALPN will precede
HTTP/2.0 and I want to avoid having a dependency issue, particularly
if we find that we need to change the string for some reason.

I'm also a little concerned about the existence of a registration for
HTTP/1.1, particularly when that registration differs from the string
used in the protocol itself (even if only in letter case).  Have the
authors consulted the HTTPbis working group about these registrations?

The other issue is the definition of the 'exp' prefix.  RFC 6648
advises against defining such constructs.  I would prefer if this
prefix were not defined.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 19 Aug 2013 23:18:09 +0000

1. If the HTTP WG has reservations about registering an HTTP/2.0 protocol ID at this time, perhaps we should remove it from the draft. New protocol ID registrations will need to be added in the future, and HTTP/2.0 could be among them.

2. ALPN defines protocol IDs as opaque byte strings, although the currently proposed protocol IDs consist of printable characters, for easy debugging, etc. ALPN protocol IDs are not meant to be displayed to the end user. I would prefer to keep the HTTP/1.1 protocol ID registration in the draft because it makes ALPN immediately useable for negotiating HTTP and SPDY connections.

3. The experimental namespace was requested by several TLS WG participants; it would be great if they could share their opinions of RFC 6648 section 3 "Recommendations for Creators of New Parameters".

Thanks,

Andrei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Monday, August 19, 2013 11:04 AM
To: [email-masked]
Subject: [TLS] WGLC comments on draft-ietf-tls-applayerprotoneg-01

I have read the draft and think that it is largely ready for publication, though there are a few minor issues that should be resolved regarding application strings.

Can I request that when you create the registry in ALPN that you do not register HTTP/2.0?  More likely than not, ALPN will precede
HTTP/2.0 and I want to avoid having a dependency issue, particularly if we find that we need to change the string for some reason.

I'm also a little concerned about the existence of a registration for HTTP/1.1, particularly when that registration differs from the string used in the protocol itself (even if only in letter case).  Have the authors consulted the HTTPbis working group about these registrations?

The other issue is the definition of the 'exp' prefix.  RFC 6648 advises against defining such constructs.  I would prefer if this prefix were not defined.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Aug 2013 17:13:46 -0700

On 19 August 2013 16:18, Andrei Popov <[email-masked]> wrote:
> I would prefer to keep the HTTP/1.1 protocol ID registration in the draft because it makes ALPN immediately useable for negotiating HTTP and SPDY connections.

I have no problem with that.  I do worry about the fact that this is
lowercase.  HTTP/1.1 self identifies as "HTTP/1.1" (i.e., uppercase),
whereas ALPN uses "http/1.1", which will cause issues (I can say
"will" rather than "might" because that was an issue we had with the
HTTP/2.0 identification string).  Is there any reason that this is not
the same string that HTTP/1.1 uses?

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Aug 2013 05:54:33 +0000

> 1. If the HTTP WG has reservations about registering an HTTP/2.0 protocol ID at this time, perhaps we should remove it from the draft. New protocol ID registrations will need to be added in the fut…

I have no problem with having HTTP/2.0 there now, as long as we're all clear that this does not relate to draft-ietf-httpbis-http2-xx, but only to the protocol in the eventual RFC.

> 2. ALPN defines protocol IDs as opaque byte strings, although the currently proposed protocol IDs consist of printable characters, for easy debugging, etc. ALPN protocol IDs are not meant to be dis…

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.

> 3. The experimental namespace was requested by several TLS WG participants; it would be great if they could share their opinions of RFC 6648 section 3 "Recommendations for Creators of New Parameter…

I agree with the RFC. I prefer a private space that has an "owner". So we could have "Priv-GOOG-SPDY4" and "Priv-CHKP-SNX" and "Priv-MSFT-SSTP", where we don't have IANA keeping things pure and non-conflicting, but having an org name there can do. And yes, I can do a "Priv-yoavnir-foo", and hope this doesn't become an identifier for some major consulting company [1].

We also need something for IETF internal drafts, so I would recommend using the draft name including numbers (as in "draft-ietf-tls-applayerprotoneg-01"). Just reserve the names without hyphens to standards track, and require registration for those only.

Yoav

[1] http://www.yoavnir.com  (not me!)

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Aug 2013 05:54:31 +0000

Yoav

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 20 Aug 2013 10:03:00 -0400

> I have no problem with having HTTP/2.0 there now, as long as we're all clear that this does not relate to draft-ietf-httpbis-http2-xx, but only to the protocol in the eventual RFC.

I think that's asking for trouble.  Some implementations will start using it because "draft-ietf-xxxx is in last call" and then some fundamental major issue will be found and they don't interop.  If HTTP WG doesn't want it, then leave it out.  Perhaps when they publish their RFC they could include the appropriate app registration.

> 3. The experimental namespace was requested by several TLS WG participants; it would be great if they could share their opinions of RFC 6648 section 3 "Recommendations for Creators of New Parameter…

If the protocol were a DNS CName entry, then the registration is 'free'  We could drop the requirement that the actual entry exist, just make it DNS syntax. And use example.com as the private/experimental space.

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Aug 2013 15:03:02 +0000

> I think that's asking for trouble.  Some implementations will start using it because "draft-ietf-xxxx is in last call" and then some fundamental major issue will be found and they don't interop.  I…

Makes no difference if it's in the registry, or if the IANA Considerations section says "IANA is requested to allocate the string "HTTP/2.0" for the specification in this document"

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 20 Aug 2013 11:08:50 -0400

> Makes no difference if it's in the registry, or if the IANA Considerations section says "IANA is requested to allocate the string "HTTP/2.0" for the specification in this document"

Well since it makes no difference to you, and since it does seem to make a difference to the HTTP-WG, and since we can avoid a potential problem by doing it this way, then we should just leave it to the HTTP-WG to do the request.

	/r$

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Aug 2013 15:35:35 +0000

> Well since it makes no difference to you, and since it does seem to make a difference to the HTTP-WG, and since we can avoid a potential problem by doing it this way, then we should just leave it t…

Sure. But that will not stop implementers from using the label based on the IANA Considerations section in the draft (when it's in last call and all)

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Aug 2013 09:17:37 -0700

> if we find that we need to change the string for some reason.

The IETF has a checkered past when it comes to pre-assigning names to moving targets. Unless the TLS WG hears from the HTTPbis WG exactly what they want us to do (and that seems unlikely), I propose that this draft does not have any entry for any future protocol. If the HTTPbis WG wants to add to the registry before they have a finished document, they can do that themselves.

--Paul Hoffman

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Aug 2013 09:48:33 -0700

> The IETF has a checkered past when it comes to pre-assigning names to moving targets. Unless the TLS WG hears from the HTTPbis WG exactly what they want us to do (and that seems unlikely), I propos…

+1.  That's exactly the request that I made.  I think that I'm
perfectly capable of adding the necessary IANA considerations section.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Aug 2013 09:53:53 -0700

> 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, howe…

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?

> 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.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Aug 2013 18:16:38 +0000

> 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.

> 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

---

From: Andrei Popov <[email-masked]>
Date: Tue, 20 Aug 2013 19:16:21 +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:[email-masked]] 
Sent: Tuesday, August 20, 2013 11:17 AM
To: Martin Thomson
Cc: Andrei Popov; [email-masked]
Subject: Re: [TLS] WGLC comments on draft-ietf-tls-applayerprotoneg-01

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Aug 2013 13:14:23 -0700

> 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,…

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.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Aug 2013 21:36:09 +0000

> lowercase.  Doubling up is almost guaranteed to cause more confusion

+1

---

From: "Stephan Friedl (sfriedl)" <[email-masked]>
Date: Thu, 22 Aug 2013 21:19:01 +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?

Thanks,

Stephan

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

+1

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Aug 2013 15:33:31 -0700

> 3.      We will leave the lower-case HTTP/1.1 protocol ID as it is.

Sounds good.  Thanks.

> 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…

I don't think that your analysis places sufficient weight on the cost
of changing names.  The experience that lead to the publication of
6648 shows that renaming doesn't happen in practice.  In this case,
there is also a size pressure that prevents the use of multiple names
for the same thing.

The key problem with X- or exp is that both carry zero semantics, but
they tend to create name-ghettos as a result of implementations that
explicitly ignore names with these prefixes.

Keeping 'exp' would be choosing the preferences of a small few over
IETF consensus on this matter.