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

Willy Tarreau <> Fri, 27 March 2015 06:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A44571A8A4D for <>; Thu, 26 Mar 2015 23:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2QSw1uY_bulx for <>; Thu, 26 Mar 2015 23:53:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FC881A8A7C for <>; Thu, 26 Mar 2015 23:53:43 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YbO68-0003yW-Nw for; Fri, 27 Mar 2015 06:50:28 +0000
Resent-Date: Fri, 27 Mar 2015 06:50:28 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YbO5x-0003x4-ND for; Fri, 27 Mar 2015 06:50:17 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1YbO5w-0000n6-MT for; Fri, 27 Mar 2015 06:50:17 +0000
Received: (from willy@localhost) by pcw.home.local (8.14.3/8.14.3/Submit) id t2R6ndhi025614; Fri, 27 Mar 2015 07:49:39 +0100
Date: Fri, 27 Mar 2015 07:49:39 +0100
From: Willy Tarreau <>
To: Adrien de Croy <>
Cc: Mark Nottingham <>, Martin Thomson <>, HTTP Working Group <>
Message-ID: <>
References: <> <emfb77a216-c881-4ccc-b0ac-177521265d55@bodybag>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <emfb77a216-c881-4ccc-b0ac-177521265d55@bodybag>
User-Agent: Mutt/
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.0
X-W3C-Hub-Spam-Report: AWL=-2.018, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1YbO5w-0000n6-MT e95f0062fa75dd5ef331e00e62bbfbc8
Subject: Re: Working Group Last Call for draft-ietf-httpbis-tunnel-protocol
Archived-At: <>
X-Mailing-List: <> archive/latest/29035
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Fri, Mar 27, 2015 at 01:17:35AM +0000, Adrien de Croy wrote:
> Hi Mark
> thanks for explaining this position.  I guess my own reasons for my mail 
> were to dispute claims that the draft did not introduce ambiguity and 
> allowed full description of the protocol stack.
> Whether or not there is appetite for further uses of the header at the 
> current time (e.g. relating to parsing / enforcement), and whether we 
> should preclude future possible uses of it by IMO getting it so badly 
> wrong are 2 independent issues  and I would be interested in learning of 
> proposed usage of the header in its current form by middle-box vendors.
> But even aside from all that, I'm not keen on proliferation of RFCs 
> which are ambiguous, as this tends to lead to interop problems.
> I think it's a perfectly valid desire to wish to indicate what sort of 
> thing is being tunneled for purposes of choosing service levels, however 
> precluding the ability to easily verify a client assertion seems to be 
> dangerous.
> How about defining 2 headers?
> Tunnel-TLS-ALPN to be used if the next layer is TLS
> Tunnel-ALPN if it's not TLS

I've been asking as well to explicitly use the ALPN word instead of
"Protocol" to make it explicit that we were designating the protocol
transported *over* TLS so that we could keep "Tunnel-Protocol" for
later purposes (eg: I don't think that TLS has its own ALPN identifier).

Please Martin, as you can see, the name "Tunnel-Protocol" is extremely
confusing as it uses something generic to indicate something specific.
We've had a lot of confusion on HTTP in the past (eg: content-length
that became ambiguous with compression as it used to designate the
framing for some implementations and the original contents for others).
Let's be clear here.

I'm fine with several proposals, as long as there's the ALPN name in
the header name to indicate that whatever value is advertised must be
a valid, registered ALPN token. Mentionning TLS before as Adrien
suggests would be even better, but I guess that without it we can
still understand that ALPN being TLS-only, TLS is implied.