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

[Piotr Sikora <[e-mail]>]

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