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

This does seem to capture the issue.  Ideally for Alt-Svc there would be an
identifier describing the relevant parts of the stack, but with a clear
alignment (ideally 1:1?) with ALPN for protocols deployed over TLS.  Does
it make more sense to have a separate registry (with some
attempt/recommendation to align them for "over TLS over TCP" protocols), or
to just expand and alter the scope of the ALPN registry to cover more than
just TLS ?   The former seems to be making more sense as we think more
about this.


On Thu, Apr 30, 2015 at 7:21 PM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

>  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> wrote:
>
> +100
>
>
>
>
> ------ Original Message ------
> From: "Mike Bishop" <Michael.Bishop@microsoft.com>
> To: "Julian Reschke" <julian.reschke@gmx.de>; "Hervé Ruellan" <
> herve.ruellan@crf.canon.fr>
> Cc: "HTTP Working Group" <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]
> 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
>
>
>
>
>