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

Amos Jeffries <squid3@treenet.co.nz> Sat, 05 August 2017 16:36 UTC

Return-Path: <squid3@treenet.co.nz>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAD0131D70 for <unbearable@ietfa.amsl.com>; Sat, 5 Aug 2017 09:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsaiGkWBSTvn for <unbearable@ietfa.amsl.com>; Sat, 5 Aug 2017 09:36:18 -0700 (PDT)
Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id 27F13131CEB for <unbearable@ietf.org>; Sat, 5 Aug 2017 09:36:15 -0700 (PDT)
Received: from [192.168.137.92] (unknown [121.98.43.66]) by treenet.co.nz (Postfix) with ESMTPA id 4E35C66044F for <unbearable@ietf.org>; Sun, 6 Aug 2017 04:36:13 +1200 (NZST)
To: unbearable@ietf.org
References: <150169636325.5791.16128248741008174399@ietfa.amsl.com> <CA+k3eCRkVoHD_QawfH4fPZJB-WtG=X_zORP0LHV7nD_54qE5Hg@mail.gmail.com> <0618fbec-ce24-d608-bab8-b1a2a24ece47@connect2id.com> <CAH9QtQGu8dxTpH14W7YVRJLbPaooBK1FR-bCPpvyAvEXqvzOBw@mail.gmail.com> <CA+k3eCRU6weja=nWSMZaBjoAgXiEy1UhCbqLVw_tM2ckJLtU3Q@mail.gmail.com> <f841c1ba-95c2-2aa5-835f-02aaff13ab93@connect2id.com>
From: Amos Jeffries <squid3@treenet.co.nz>
Message-ID: <275f8e4c-6b4b-8229-8e33-0c89b7bdd498@treenet.co.nz>
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: <f841c1ba-95c2-2aa5-835f-02aaff13ab93@connect2id.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/hJgi6WjFJLYzUCuwqhpMr2LZjDA>
Subject: Re: [Unbearable] Fwd: I-D Action: draft-ietf-tokbind-ttrp-01.txt
X-BeenThere: unbearable@ietf.org
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.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=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
>> <https://github.com/zmartzone/mod_token_binding>, 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 
encouraged.

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. <https://www.w3.org/TR/edge-arch/>

Amos