Subject: [Unbearable] draft-campbell-tokbind-tls-term architecture.

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Mar 2017 10:12:35 -0700

I have read this document. Comments below.

OVERALL
In S 2 you say:

   Reverse proxies MUST only add the "Token-Binding-Context" header when
   explicitly configured to do so and MUST only dispatch requests
   containing it to trusted backend servers.  Any occurrence of the
   "Token-Binding-Context" header in the request from the client MUST be
   removed or overwritten before forwarding the request.  Backend
   servers MUST only accept the "Token-Binding-Context" header when
   explicitly configured to do so and only from trusted reverse proxies.

As well as/instead of requiring proxies to sanitize, why not make it
not possible for the client to construct a valid header. One way to
do this would be to require that the header be MACed with a shared
key between the proxy and the server.

Also, I think some analysis of why this header doesn't need to be
in Sec-* would be valable. I am assuming your argument is going
to be that it's always stripped by proxies?

S 1.
Nit:
   standardized approach, different implementations will will address it

Duplicate will

-Ekr

---

From: Brian Campbell <[email-masked]>
Date: Mon, 20 Mar 2017 08:08:49 -0600

Thanks for the read, Eric. Thoughts/replies are inline below.

> key between the proxy and the server.

My thinking here was that there will typically be some kind of trust
relationship (implicit or explicit or a bit of both) in the set up of the
reverse proxy and the server - private network, mutual TLS, some other
authentication, etc., - and one that might already be doing some header
sanitation by the proxy. Having the proxy sanitize this new TB context
header seemed like the lightest weight approach to locking this new
functionality down sufficiently. And keeping the work incumbent on the
proxy as lightweight as possible/reasonable has generally been a recurring
goal.

MACing the header would also accomplish the same general security goals as
requiring proxies to sanitize. And is probably less prone to deployment or
implementation errors that inadvertently allow for abuse of the header. But
it is less lightweight and adds new cryptographic processing requirements
on the reverse proxy as well as the backend server and some more bytes to
each request. It also would bring the need for this draft to consider
algorithm agility and MTI, which can be done of course but is something I
am pretty happy to avoid.

That's my reasoning behind the current approach in the draft anyway. But if
there's some preference and/or rough consensus toward a MAC of the header,
that's certainly a viable approach the draft could take. Assuming it moves
forward as a WG item.

> to be that it's always stripped by proxies?

I suppose that would be my argument, yes. But I don't know that I'm really
inclined to argue about it. Do you see some value in having the header be
Sec- prefixed? If there's good reason to do that, I'd certainly be open to
it. This thing is just a -00 individual draft at this point.

S 1.
>    standardized approach, different implementations will will address it

Fixed in my local copy. Thanks for catching that.