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

Nick Harper <nharper@google.com> Fri, 30 March 2018 02:25 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 BAC7412E052 for <unbearable@ietfa.amsl.com>; Thu, 29 Mar 2018 19:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 KHNvadaPux-i for <unbearable@ietfa.amsl.com>; Thu, 29 Mar 2018 19:25:00 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 28E5C124B18 for <unbearable@ietf.org>; Thu, 29 Mar 2018 19:25:00 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id o184so7948352qkd.13 for <unbearable@ietf.org>; Thu, 29 Mar 2018 19:25:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W98SquNdFJgQHWk7vemsB8YJuR4t7u5tFx3ksciMY+I=; b=Ukx94D9txejgcOwyFZrkoszcoZI0rKH1GpqpLO9f0m3IaiQEbTs/Y6JyG1DWe0n0tW 4VKM0POZIz9THV6tavXkGsqEc/YomOraqhvvyJKOs2AShFU0ubKpqsnTD+4jhHV0YwB9 T67wTwD9SvwPfAl0MenBIrEHwl8y1fQnrkKfTx5IzC6e3oMamoxJXW25vOseOeIvX1Pu Z5bPYdPtE4CkEwTCxp47h1jkjCrtiBbVFggB+IIQ6ggCkpjw3QBPVLisytY5oQyUVck5 iH27Zibx8TJbh6OaoJUEgPTNCwyyR0pNaHXYIH/UYUjS7YM/Hm77jNwIbeRqfDG9mEyY eCFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W98SquNdFJgQHWk7vemsB8YJuR4t7u5tFx3ksciMY+I=; b=JcIvfHyfIDm8djE4v69LSPMnBXpU07tQGYHAkdQ9x5vL8zJ6cuZqGyNbHuz33BzVw5 CMaWUEhLh2ECDSsS8bPg6qP/DjDwDah5xZBihrGeqgU7fLqKAnuDNzWQc52mKYDfaEUN Z7PtwGiizbFrTKKnmcU3girKN7sPDzny1woKVisEPGR2hqUQ8YPB8q0RSqPgYuf5L+tj nCKoZnGXc3ccoFT1kJnzONOl1+MVIu2zmH39X0G9fv4dFCnnMw4Tlbnsf6yhhD4NMofy 9GAff7LgQVWOsTizeH5zLd4BtD7FW4LMLZYs8/UqgQhzzspIDdLvTS+ImFkrDEU8duqR SgoQ==
X-Gm-Message-State: ALQs6tBB0iRxm3icPe2FNc0I+SEhs9+lFyyRz82cViVyy5QPZzOqyizh uVLZMgc0FL67kr3PTWhnUyIIZwu/pHeyCFap2ma2MFK+
X-Google-Smtp-Source: AIpwx4/x40lifzuWzQs5X0y3nVeayDsmaX2SSFMMMf0Qz5mgwkinX7rBYL5X8h0eCk1CTYEfQyHjsf3TnK82FcjqRi8=
X-Received: by 10.55.162.66 with SMTP id l63mr15082240qke.124.1522376698799; Thu, 29 Mar 2018 19:24:58 -0700 (PDT)
MIME-Version: 1.0
References: <CACdeXiKHWmRxai1WST2BnW1BfjTWRZOAM6BRE3ZoS5De4FiQ5Q@mail.gmail.com> <c78d00f8-40db-86bf-f7de-ade25fbdcef1@treenet.co.nz>
In-Reply-To: <c78d00f8-40db-86bf-f7de-ade25fbdcef1@treenet.co.nz>
From: Nick Harper <nharper@google.com>
Date: Fri, 30 Mar 2018 02:24:47 +0000
Message-ID: <CACdeXiJu++y8hsn2LxFHpYSF9r=zMu2L_at0LCB20VxX44MP-Q@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: unbearable@ietf.org
Content-Type: multipart/alternative; boundary="001a114faa74593c57056897f2d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/NLW-TttMWLdG3NpUKiQ0QpQ9Lt4>
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:25:03 -0000

On Thu, Mar 29, 2018 at 19:16 Amos Jeffries <squid3@treenet.co.nz> 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 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.

>
>
> 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
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>