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

[Nick Harper <[e-mail]>]

On Thu, Mar 29, 2018 at 19:16 Amos Jeffries <[e-mail]> wrote:

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


The Sec-Token-Binding header is only relevant when there is end-to-end
security. How can there be any parties changing HTTP headers in the
delivery path without the permission of the server?

It is a corner case thus the weak MAY.


> It wouldn’t make sense for it to be any stronger than a MAY.

>
> Amos
>
> _______________________________________________
> Unbearable mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/unbearable
>