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

Brian Campbell <> Thu, 03 August 2017 21:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BA7912741D for <>; Thu, 3 Aug 2017 14:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w6xyaAPUXK-T for <>; Thu, 3 Aug 2017 14:14:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D89912EC48 for <>; Thu, 3 Aug 2017 14:14:41 -0700 (PDT)
Received: by with SMTP id u185so10876278pgb.1 for <>; Thu, 03 Aug 2017 14:14:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/idcKwmV7S/Oy1ptGC/S0cDCNlKc9TAC6eus/HWDUUc=; b=LbcJJQb4bvstoSB6PiKdAlJHC+OilxuT0LpnRDvDcseoMpb9IyGFffVIbKvXaYHI2e OsRPqfZAaaxxVwHgtLtvawV6jVVR04DwG/tt5zHusHiGl2/Kt7VCNjpU91C+dXj+TtfB Bp5sJhIPPgKP2ehxp+nuQBv1JX01MIC1Q+4N8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/idcKwmV7S/Oy1ptGC/S0cDCNlKc9TAC6eus/HWDUUc=; b=XSe4lsU4vuwyCsqOm4TKJ28uUj1QWEXUPe/1GP7fQs9ny3MiiIsw1tt0ifja5vhtlM +xpVyvd4BoIY6dKfH/i71i/uB8OravVyg+RJEFI/p8J9FnG9m7XovOm1xYPdhE3Z0C0Y jhIG/ddaD7dxyuPFglKSOy7Kg4UL9aybsNdYq5Mtrp6o0sgJdXH5qDNLEtafoi8CU/km 7KYMIkSfZJn5/t2NtSpDT5T4hNzH/NLJ2Bq3VHT0kkRFobJC4L0w/Xh7nG3oPKF2OzJ7 ccxKfLTGt8ai0YtF7eHphqL+39KC7Uy+1oGJVBf0SAFqLwTCOvvSw5jYMUeF1FPi9Vlh cNNA==
X-Gm-Message-State: AIVw111OtBGf+ffiv9GzM4d/G+bw1p7VU24XzpK8OR49cJYYuG2vjwXF S1YbzcQB2YTC8rQ5kdkozSTLcAaFhquF2I8c4pBcbbq4F22iQdCEQISC9bKaHtG1gov5bnemzFI zpVjny19aEnU=
X-Received: by with SMTP id i5mr118052pfg.317.1501794880796; Thu, 03 Aug 2017 14:14:40 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 3 Aug 2017 14:14:10 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Brian Campbell <>
Date: Thu, 03 Aug 2017 15:14:10 -0600
Message-ID: <>
To: Bill Cox <>
Cc: Vladimir Dzhuvinov <>, Tokbind WG <>
Content-Type: multipart/alternative; boundary="94eb2c184714655a0e0555dfdecb"
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: Thu, 03 Aug 2017 21:14:43 -0000

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.

As John said, there were a number of suggestions in Prague and on-list
around how to prevent/detect header injection in more of a fail closed way.
Vladimir's specific idea didn't come up but there were conceptually similar

I maintain that it would be very inappropriate for this draft to define a
one-off mechanism for a backend server to detect client injection of the
headers. The potential problem of client header injection is not at all
unique to the functionality of the draft so the draft shouldn't define a
unique solution. If there's the will and/or appetite to develop a common
standardized mechanism detecting/preventing client header injection through
reverse proxies, I'd be happy to help contribute to that effort.

On Thu, Aug 3, 2017 at 9:31 AM, Bill Cox <> wrote:

> On Thu, Aug 3, 2017 at 6:32 AM, Vladimir Dzhuvinov <
>> wrote:
>> The downside of having set header names is that attacks on badly
>> configured TLS proxies become much easier to carry out. This is my concern
>> about the TTRP spec in this form.
>> Thanks,
>> Vladimir
> I think most coders adding the standard header will the RFC, and will be
> more likely to remember to scrub the header.
> One question about the spec: Why must the "sec-token-binding" header be
> removed?  I did that originally in an implementation, and was asked to stop
> "molesting the headers".
> Bill
> _______________________________________________
> Unbearable mailing list

*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*