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

"Adrien de Croy" <> Mon, 30 March 2015 21:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 981271A00F6 for <>; Mon, 30 Mar 2015 14:25:26 -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 I_h-oLlT3tey for <>; Mon, 30 Mar 2015 14:25:16 -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 7120B1A00F4 for <>; Mon, 30 Mar 2015 14:25:16 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1Ych8J-00050a-TF for; Mon, 30 Mar 2015 21:22:07 +0000
Resent-Date: Mon, 30 Mar 2015 21:22:07 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1Ych8A-0004zt-VD for; Mon, 30 Mar 2015 21:21:58 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1Ych86-0001ZH-Ix for; Mon, 30 Mar 2015 21:21:58 +0000
Received: From [] (unverified []) by SMTP Server [] (WinGate SMTP Receiver v8.3.2 (Build 4772)) with SMTP id <>; Tue, 31 Mar 2015 10:20:20 +1300
From: Adrien de Croy <>
To: Martin Thomson <>
Cc: Willy Tarreau <>, Amos Jeffries <>, HTTP Working Group <>
Date: Mon, 30 Mar 2015 21:20:20 +0000
Message-Id: <em6b017b97-9da0-4262-b397-81afc1c1530e@bodybag>
In-Reply-To: <>
Reply-To: Adrien de Croy <>
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=;;
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: AWL=-0.225, BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1Ych86-0001ZH-Ix ac80ab5c18cf2e254de05ebf104eb96b
Subject: Re: Working Group Last Call for draft-ietf-httpbis-tunnel-protocol
Archived-At: <>
X-Mailing-List: <> archive/latest/29090
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

OK I understand.

seems like broken layering to me though.

For instance what do you do for foo over TLS over TLS... create fooss?  
foo over SSH becomes foosh?

So to put a protocol over TLS you need to assign another registry entry? 
  And if it can go over some other channel you need to register even 
more?  I see problems with this approach.  Software won't be updated to 
recognise these tokens.  So it will have to resort to sniffing if it 
wants to do anything with the TLS layer (like protecting against bad 

The design pattern where each layer identifies only the next layer is 
very effective and elegant.  I don't know why we would want to move away 
from that.

It's a misnomer to refer to ALPN as "next layer" negotiation then.  
Maybe I'm being confused by NPN


------ Original Message ------
From: "Martin Thomson" <>
To: "Adrien de Croy" <>
Cc: "Willy Tarreau" <>; "Amos Jeffries" <>; 
"HTTP Working Group" <>
Sent: 31/03/2015 6:58:27 a.m.
Subject: Re: Working Group Last Call for 

>On 30 March 2015 at 06:43, Adrien de Croy <> wrote:
>>  If you have a foo protocol that is used over TLS or may be used 
>>  over TCP, then if you see
>>  ALPN: foo
>>  then how does the registry help you determine if this is foo over TLS 
>>  plaintext foo, since _surely_ you don't put foos in the TLS ALPN, 
>>since the
>>  "next layer" from TLS is not foos, it is foo.
>You describe the whole thing. So 'foos' is correct. A protocol of
>foo over TLS over TCP is identified separately from foo over TCP.