Re: [Unbearable] Fwd: I-D Action: draft-ietf-tokbind-ttrp-01.txt

Amos Jeffries <> Sat, 05 August 2017 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2EAD0131D70 for <>; Sat, 5 Aug 2017 09:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XsaiGkWBSTvn for <>; Sat, 5 Aug 2017 09:36:18 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 27F13131CEB for <>; Sat, 5 Aug 2017 09:36:15 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPA id 4E35C66044F for <>; Sun, 6 Aug 2017 04:36:13 +1200 (NZST)
References: <> <> <> <> <> <>
From: Amos Jeffries <>
Message-ID: <>
Date: Sun, 6 Aug 2017 04:36:12 +1200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Unbearable] Fwd: I-D Action: draft-ietf-tokbind-ttrp-01.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 05 Aug 2017 16:36:20 -0000

On 05/08/17 07:02, Vladimir Dzhuvinov wrote:
> On 04/08/17 00:14, Brian Campbell wrote:
>> I agree that standardizing the header names significantly increases the
>> likelihood that implementations will properly scrub them.
>> I'm told that this mod_token_binding module for Apache
>> <>, for example, was recently
>> updated to do the header sanitation automatically in the course of
>> processing rather than relying on configuration directives of other modules
>> to overwrite the headers. So it can't be misconfigured, at least not with
>> respect to this issue. Standardizing the header names allows and suggests
>> for the sanitation to be an implementation thing rather than a
>> configuration thing, which is a good thing.
> If the proxy implementers get on board with this, as you mention, it
> will be great. It helps that the implementations are relatively few.
> I wonder, has there been anywhere work on standardizing a header pattern
> that can only exist between a reverse proxy and a backend server?

The word I got from HTTPbis chair and seniors some years back when I 
suggested a pattern was that it was a bad idea to depend on header 
patterning. Sec-* was a necessary evil that was endured rather than 

That said; there is Sec-*, the informal Accept-* in HTTP, and the 
semi-formal Content-* in SMTP which HTTP inherits quite a few headers 
from.  So following a naming pattern is probably not as bad as formally 
defining it as a reserved pattern.

In other areas, the ESI architecture defines several headers all 
prefixed Surrogate-* for use exclusively between origin and reverse 
proxy. <>