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

From: [email-masked]
Date: Wed, 02 Aug 2017 10:52:43 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Token Binding WG of the IETF.

        Title           : HTTPS Token Binding with TLS Terminating Reverse Proxies
        Author          : Brian Campbell
	Filename        : draft-ietf-tokbind-ttrp-01.txt
	Pages           : 10
	Date            : 2017-08-02

Abstract:
   This document defines common HTTP header fields that enable a TLS
   terminating reverse proxy to convey information about the validated
   Token Binding Message sent by the client to a backend server, which
   enables that backend server to bind, or verify the binding of,
   cookies and other security tokens to the client's Token Binding key.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-01
https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-ttrp-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-ttrp-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian Campbell <[email-masked]>
Date: Wed, 2 Aug 2017 11:59:18 -0600

Just published the -01 draft of "HTTPS Token Binding with TLS Terminating
Reverse Proxies" with the changes listed below.  Use of the "Sec-" prefix
for the header names is the only big change and I didn't want to wait long
on getting a draft out that has the new header names.

   draft-ietf-tokbind-ttrp-01
<https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-01>

   o  Prefix the header names with "Sec-" so that they are denoted as
      forbidden header names by Fetch https://fetch.spec.whatwg.org/

   o  Removed potentially confusing sentence from Security
      Considerations per
      https://mailarchive.ietf.org/arch/msg/unbearable/
<https://mailarchive.ietf.org/arch/msg/unbearable/O0IpppyyEqMrQjEkyEi8p8CeBGA>
      O0IpppyyEqMrQjEkyEi8p8CeBGA
<https://mailarchive.ietf.org/arch/msg/unbearable/O0IpppyyEqMrQjEkyEi8p8CeBGA>

   o  Editorial fixes.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Wed, Aug 2, 2017 at 11:52 AM
Subject: [Unbearable] I-D Action: draft-ietf-tokbind-ttrp-01.txt
To: [email-masked]
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Token Binding WG of the IETF.

        Title           : HTTPS Token Binding with TLS Terminating Reverse
Proxies
        Author          : Brian Campbell
        Filename        : draft-ietf-tokbind-ttrp-01.txt
        Pages           : 10
        Date            : 2017-08-02

Abstract:

_______________________________________________
Unbearable mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/unbearable

-- 
*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.*

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 3 Aug 2017 16:32:27 +0300

To me forgetting to configure scrubbing of the headers is the worst
thing that can potentially happen in a TLS terminating proxy setup.

When implementing mTLS we decided to make the header names configurable,
and insist on them having a random portion, to make them hard to guess,
e.g. X-Client-X509-Cert-alaeLuL8geiqu3OhOg1Mafa4Ecu9ahsh. The prefix was
put there to ease debugging. By doing this the header name essentially
becomes a secret, shared between the TLS proxy and the backend server.
Someone probing the TLS proxy to see if scrubbing was accidentally left
out will have a much harder job with this.

I don't know if something like that was discussed in Prague. I
understand that there's great interop value in making header names
standard. 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

---

From: Bill Cox <[email-masked]>
Date: Thu, 3 Aug 2017 08:31:17 -0700

On Thu, Aug 3, 2017 at 6:32 AM, Vladimir Dzhuvinov <[email-masked]>
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

---

From: John Bradley <[email-masked]>
Date: Thu, 3 Aug 2017 11:49:52 -0400

I think the main concern is sanitizing the Referred-Token-Binding-ID and Sec-Provided-Token-Binding-ID headers rather than the original Sec-Token-Binding header.

The concern is if the TTP is not properly configured an attacker could send the 
Referred-Token-Binding-ID and Sec-Provided-Token-Binding-ID headers directly to bypass security.

At the F2F a number of suggestions were made around how to prevent/detect misconfiguration of one of a set of TTP that is not configured to sanitize those headders.

John B

> On Aug 3, 2017, at 11:31 AM, Bill Cox <[email-masked]> wrote:
> 
> 
> 
> On Thu, Aug 3, 2017 at 6:32 AM, Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>> 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

---

From: Brian Campbell <[email-masked]>
Date: Thu, 3 Aug 2017 14:20:40 -0600

> removed?  I did that originally in an implementation, and was asked to stop

This is largely to try and comply with HTTPSTB
<https://tools.ietf.org/html/draft-ietf-tokbind-https-10> that says the
"Sec-Token-Binding" header is sent by the client when TB is negotiated on
the TLS connection.  On the connection from the TTRP to the backend, the
TTRP is the client and TB isn't negotiated (most likely anyway).

---

From: Brian Campbell <[email-masked]>
Date: Thu, 3 Aug 2017 15:14:10 -0600

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.

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
ideas.

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 <[email-masked]> wrote:

>
>
> On Thu, Aug 3, 2017 at 6:32 AM, Vladimir Dzhuvinov <
> [email-masked]> wrote:
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 4 Aug 2017 22:02:15 +0300

> 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?

> unique solution.
+1
>  If there's the will and/or appetite to develop a common

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 6 Aug 2017 04:36:12 +1200

> 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