Subject: Questions about ALPN

From: Mark Nottingham <[email-masked]>
Date: Mon, 14 Oct 2013 14:19:37 -0700

After our recent discussions, I went back and looked at the LC draft of ALPN:
  http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-02
and noticed a few things.

For a while now, we've been talking about using the ALPN string for more than just negotiation within TLS; possible uses include in the Upgrade "dance", in the Alt-Svc / Alternate-Protocol header, and possibly within DNS.

However, the range of characters in an ALPN string is broad; in fact, UTF-8 is only a possibility:

"""
   o  Identification Sequence: The precise set of octet values that
      identifies the protocol.  This could be the UTF-8 encoding
      [RFC3629] of the protocol name.
"""

While that's fine for TLS, it becomes problematic in other environments like HTTP headers or DNS, because encoding will be necessary.

Furthermore, there's no ABNF for other specifications to refer to.

I think the range of an ALPN protocol identifier needs to be more constrained, to make it more amenable to reuse. Alternatively, maybe the protocol identifier registry shouldn't be specified by this document; it could be delegated to the URI scheme that is in use, for example. Or, maybe the Port Number registry could be reused (as SVN has done).

In some ways, that makes more sense, since ALPN is so TLS-specific; in some of the discussions I've had, people get confused when I talk about ALPN protocol identifiers being used for non-TLS protocols.

Note that I'm not against having ALPN define this registry -- I just think we need to talk about it and understand what the consequences of doing so will be.

Also, the document pre-registers a number of values:

"""
      Protocol: HTTP/1.1
      Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")
      Specification:  http://tools.ietf.org/html/rfc2616

      Protocol: SPDY/1
      Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1")
      Specification: http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1

      Protocol: SPDY/2
      Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x32 ("spdy/2")
      Specification: http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2

      Protocol: SPDY/3
      Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3")
      Specification:  http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3
"""

The reference for HTTP/1.1 needs to be draft-ietf-httpbis-p1-messaging, and I don't think that SPDY/1 has ever been used (except for early internal testing by Mike and Roberto, perhaps). 

I'll eventually send this feedback to TLS, but wanted to bring it up here first; please discuss.

Cheers,

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

---

From: Roberto Peon <[email-masked]>
Date: Mon, 14 Oct 2013 14:48:45 -0700

SPDY/1 was never released externally, and so isn't particularly useful
except as an example.

Arguably the string used within ALPN is a subset of the form that might be
used in alt-protocol or alt-svc (there is no need to talk about ports, ips,
hosts, transports, etc. within the ALPN string-- that choice was already
made...), and so should probably be defined in a separate document from
both the HTTP or ALPN specs.

-=R

On Mon, Oct 14, 2013 at 2:19 PM, Mark Nottingham <[email-masked]> wrote:

> For a while now, we've been talking about using the ALPN string for more
> than just negotiation within TLS; possible uses include in the Upgrade
> "dance", in the Alt-Svc / Alternate-Protocol header, and possibly within
> DNS.
>
> While that's fine for TLS, it becomes problematic in other environments
> like HTTP headers or DNS, because encoding will be necessary.
>
> I think the range of an ALPN protocol identifier needs to be more
> constrained, to make it more amenable to reuse. Alternatively, maybe the
> protocol identifier registry shouldn't be specified by this document; it
> could be delegated to the URI scheme that is in use, for example. Or, maybe
> the Port Number registry could be reused (as SVN has done).
>
> In some ways, that makes more sense, since ALPN is so TLS-specific; in
> some of the discussions I've had, people get confused when I talk about
> ALPN protocol identifiers being used for non-TLS protocols.
>
> Note that I'm not against having ALPN define this registry -- I just think
> we need to talk about it and understand what the consequences of doing so
> will be.
>
>       Specification:
> http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1
>
>       Protocol: SPDY/2
>       Specification:
> http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2
>
>       Protocol: SPDY/3
>       Specification:
> http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3
> """
>
> The reference for HTTP/1.1 needs to be draft-ietf-httpbis-p1-messaging,
> and I don't think that SPDY/1 has ever been used (except for early internal
> testing by Mike and Roberto, perhaps).
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Oct 2013 17:07:50 -0700

> While that's fine for TLS, it becomes problematic in other environments like HTTP headers or DNS, because encoding will be necessary.

The question is whether you consider it a problem if ALPN can
negotiate protocols that others cannot.  Or, if you consider upgrade
to be the only place where a mechanism of this nature exists, that
those "others" might be required to perform some escaping, with all
the bugs that entails.

We're defining our strings in the ASCII range, so I didn't see a big
problem with the extra flexibility.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 15 Oct 2013 10:26:17 +0900

>        [RFC3629] of the protocol name.

I have no idea why arbitrary octet values would be needed here. If 
anybody knows, please explain.

I'm generally well known for strongly supporting UTF-8 in many places, 
but I have difficulties to see why we'd need anything but ASCII (without 
most punctuation,...) for something like protocol identifiers.

Regards,   Martin.