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

Amos Jeffries <squid3@treenet.co.nz> Fri, 30 March 2018 02:16 UTC

Return-Path: <squid3@treenet.co.nz>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1B3124B18 for <unbearable@ietfa.amsl.com>; Thu, 29 Mar 2018 19:16:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level:
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr-FagM5vQfE for <unbearable@ietfa.amsl.com>; Thu, 29 Mar 2018 19:16:43 -0700 (PDT)
Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id D6789128896 for <unbearable@ietf.org>; Thu, 29 Mar 2018 19:16:40 -0700 (PDT)
Received: from [192.168.137.92] (unknown [121.98.41.233]) by treenet.co.nz (Postfix) with ESMTPA id 2A0CA6600F5 for <unbearable@ietf.org>; Fri, 30 Mar 2018 15:16:39 +1300 (NZDT)
To: unbearable@ietf.org
References: <CACdeXiKHWmRxai1WST2BnW1BfjTWRZOAM6BRE3ZoS5De4FiQ5Q@mail.gmail.com>
From: Amos Jeffries <squid3@treenet.co.nz>
Openpgp: preference=signencrypt
Autocrypt: addr=squid3@treenet.co.nz; keydata= xsFNBFiOEzoBEADuuawHiMOqHBjL5Mk6IfPCgJmY3oqJDmykzve+vDh7jArtFnOG067ftaML ligGh3y6LOLh3r1kIZ254CPHuKFYssA1p9mXL9YJnZ1qHrQVhqZwDq7dH/UtBQ2IM1QukoTo 1VRTB3ppiPHKTSa2zZ/kgBs0d+1MOi8DY2SmIDYVhUJI55qSqpxlcs6MyG4KxlEPD35J3nL4 hIzLzuzIbZoUO6M+dLvnqiFu2+mm6o75nxYmq+JCPwN5biETkSvndqr56t/W0ajlU1MpFXfO YJ8PfutrIBUPsRJUqWQjGg6uXp4torC1q2XasfSKVIQ+8duw7MCrkAfRv5BtDtpesAAsScvY TwUaDYVioiNNK1uJQZlrpYY4I0EbHI4GHKq7Q4VmotcQ2BhigqRIdh7kD3corddhlLTvTs0G 5Pjk/T2ZoMFZI03g+ieuo1l8VhCGdlqSQd8d1Np9WWwS9899QSgucwEeG+OK2f1IxxD12HiC gNoSh9id9vTYLTZK+HM1FEu+iwTxfQ9F/kDN49IaPhfvjJTs86Ov4FBTtaNUN2pF0qXpQr3A RisxZt7t7MVls+570sNnaijYYkLZdZj+49QArJxallltX3sbc9AK5JxkT8XivRCeLTKOngZE zIZCBeZuyI8cCemhU0csl89ZcORbMsgFS28FyWH4+X6lA+R5HQARAQABzSJBbW9zIEplZmZy aWVzIDxhbW9zQHRyZWVuZXQuY28ubno+wsGOBBMBCAA4FiEEAimzwkzOwlQSfJUyANhjZ5Qg vdMFAliOEzoCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQANhjZ5QgvdOKkhAAseag 7QTzRF20TDwc6QQpfYdUyuuMqyEV3AwATtJxF2Y+aF/hEHXU9XBCM8EMyiJR816haC+86Wci 0cXYj7pmR80psR9C6JoaNos89CrgsmMx9tZR5yJXrdTCnQajbZf3ozs7IDk41g4NvWg5GtHM 3MYriL0LUBXLT+YSZ9Qq2DmRZRatCjk6tiMYeHG/GtH6GZs3YExRO9Am16C1gTJRao9mJtCB DR+0NrRB2E7tKN8EZySAsZkDzbL+hL/LpdWkEZvlBsSxJebAN0x64w3FSztHGfZwLfLsxdva 6CfYs8kalHoTxRoRhpIKmTtGFJI4v9cR0+Ua5trMPgHG2QIOgXOKtOTgdYF5ksA98ZF+Odsu W7yCe9POqc4bnDbOXByxVuNMPwVSESk/GJwnxRB2vW4nywQKREJ2H6HeDO+KVhLE9nH5Alsp XpEgPpzYVeplhcKKi6H56bI0anIHvao7vEEXNP2pwRWSoMKEwGWGG7QvmemQ0YbsUqJSK563 SwNe5cVUg/Cqb08m7D9ybAm+hwgtvzU7OGsLyIHuyVxnGkB5A1GV1lizUmsFauBxyw8Yx6Gm wfmsiwEVYV/lidg+ubnsxqN7Kuvg9gYRvv+Yg1wl1QFRgeOFjbU8hj/AaNAP9SppHcA5joBe kakQx18Y6LIKKvdoepDg3mFXrOouo8jOwU0EWI4TOgEQAMmEISQmHDde0q2YfyeA8MKejHlt 5vCldKYwtaN5ii077vJaNrQk9Q8Iym6ro0plAdtLDTzyQCATWUctF6B0VowB4/LqF40U4g+u NAj7fzC/mVvSIG42diN0pJYkcfd9ghVcF7H5CeYe2zL3TlqilqQA6Xmt6i7NmYUMO939jw7V ZszMHlqvDTUzcimKrTVB7oS3+r5v1GGT3q+utrxka3WoQ3IHnidsylbTfF+dlRsvtKWxtg8k mTgu/oj1CmUE0DQh67kXsiC3nhjdUh+eZfDGmLuOGgVAWU/WNCS3oaVxVXW3rX/nUc+URkiO CuxyPjBy+A8Z+I8OXpIaC6FQY9sCFVo7yK4UxsK+eM93mWGIc5cGBL99vr+7YgZ3TBjYrazL O5Z8wyw765G1U3dPZB+egRMEY5CO64eb78f7vbRl8/INZWdkJxcotR4weGnvOxxDHyncS3BT Su6iiqmXSz0ZDpaOdCMNDHE6Kmt1qw2NbuGUHohqg2K8+1mWnXwevS0afydoG7EX0AuE1YEf kODsek8ceFj4U2c1jlOQbuO01pHa6Z9VYn5NOwXETlIytjDyBt15R7Tt1BQQg7wU482a5SSl wXYyzOx42a2CLvZM2tXnbIY4VZDu+V1ywXNMGOs8Am1LJzi74eEv2NTbvdFMmsGAkWNWn6KS 77eR+pe5ABEBAAHCwXYEGAEIACAWIQQCKbPCTM7CVBJ8lTIA2GNnlCC90wUCWI4TOgIbDAAK CRAA2GNnlCC90zeSD/9qEpJAtuEAXyCCymUEpzN6XgSWdcYra+NolIGCRzWd3SnxtBi+zWwh LFxm8AEhfqSMRh95T4XWKHScIsZZuG9xiap5whJ5xLJC/NlZidQqiPSJLog2+Yqt+PBVPrMp aG7Cmq64Y4ttvFwLZ8Wn23irJzr9JiWvsjprImsCZbuG/I1JWHUIn70oknzsTgpTPWDCfnCi GhCK7vgXak9QgBKhrzgADK3o6uCjmNllUdci9gFzUSy4/x9x73xrbzXS8/pO23fnbBwPa7VV 9IRtOb8HJJk8Y79A1ZnkVANBo1KmE+Ycw92IMcz2ev4VFw+pbqZ/swHqa3y3L5cT7Keqgc67 wiahSZRc5zM0jJWxN//lpgcdnDRI1OSLCrMMI69yc2QMzUZu87BtEJzm0DBy2pIKEni9dSCw wMITUsU21Ny3RmaV7fmXYAyp9pcaQQWGOb2CIvU7k60eLWgfNTo5SGI56WYC+ndod7vPU+sw JVbKrQKqfwO5JbdY9YPbo++Z6kfrnbkmm3wkJ4W8dOcrkLYbmOk7sColcQhVbmGy74Ggzl75 R22Q7+Uhjj9iq0Kv3CGQ3rKVdXOfAo5OekdaMDx9t9HoirGiokcyCPTy7wAyvQ75lbrygxCm e05XBfLZHrMp+SdM8ONsdgIe7U0bI85zYegceSagzCtBdB8HQ10TFg==
Message-ID: <c78d00f8-40db-86bf-f7de-ade25fbdcef1@treenet.co.nz>
Date: Fri, 30 Mar 2018 15:16:38 +1300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <CACdeXiKHWmRxai1WST2BnW1BfjTWRZOAM6BRE3ZoS5De4FiQ5Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/6AuWjZpShGgWmwquDUXUHv_L7Tk>
Subject: Re: [Unbearable] Sec-Token-Binding header and Vary
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2018 02:16:45 -0000

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