Subject: Re: Questions about ALPN

From: Mark Nottingham <[email-masked]>
Date: Sat, 19 Oct 2013 12:17:36 +1100

On 16/10/2013, at 9:41 AM, Andrei Popov <[email-masked]> wrote:

> Hi Mark,
>  
> SPDY and HTTP/1.1 protocol IDs are defined in the ALPN draft so that ALPN can be immediately used to negotiate the same protocols as NPN. We had originally defined an HTTP/2 protocol ID as well, but removed it from the latest versions of the draft so that the HTTPbis WG can specify the appropriate protocol ID(s).
>  
> ALPN protocol IDs are defined as opaque non-empty octet strings, which allows for a compact representation of a large number of IDs. This does not prevent the HTTPbis WG from defining US-ASCII or UTF-8 protocol IDs for use on the Web.

Hi Andrei,

I understand; just a bit uncomfortable with using a registry that allows some fields that aren't valid. When we specify the header, we'll either have to specify an encoding (which probably won't get implemented), or just say that values outside a certain range are unusable. 

Our intent is to have multiple ways to convey these ids (e.g., in DNS, in headers), which means there needs to be coordination about what syntactic limits they have. The normal place to do that is in the registry requirements. 

Of course, we can work around this with some effort; it's just odd. Are there other strong motivating use cases that require this flexibility?

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Andrei Popov <[email-masked]>
Date: Mon, 21 Oct 2013 21:03:07 +0000

While ALPN was introduced primarily to enable the negotiation of HTTP and SPDY protocol versions within the TLS handshake, the intent is for other (non-Web) applications to be able to negotiate their protocols using the same TLS extension. It is conceivable that different applications will prefer different representations of their protocol IDs. Even on this thread, I believe both US-ASCII and UTF-8 protocol IDs have been mentioned. From this perspective, having the flexibility at the TLS layer appears beneficial. Treating application protocol IDs as opaque octet strings also allows efficient protocol ID matching at the TLS layer.

Cheers,

Andrei

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Friday, October 18, 2013 6:18 PM
To: Andrei Popov
Cc: [email-masked]
Subject: Re: Questions about ALPN

Hi Andrei,

Cheers,

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 27 Oct 2013 07:30:43 +0900

On 2013/10/22 6:03, Andrei Popov wrote:
> While ALPN was introduced primarily to enable the negotiation of HTTP and SPDY protocol versions within the TLS handshake, the intent is for other (non-Web) applications to be able to negotiate their protocols using the same TLS extension. It is conceivable that different applications will prefer different representations of their protocol IDs.

Yes, If some of them, like HTTP, prefer upper-case because it has always 
been upper-case, and others prefer lower-case, that's not going to be a 
problem.

> Even on this thread, I believe both US-ASCII and UTF-8 protocol IDs have been mentioned.

I saw UTF-8 mentioned as a theoretical idea, but I didn't see any actual 
UTF-8 example. Please tell me in case I missed it.

More strongly, as I have said before, I think for *protocol* 
identifiers, UTF-8 is entirely and completely unnecessary.

> From this perspective, having the flexibility at the TLS layer appears beneficial.

Flexibility is good, too much flexibility is bad.

> Treating application protocol IDs as opaque octet strings also allows efficient protocol ID matching at the TLS layer.

There's a huge difference between *allowing* arbitrary octet strings 
(which is completely unnecessary and actually problematic if you have 
octets e.g. in the C0 range show up in displays) and *comparing* them 
octet-by-octet (which is good for efficiency).

So please fix them to say that they are limited to printable ASCII and 
are compared byte-by-byte. That will be flexible enough without being 
too flexible, and efficient on top of it.

Regards,   Martin.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 28 Oct 2013 02:24:15 +0000

While the primary motivation for ALPN is the HTTP work, it may not be the only consumer and we did not see the need to restrict the possible values.   If the work associated to HTTP wants to restrict the values that they use then that can be done within the context of that work.  Other usages would still be free to define values that are expressed in other ways.   I think this design allows for flexibility so we do not have to define an extension for each usage.  

I still don't see a reason why allowing additional representations beyond what HTTP wants to use as problematic as long as we can represent what HTTP needs.  You will still need to handle unwanted character sets since implementations may choose not to follow the specification for malicious and benign reasons. 

Cheers,

Joe

On Oct 26, 2013, at 3:30 PM, "Martin J. Dürst" <[email-masked]>
 wrote:

> Yes, If some of them, like HTTP, prefer upper-case because it has always been upper-case, and others prefer lower-case, that's not going to be a problem.
> 
> I saw UTF-8 mentioned as a theoretical idea, but I didn't see any actual UTF-8 example. Please tell me in case I missed it.
> 
> More strongly, as I have said before, I think for *protocol* identifiers, UTF-8 is entirely and completely unnecessary.
> 
> There's a huge difference between *allowing* arbitrary octet strings (which is completely unnecessary and actually problematic if you have octets e.g. in the C0 range show up in displays) and *comparing* them octet-by-octet (which is good for efficiency).
> 
> So please fix them to say that they are limited to printable ASCII and are compared byte-by-byte. That will be flexible enough without being too flexible, and efficient on top of it.
> 
> Regards,   Martin.
>

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 28 Oct 2013 17:49:55 +1300

> While the primary motivation for ALPN is the HTTP work, it may not be the only consumer and we did not see the need to restrict the possible values.   If the work associated to HTTP wants to restri…

This comparison methodology Martin is proposing has nothing HTTP-specfic 
about it. It is simply the most flexible and cross-protocol compatible 
definition you can use.

Case-insensitivity and UTF-8 which have both been put forward as 
properties of the ALPN token are in fact major *limitations* on what can 
be done. UTF-8 implies all the octet mapping between language variants 
and alphabets. Case-insensitivity implies mapping between octet case 
values even in 7-bit ASCII.

Defining it as opaque 8-bit content with octet-by-octet/byte-by-byte 
comparison is *The* most flexible definition to use by far.

> I still don't see a reason why allowing additional representations beyond what HTTP wants to use as problematic as long as we can represent what HTTP needs.  You will still need to handle unwanted…

Representations beyond what HTTP wants is not the issue. Preventing 
other non-HTTP definitions from "accidentally" mapping to the HTTP token 
*is* a problem. Going past octet-by-octet comparison to anything more 
complex introduces a potential for mapping errors and adds needless 
complexity.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Oct 2013 16:00:33 +1100

Joe,

The crux of the matter for me is that we're talking about defining parallel mechanisms that also use this registry, but have syntactic constraints -- to wit, DNS, and HTTP headers.

That means we'll need to either define an encoding mechanism to allow these theoretical non-ASCII protocol identifiers to be used, or we'll have to say that certain protocol identifiers just won't work. Neither seems like a great solution.

Let's push on it the other way, though: has anyone stated a requirement for non-ASCII protocol identifiers? We've talked about the downside of so much flexibility -- what does it buy us?

Cheers,

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 28 Oct 2013 11:32:38 +0000

> Let's push on it the other way, though: has anyone stated a requirement for non-ASCII protocol identifiers? We've talked about the downside of so much flexibility -- what does it buy us?
I am agreeing with Mark. Identifiers don't need to be anything other 
than ASCII. If somebody wants to stuff binary data in ALPN to go with 
protocol identifiers, then UTF-8 is not flexible enough.

So I would also like to see use cases for UTF-8 data which is not US-ASCII.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Oct 2013 10:29:12 -0700

> So I would also like to see use cases for UTF-8 data which is not US-ASCII.

How about a use case that is neither ASCII nor UTF-8?

There was concern raised about the overall size of the option when
there are multiple strings in the set.  Aside from changing from
16-bit lengths to 8-bit lengths (something I'd prefer, but am not
going to jump up and down over), the following was suggested.

>From any set of strings, you can create another string that acts as a
stand-in for all of the set.  That string is the output of a hash of
some canonical form of the input set (maybe sort, encode, hash).

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 28 Oct 2013 17:51:39 +0000

> some canonical form of the input set (maybe sort, encode, hash).
I am not yet sure about the hash idea yet, but if this is something that 
needs to be supported, then it is either binary or can be hex- or base64 
encoded (and then it is ASCII). Either way, the binary case needs to 
have some text in the ALPN draft.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 28 Oct 2013 17:57:15 +0000

> The crux of the matter for me is that we're talking about defining parallel mechanisms that also use this registry, but have syntactic constraints -- to wit, DNS, and HTTP headers.

[Joe] This may be part of the disconnect.   The ALPN extension was not designed to be solely used by the HTTPbis framework.   At this point I don't think it is safe to assume that everything in the registry will be relevant to HTTPbis.   Is this a problem for HTTPbis?

> Let's push on it the other way, though: has anyone stated a requirement for non-ASCII protocol identifiers? We've talked about the downside of so much flexibility -- what does it buy us?

[Joe]  So I can't think of a problem with disallowing non-ASCII characters.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 28 Oct 2013 20:51:39 +0000

The ALPN draft currently defines protocol IDs as opaque octet strings, so the hash idea would work just great with the current ALPN draft.

Cheers,

Andrei

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Monday, October 28, 2013 10:52 AM
To: Martin Thomson
Cc: Joseph Salowey (jsalowey); Andrei Popov; [email-masked]
Subject: Re: Questions about ALPN

> some canonical form of the input set (maybe sort, encode, hash).
I am not yet sure about the hash idea yet, but if this is something that needs to be supported, then it is either binary or can be hex- or base64 encoded (and then it is ASCII). Either way, the binary case needs to have some text in the ALPN draft.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 28 Oct 2013 21:12:53 +0000

Except that, as I understand the proposal Martin is referring to, it's a single hash of the (multiple) protocol IDs you support.  It very substantially changes ALPN's matching model, or at the very least adds a second layer.

-----Original Message-----
From: Andrei Popov [mailto:[email-masked]] 
Sent: Monday, October 28, 2013 1:52 PM
To: Alexey Melnikov; Martin Thomson
Cc: Joseph Salowey (jsalowey); [email-masked]
Subject: RE: Questions about ALPN

Cheers,

Andrei

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Oct 2013 14:20:03 -0700

> Except that, as I understand the proposal Martin is referring to, it's a single hash of the (multiple) protocol IDs you support.  It very substantially changes ALPN's matching model, or at the very…

The major change is that P[response] is not a strict subset of
P[request].  So, yes.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 28 Oct 2013 21:28:18 +0000

This would create problems. If the TLS layer were in the business of interpreting the contents of the protocol IDs, this would break the separation of the protocol layers (even further). Besides, if a TLS server is not aware of one of the protocol IDs hashed together by the client, the server would have no way to interpret the hashed set.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, October 28, 2013 2:20 PM
To: Mike Bishop
Cc: Andrei Popov; Alexey Melnikov; Joseph Salowey (jsalowey); [email-masked]
Subject: Re: Questions about ALPN

> Except that, as I understand the proposal Martin is referring to, it's a single hash of the (multiple) protocol IDs you support.  It very substantially changes ALPN's matching model, or at the very…

The major change is that P[response] is not a strict subset of P[request].  So, yes.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 29 Oct 2013 16:15:40 +1100

> [Joe] This may be part of the disconnect.   The ALPN extension was not designed to be solely used by the HTTPbis framework.   At this point I don't think it is safe to assume that everything in the…

Well, it's an interesting question. We need a registry that the various things can point to. If some of the contents of this registry aren't appropriate, we might need to have a separate registry. Which means that people would have to do *two* registrations, which seems like busy work.

What if you didn't have any registry at all -- what if the name space of possible ALPN tokens being used was scoped by the port in use? Just thinking out loud.

---

From: Mike Bishop <[email-masked]>
Date: Tue, 29 Oct 2013 17:45:29 +0000

HTTP(S) is allowed on any port -- 80 and 443 are used when the port's not specified, and most likely to work across intermediaries, but a URI can always specify a different port.  I would presume the same is true of any other protocol.  I don't think segregating the registry by port is going to fly very far.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 29 Oct 2013 17:58:50 +0000

If protocol ID segregation is desired, perhaps ALPN protocol IDs could be segregated by prefix, e.g. "HTTP/X" protocol IDs for Web applications.

Also, the ALPN protocol ID registry operates under the "Expert Review" policy, the idea being that expert review will prevent inappropriate registrations.