RE: alt-svc issue 43: ALPN identifiers in Alt-Svc

The ambiguity is that ALPN, by definition, refers to... something.  But no one seems quite clear what, at the moment.

First view:  ALPN, being a TLS extension, implicitly means that you're using TLS.  Having an ALPN identifier for a non-TLS protocol is nonsensical, since ALPN never comes into play if it's not with TLS.

Second view:  Since ALPN describes what protocol will be carried *inside* the TLS channel, having an ALPN identifier for any over-TLS protocol is nonsensical, unless you're double-encrypting data for some reason.  (And in that case, the contained protocol is simply TLS, and that inner flow will have its own ALPN extension describing the next layer in.)  All ALPN identifiers refer to unencrypted protocols transported in the TLS application data.

This document is the appropriate place to resolve it because this document is creating the confusion by overloading a TLS registry for something other than a TLS extension, and attempting to describe a protocol stack with a registry of individual protocols.  If it's introducing ambiguity, it needs to resolve it before being finalized.  (Or you could just create your own registry with startlingly similar initial contents....)

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Thursday, April 30, 2015 8:34 AM
To: Hervé Ruellan
Cc: HTTP Working Group
Subject: Re: alt-svc issue 43: ALPN identifiers in Alt-Svc

On 2015-04-30 17:23, Hervé Ruellan wrote:
>
> On 04/30/2015 04:43 PM, Julian Reschke wrote:
>> (see <https://github.com/httpwg/http-extensions/issues/43>)
>>
>> > ALPN identifiers from the ALPN spec have been defined in the 
>> > context of negotiating the application protocol in TLS. In this 
>> > context, they imply a layering above TLS.
>> > When used outside this context, there is an ambiguity, mainly for 
>> > the
>> > http/1.1 token: does it refer to HTTP/1.1 over TLS, or can it refer 
>> > also to HTTP/1.1 over TCP?
>> > The draft should resolve this ambiguity by stating that the 
>> > http/1.1 identifier is used to identify HTTP/1.1 over TLS.
>>
>> Right now we do not mention "http/1.1" at all. Should that change?
> I think we should remove the ambiguity to make clear that http/1.1 is 
> over TLS.

Looking at
<http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids>,
only "h2c" is marked as non-TLS.

Somewhere does the confusion come from, and what does it have to do with alt-svc right now? Is the idea to put this into alt-svc because we happen to process this doc right now, and it is somewhat related?

(I'm fine with that, but I'd like to fully understand what's going on)

>>
>> > In addition, a new identifier, h1c for example, could be defined to 
>> > identify HTTP/1.1 over cleartext TCP, in order to allow using 
>> > Alt-Svc to be used to target an HTTP/1.1 server over cleartext TCP.
>>
>> Is this a use case we want to address?
> I think there is a general sense that we should not define such an 
> identifier to instead promote the usage of TLS.
>>
>> Best regards, Julian
>>
> Best regards,
>
> Hervé

Best regards, Julian

Received on Thursday, 30 April 2015 20:48:54 UTC