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

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

Received on Thursday, 30 April 2015 22:09:04 UTC