Re: [Unbearable] (late, sorry) WGLC question on establishing the binding or not

[Brian Campbell <[e-mail]>]

On Tue, Dec 20, 2016 at 7:13 PM, Andrei Popov <[e-mail]>
wrote:

> What if instead we say in HTTPSTB that if the server is configured to
> require TB, then this server MUST reject HTTP requests lacking TB headers?
>

I think that's implied. It might be some time before straight requiring TB
is viable but that's a deployment/policy decision and of course such a
deployment would reject HTTP requests w/ out TB headers.

The situation at hand is a more general server that will accept both TB and
non-TB but when the client and server both negotiate the same TB version
and then the client doesn't send the TB message. Looking at the drafts a
bit more again I see that TBNEGO §4
<https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-06#section-4>
has:

   If the "token_binding" extension is included in the server hello and
   the client supports the Token Binding protocol version selected by
   the server, it means that the version and key parameters have been
   negotiated between the client and the server and SHALL be definitive
   for the TLS connection.

While HTTPSTB §2
<https://tools.ietf.org/html/draft-ietf-tokbind-https-07#section-2> has:

   Once a client and server have negotiated the Token Binding Protocol
   with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and
   [I-D.ietf-tokbind-negotiation]), clients MUST include the Sec-Token-
   Binding header field in their HTTP requests.

Taken together I think that could be read to say that an HTTP client that
offers TB 1.0 in the client hello and gets TB 1.0 in the server hello but
doesn't send the TB message with HTTP requests is not complying with the
spec and a server could reasonably choose to reject such requests.

Does that seem legit?

I suppose more text could be added or clarified but maybe it's good enough
as is.