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