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

"Adrien de Croy" <adrien@qbik.com> Mon, 30 March 2015 03:17 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678EB1A1A15 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 29 Mar 2015 20:17:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPsytCPRQH32 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 29 Mar 2015 20:17:19 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA7D1A19F8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 29 Mar 2015 20:17:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YcQ9P-0005Vh-EH for ietf-http-wg-dist@listhub.w3.org; Mon, 30 Mar 2015 03:14:07 +0000
Resent-Date: Mon, 30 Mar 2015 03:14:07 +0000
Resent-Message-Id: <E1YcQ9P-0005Vh-EH@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <adrien@qbik.com>) id 1YcQ9I-0005Uo-Ch for ietf-http-wg@listhub.w3.org; Mon, 30 Mar 2015 03:14:00 +0000
Received: from smtp.qbik.com ([122.56.26.1]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1YcQ9G-0007fS-B1 for ietf-http-wg@w3.org; Mon, 30 Mar 2015 03:14:00 +0000
Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v8.3.2 (Build 4772)) with SMTP id <0000306450@smtp.qbik.com>; Mon, 30 Mar 2015 16:12:24 +1300
From: Adrien de Croy <adrien@qbik.com>
To: Willy Tarreau <w@1wt.eu>, Amos Jeffries <squid3@treenet.co.nz>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Date: Mon, 30 Mar 2015 03:12:24 +0000
Message-Id: <em1a9b3210-8429-480b-bede-c1013d7518eb@bodybag>
In-Reply-To: <20150329064430.GA6234@1wt.eu>
Reply-To: Adrien de Croy <adrien@qbik.com>
User-Agent: eM_Client/6.0.21372.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=122.56.26.1; envelope-from=adrien@qbik.com; helo=smtp.qbik.com
X-W3C-Hub-Spam-Status: No, score=-3.1
X-W3C-Hub-Spam-Report: AWL=-1.095, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1YcQ9G-0007fS-B1 4d9ff40579da2503569147fd9a4f29cc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Working Group Last Call for draft-ietf-httpbis-tunnel-protocol
Archived-At: <http://www.w3.org/mid/em1a9b3210-8429-480b-bede-c1013d7518eb@bodybag>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/29062
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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