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

From: Nick Harper <[email-masked]>
Date: Thu, 29 Mar 2018 14:20:47 -0700

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.

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:

1) The browser has no connection open to example.com. Any attempted
request for resource foo would have a different Sec-Token-Binding
header (because it cannot possibly match the header of the request
sent on a different connection), so the resource cannot be loaded from
cache because the Sec-token-Binding header can't match.
2) The browser does have a connection open to example.com. Now, the
browser needs to check that if it were to make a request to
example.com for foo, whether the Sec-Token-Binding header it would
generate matches - if so it can serve the response from cache; if not,
it needs to continue sending the request on the network.

A main reason for caching responses is so that they can be served
without ever going to the network. This now requires binding a request
to a particular network connection before evaluating whether it can be
served from the cache, which seems backwards and somewhere between
annoying and impossible to implement.

I suggest changing the "MAY" to "MUST NOT": Under "Additionally, the
Sec-Token-Binding header field:" where it says "MAY be listed by a
server in a Vary response header field", change this to a "MUST NOT".

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 30 Mar 2018 15:16:38 +1300

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

> 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

---

From: Nick Harper <[email-masked]>
Date: Fri, 30 Mar 2018 02:24:47 +0000

> headers are only valid when used in conjunction with a specific TLS

If the server wants to ensure that the HTTP response is only valid when
used on that connection (as opposed to in a context where there is no
connection, e.g. when reading a response from cache), that sounds to me
like it doesn’t want the response cached. If the server doesn’t want the
response cached, it should send the appropriate cache headers instead of
Vary: Sec-Token-Binding.

> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: Nick Harper <[email-masked]>
Date: Fri, 30 Mar 2018 02:31:20 +0000

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

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