[Unbearable] Sec-Token-Binding header and Vary

Nick Harper <nharper@google.com> Thu, 29 March 2018 21:21 UTC

Return-Path: <nharper@google.com>
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 C0C331200F1 for <unbearable@ietfa.amsl.com>; Thu, 29 Mar 2018 14:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 erpdZQqCn8q8 for <unbearable@ietfa.amsl.com>; Thu, 29 Mar 2018 14:21:27 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D1112E8CD for <unbearable@ietf.org>; Thu, 29 Mar 2018 14:21:09 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id d206so7468348qkb.0 for <unbearable@ietf.org>; Thu, 29 Mar 2018 14:21:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ca4J8ba185cuhXy2bH+NqP2oNMpx6tkO9m9WfUTfYd4=; b=spSCFrsWlb1NIQCDfh5tetUWkIvxqmpMDblWwfQmrNjhV76B4KMEimUw7BvOuzmdjn tJHhFWVs4Sdk/z7kOyQ8CukEaEq4lWLyEwPODWVCFWFtfSnnKt2kIWCf+kkgBMEf3iPP BbLLiXaXDKZ2CnQqj3cZm+FI/uhPbbcnqTCJx07EIJgodkiKepmAbPMR3GQHfMcgBD8J VJTtUheJZ37wvCk/xqQm1n7hLYIcUpPuHbN31S+naaoUK8yn9JOvbBhdeCk/wqGbmiK7 zWvUsEij5HytqarfvagNT3IxYa6F4ypiqluhzljm8ofEdrlh//VhM93qX/opml5j1PNW MVYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ca4J8ba185cuhXy2bH+NqP2oNMpx6tkO9m9WfUTfYd4=; b=fUc7dcwbPr6oWH7HrsHVaj2RajjpDOmziwdPRJyPjb79XySN2hjjFEJISlr0Y4gyRX 2ggVIlPnBjhVmwEveP5skckvKeBgtb7AhdQTQnt8yf2/9wbRsCznlkoh1DlX9H9bHtlc 0EKQHCSmcGIsxO5Jh4IS4vIT8O4q4ejL/95D0d3JTFF3pFhqgsScD6uTOKeSQj4sTQ7v G6kCxfbCfwFeK0UQU53JeBnG8mVNshh8Z1Va3dxzVzCGvJRX8m5edTL1vOpYVqyM8U3t +C8DQZLAzAQ1kZUAycZ+lo+xp1Zf6tDtAizqGcynX919Vt/4iW1h+tVZL7zuStlPtd6o xeYg==
X-Gm-Message-State: ALQs6tDQmU0QkD9vFRYK1s6ae67URQSlPvhhBKjeH+PiFKtTrBZkehl1 YN+QzJ14XRKt8twzTHxE0ObssRbvrEYLjMunsgqpiWxNRlo=
X-Google-Smtp-Source: AIpwx4+fbxcsXwRv6ExNJc3nSFldBe3HmSMr1+ld4fHN+Hp4/3KxzRuplu/4H2qyFGZnKuiWNJGuYGL9Rms4N4WmNgk=
X-Received: by 10.55.24.169 with SMTP id 41mr13515645qky.176.1522358467981; Thu, 29 Mar 2018 14:21:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.56.97 with HTTP; Thu, 29 Mar 2018 14:20:47 -0700 (PDT)
From: Nick Harper <nharper@google.com>
Date: Thu, 29 Mar 2018 14:20:47 -0700
Message-ID: <CACdeXiKHWmRxai1WST2BnW1BfjTWRZOAM6BRE3ZoS5De4FiQ5Q@mail.gmail.com>
To: IETF Tokbind WG <unbearable@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/VzQOnM1clr2jCY2GX7wXvpPnH-c>
Subject: [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: Thu, 29 Mar 2018 21:21:30 -0000

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