Re: [TLS] Questions about ALPN

[Michael D'Errico <[e-mail]>]

Mark Nottingham wrote:
> On 15 Apr 2014, at 9:57 am, Michael D'Errico <[e-mail]> wrote:
> 
>> Additionally, adding a new low-level transport would break things:
>> As an example, suppose you already have defined "http/2 over TCP" and
>> "http/2 over TLS (over TCP)" and all servers recognize these code
>> points.  Now whoever wants to create "http/2 over HNTP" (hypothetical
>> new transport protocol) will need to have all http server software
>> everywhere learn the new code point whether it is aware of HNTP or not,
>> before http/2 could be used reliably over HNTP.
> 
> Why? 

Suppose that "http/2 over TCP" and "http/2 over TLS" are assigned the
code points 23 and 38 respectively (I'm just making up numbers).  A TLS
stack can be programmed to recognize both of these numbers in ALPN as
"http/2" for its purposes.

But then some time later, someone registers "http/2 over HNTP" at code
point 139.  The same TLS stack can not possibly know that protocol 139
in ALPN means http/2 without an upgrade, leading to a failure.

Also you'd then have to define "smtp over HNTP", "ftp over HNTP", etc.
for all applications that could be delivered over HNTP.  Much better to
just register one new transport code point for HNTP and you're done.

>> So instead of making this mistake, I'd like to see a single code point
>> for application protocol (e.g. http/2) which would be used by TLS in
>> ALPN and then you can combine that with another code point representing
>> the transport if you need this level of distinction ("TCP", "SCTP",
>> "UDP", "TLS over TCP", "DTLS over UDP", etc.).
> 
> That would lead people to believe that they can use HTTP over DTLS (for
> example), which isn't defined and isn't interoperable. Someone would have
> to go and write the document "how to use HTTP/2 over DTLS", and then we'd
> need a way to indicate to the peer that this is supported.

I'm not saying that every combination needs to make sense.  Keeping the
code point spaces for transport and application separate will require
many fewer registrations and allow for more robust software.

Mike