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

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:rch@google.com]
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 <adrien@qbik.com<mailto:adrien@qbik.com>> wrote:
+100



------ Original Message ------
From: "Mike Bishop" <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>>
To: "Julian Reschke" <julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>>; "Hervé Ruellan" <herve.ruellan@crf.canon.fr<mailto:herve.ruellan@crf.canon.fr>>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
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....)

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de<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