Subject: [Unbearable] Comments on draft-campbell-tokbind-tls-term

From: Piotr Sikora <[email-masked]>
Date: Mon, 27 Mar 2017 14:36:12 -0500

Hey,
I'm a bit late to the party, so apologies if this was already discussed.

>   A backend server that receives a request from a trusted reverse proxy
>   containing the "Token-Binding-Context" and "Sec-Token-Binding"
>   headers decodes the Token Binding Context Message and uses its
>   content to validate the encoded Token Binding Message as described in
>   Section 2 of Token Binding over HTTP [I-D.ietf-tokbind-https] in
>   place of information that otherwise would have come from the TLS
>   connection.

What's the value of sending both to the backend server instead of
validating the Token Binding Message at the reverse proxy and passing
only Token Binding ID (in one form or another) to the backend server?
Especially, since the Token Binding Message must (should?) be
validated by the TLS terminating reverse proxy anyway.

Also, re-using "Sec-Token-Binding" header doesn't allow Token Binding
to be established between reverse proxy and backend server...
Actually, it doesn't allow TLS between reverse proxy and backend
server, since backend server should reject such connection, if Token
Binding protocol wasn't negotiated during TLS handshake.

>   The Token Binding Context Message is a byte sequence that contains
>   the concatenation of the negotiated Token Binding Protocol Version
>   and Key Parameters as well as the exported keying material (EKM) from
>   the TLS connection between the client and reverse proxy.  The first
>   two bytes are the ProtocolVersion, as defined in Section 2 of
>   [I-D.ietf-tokbind-negotiation], that the reverse proxy negotiated
>   with the client.  The third byte is the negotiated
>   TokenBindingKeyParameters (also defined in Section 2 of
>   [I-D.ietf-tokbind-negotiation]).  The remaining 32 or more bytes are
>   the EKM from the TLS connection between the client and the reverse
>   proxy, as defined in Section 3.3 of [I-D.ietf-tokbind-protocol].

Following from the previous comment, why all this information needs to
be passed to the backend server? Wouldn't base64url-encoded Token
Binding ID (or SHA256 hash of it) be good enough?

Best regards,
Piotr Sikora

---

From: Brian Campbell <[email-masked]>
Date: Wed, 29 Mar 2017 17:35:16 -0500

Hi Piotr,

Thanks for the review and comments/questions. Attempted replies are inline
below.

I hope to discuss much of this stuff in more detail tomorrow from 9am-10am
in Lugano during the ad hoc meeting I requested/announced on the list at
https://www.ietf.org/mail-archive/web/unbearable/current/msg01338.html.
Feel free to join the discussion, if you are still in Chicago and available.

> only Token Binding ID (in one form or another) to the backend server?

The intended value of this approach is to keep the reverse proxy as light
as possible. I got the sense that that was a desirable property from what
seemed like a majority of the room during the last meeting in Seoul. If we
stay with the approach, I'll add some explanation of the rational to the
document. But this might not be the 'right' approach or the preferred one.
I'm hoping to get more input and a better sense of the goals and
preferences of people tomorrow.

> validated by the TLS terminating reverse proxy anyway.

The server as a logical entity must validate the Token Binding Message. But
that doesn't mean the front end necessarily has to do it. The approach in
this -00 document enables a back end component of the server as a whole to
do the Token Binding Message validation. But the server as a logical entity
is still validating the TB message.

> to be established between reverse proxy and backend server...

That's true. But I think it is okay because establishing Token Binding
between infrastructure components under the same operational control
doesn't really add much value. Token Binding is good for the logical
endpoints of the client and server in a connection.

> Binding protocol wasn't negotiated during TLS handshake.

Treating the different components of the server as a single logical entity
with respect to Token Binding does allow LS between reverse proxy and
backend
server.

> Binding ID (or SHA256 hash of it) be good enough?

Something along those lines is an alternative approach at a solution.

---

From: Piotr Sikora <[email-masked]>
Date: Wed, 29 Mar 2017 21:49:25 -0500

Hey Brian,

> https://www.ietf.org/mail-archive/web/unbearable/current/msg01338.html. Feel
> free to join the discussion, if you are still in Chicago and available.

I'll do my best to be there.

> The intended value of this approach is to keep the reverse proxy as light as
> possible.

But why? What's the gain of removing that from a proxy that already
terminates TLS?

Also, keep in mind that it's the proxy that negotiates Token Binding
key parameters using crypto algorithms at its disposal. It's not
unlikely that it would negotiate key parameters that backend server
doesn't support, leading to a scenario where Token Binding was
negotiated at the TLS layer, but backend server was unable to verify
Token Binding Message.

> is still validating the TB message.

I think it would be irresponsible for a proxy to pass not validated
Token Binding Message to the backend.

> between infrastructure components under the same operational control doesn't
> really add much value. Token Binding is good for the logical endpoints of
> the client and server in a connection.

Why do you assume that reverse proxy and backend servers are part of
the same organization? What about CDNs and Cloud Load Balancers? While
I cannot think of an obvious use case for Token Binding with those, I
don't think we should exclude it.

> backend server.

But it gets quite ugly, since backend server receives
"Sec-Token-Binding" HTTP header over a TLS connection that _didn't_
negotiate Token Binding extension. AFAIK, the core spec requires
bindings to be dropped in such case.

Best regards,
Piotr Sikora