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

From: Julian Reschke <[email-masked]>
Date: Thu, 30 Apr 2015 16:43:56 +0200

(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?

> 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?

Best regards, Julian

---

From: Hervé Ruellan <[email-masked]>
Date: Thu, 30 Apr 2015 17:23:25 +0200

On 04/30/2015 04:43 PM, Julian Reschke wrote:
> > 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.
>
I think we should remove the ambiguity to make clear that http/1.1 is over TLS.
>
> > 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.
>
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é

---

From: Julian Reschke <[email-masked]>
Date: Thu, 30 Apr 2015 17:33:33 +0200

> I think we should remove the ambiguity to make clear that http/1.1 is

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)

> 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

---

From: Mike Bishop <[email-masked]>
Date: Thu, 30 Apr 2015 20:48:26 +0000

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:[email-masked]] 
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:
>> > 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.
>> > The draft should resolve this ambiguity by stating that the 
>> > http/1.1 identifier is used to identify HTTP/1.1 over TLS.
>>

Looking at

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?

>> > 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.
>>

Best regards, Julian

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 30 Apr 2015 22:07:08 +0000

+100

------ Original Message ------
From: "Mike Bishop" <[email-masked]>
To: "Julian Reschke" <[email-masked]>; "Hervé Ruellan" 
<[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>
Sent: 1/05/2015 8:48:26 a.m.
Subject: 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....)
>
>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

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 30 Apr 2015 15:52:46 -0700

We should keep in mind that Alt-Svc will likely be used for protocols like
QUIC which run over UDP (and hence not TLS per-se). That would suggest to
me that the alpn ids should not be limited to protocols which need to live
inside of a TLS over TCP connection.

On Thu, Apr 30, 2015 at 3:07 PM, Adrien de Croy <[email-masked]> wrote:

> To: "Julian Reschke" <[email-masked]>; "Hervé Ruellan" <
> [email-masked]>
>> 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.
>>
>> 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....)
>>
>> <
>> http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
>> >,
>> 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?
>>

---

From: Mike Bishop <[email-masked]>
Date: Thu, 30 Apr 2015 23:21:07 +0000

No argument there – the ALPN spec defines them as being within TLS (not necessarily over TCP), though I don’t see a barrier to ALPN and DTLS off-hand, either.  We’re not bound to TCP even as currently defined.

For Alt-Svc, we’re really trying to convey a protocol stack.  The problem is that “h2” and “h2c” imply protocol stacks in a single token: HTTP/2 over TLS over TCP, or HTTP/2 over TCP.  Two different protocol stacks.  (A division in the HTTP/2 spec I still think is silly, but don’t mind me….)  “http/1.1” isn’t a protocol stack, it’s an individual protocol that might flow over TLS over TCP, or over TCP directly, or over SCTP for that matter.

The ALPN spec maps an identifier to an individual protocol; Alt-Svc needs to identify a protocol suite.  The requirements are different, and we’re creating confusion because we’re conflate the two concepts in a single registry.

From: Ryan Hamilton [mailto:[email-masked]]
Sent: Thursday, April 30, 2015 3:53 PM
To: Adrien de Croy
Cc: Mike Bishop; Julian Reschke; Hervé Ruellan; HTTP Working Group
Subject: Re: alt-svc issue 43: ALPN identifiers in Alt-Svc

We should keep in mind that Alt-Svc will likely be used for protocols like QUIC which run over UDP (and hence not TLS per-se). That would suggest to me that the alpn ids should not be limited to protocols which need to live inside of a TLS over TCP connection.

On Thu, Apr 30, 2015 at 3:07 PM, Adrien de Croy <[email-masked]<mailto:[email-masked]>> wrote:
+100

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]<mailto:[email-masked]>]
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

 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

 Best regards, Julian
 Best regards,

 Hervé

Best regards, Julian