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

[Brian Campbell <[e-mail]>]

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


On Sun, Mar 19, 2017 at 11:12 AM, Eric Rescorla <[e-mail]> wrote:

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

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.


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

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.
> Nit:
>    standardized approach, different implementations will will address it
>
> Duplicate will
>

Fixed in my local copy. Thanks for catching that.


>
> -Ekr
>
>
>