Questions about ALPN

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/

Received on Monday, 14 October 2013 21:20:02 UTC