Re: [Unbearable] Sec-Token-Binding header and Vary

[Amos Jeffries <[e-mail]>]

On 30/03/18 10:20, Nick Harper wrote:
> The Vary HTTP header specifies a list of headers whose values must
> match for a resource to be served from the cache. HTTPSTB specifies
> that a server MAY list Sec-Token-Binding in a Vary response header. I
> think this behavior is silly, and we should disallow Sec-Token-Binding
> in Vary.
> 
> The reason why this is silly is that the Sec-Token-Binding header's
> value is dependent on the underlying connection, and it will be
> different for requests on different connections.

That is exactly why Vary is permitted. The whole purpose of token
binding is to bind a token in the TLS connection (session) to the Cookie
etc in the HTTP(S) message.

The intended use case for token binding is to ensure that HTTP response
headers are only valid when used in conjunction with a specific TLS
connection / session.

If session resume is used the TLS connection over different TCP
connection should have the same security token that has been bound for
the response in question.

If an entirely new session has been negotiated the token has changed and
new HTTP response header is needed. That may require;
 a) a new Cookie header only (CC:no-cache and revalidation is all that
is needed) or
 b) a new payload (Vary is relevant).

For example, consider the new AES payload encodings using a bound token
value as (part of) their encoding key to enforce one-time access to
resources - perhapse a secure live stream.


> 
> Consider a request to example.com for resource foo, sent with the
> Sec-Token-Binding header, that gets a response with "Vary:
> Sec-Token-Binding", and a browser caches this response. The browser
> then visits some page that includes resource foo, so it goes to see if
> it can use it from cache. (Assume arguendo that all other caching
> properties are such that if there weren't this Vary header the
> response would be served from cache.) There are two options now:

If one assumes the case where Vary is unnecessary one of course can
circle around to find that Vary is unnecessary.

Assume the other case: that caching controls were sent but ignored
(and/or removed) by one or more HTTP agents along the delivery path.
Vary is now useful as a backup mechanism to protect against injection
attacks. It is a corner case thus the weak MAY.


Amos