Re: Working Group Last Call for draft-ietf-httpbis-tunnel-protocol

I think renaming to ALPN addresses a couple of issues, but still not the 
one about whether it's being used for a TLS-wrapped protocol or bare 
protocol.

The language in the draft still is explicit that it would be the same 
token inside the TLS ALPN as would be in the HTTP header.

I'm happy if we remove the ability to use this for a non-TLS-wrapped 
protocol, since that removes any ambiguity.  Otherwise presense of TLS 
should be explicitly identified.




------ Original Message ------
From: "Willy Tarreau" <w@1wt.eu>
To: "Amos Jeffries" <squid3@treenet.co.nz>
Cc: "Martin Thomson" <martin.thomson@gmail.com>; "HTTP Working Group" 
<ietf-http-wg@w3.org>
Sent: 29/03/2015 7:44:30 p.m.
Subject: Re: Working Group Last Call for 
draft-ietf-httpbis-tunnel-protocol

>On Sun, Mar 29, 2015 at 01:27:32PM +1300, Amos Jeffries wrote:
>>  On 29/03/2015 8:13 a.m., Martin Thomson wrote:
>>  > On Mar 27, 2015 10:06 PM, "Amos Jeffries" <squid3@treenet.co.nz> 
>>wrote:
>>  >> Though the header is of less interest for Squid in its current 
>>form than
>>  >> I had thought earlier.
>>  >
>>  > Maybe you can help us help you :) What specific property are you 
>>looking to
>>  > have exposed here?
>>  >
>>
>>  A quick way to identify whether the inner protocol is TLS wrapped or
>>  not, without having to register all the sub-protocols inside the TLS 
>>or
>>  to sniff the TLS handshake.
>
>Here at least the presence of the ALPN header will indicate TLS is 
>present.
>However we won't have any indication about non-TLS protocols as it 
>seems
>we both expected. But we could write a second proposal for this as 
>well.
>
>Willy
>
>

Received on Monday, 30 March 2015 03:14:00 UTC