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

> We also discussed this use of ALPN with the TLS WG, and there wasn't an objection to it.

Have a link to that thread handy?  Would be good for everyone to read for context.

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net] 
Sent: Sunday, May 3, 2015 8:28 PM
To: Erik Nygren
Cc: Mike Bishop; Ryan Hamilton; Adrien de Croy; Julian F. Reschke; Hervé Ruellan; HTTP Working Group
Subject: Re: alt-svc issue 43: ALPN identifiers in Alt-Svc

This was all discussed pretty exhaustively when we started using ALPN in H2; e.g.,
  https://github.com/http2/http2-spec/issues/422


I very much agree that we can communicate more clearly about how we're using ALPN protocol identifiers. However, we purposefully used the ALPN registry to avoid having two registries that had substantially similar content. We also discussed this use of ALPN with the TLS WG, and there wasn't an objection to it.

Cheers,


> On 2 May 2015, at 3:31 am, Erik Nygren <erik@nygren.org> wrote:
> 
> 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-extensio

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

--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 4 May 2015 17:48:54 UTC