[Unbearable] Switching exporters for 0-RTT Token Binding

Nick Harper <nharper@google.com> Tue, 18 April 2017 22: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 047A81314B7 for <unbearable@ietfa.amsl.com>; Tue, 18 Apr 2017 15:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 80YtQ3okZHNI for <unbearable@ietfa.amsl.com>; Tue, 18 Apr 2017 15:25:04 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 ACE5F1314B3 for <unbearable@ietf.org>; Tue, 18 Apr 2017 15:25:03 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id c80so3370015lfh.3 for <unbearable@ietf.org>; Tue, 18 Apr 2017 15:25:03 -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=ESPv51Q4Ex2ZPFdoJO2ij14aBnahT/O4KowNXE6rhF8=; b=m5nz7SsQHrnva6/wzom4vRnL/R4DgboYFAWSEPKRUZuHTJYKgAIiS//93Qhm5R2npE BofosHi3ztI52AsqiyYDGxub+QPr8LI1E1WMBqOA+gFt0gjsomxeT0m3NnJlA9FJ7g52 UuSllqXHgNwyLwSJjyAPD0Map/DbJjkIC0y7QcfT8r5NFRLNZ5Xkgdz7Zrp7pF8rx2cP hSVNv87+Xn7SIHZHPDN4X+vc3kThAr2L/P59dN/JzR1aRzlD4DaUQXZn0m0vAmaeske7 E7fL89qqZLhTfwCBv3uPGLB8OQfmcKpa7QP8dxXCd+2xFPm8vCCpBURltoxgAMHdr7zS kXIQ==
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=ESPv51Q4Ex2ZPFdoJO2ij14aBnahT/O4KowNXE6rhF8=; b=sOwBHCeiQ531IEpKNX05+tL3BaKTtYNluSw6aPh6iE7J7xJ7v9p5bWCqvgxWL4d42b 65d2WsGepqftQHMr0j4UQ77t6Nkl8KiWl6i68kobZwYd59PXwphj2QEbx+SH9fl7jPpr DKmCbV3UeZQf60eBIW56Z/jfKZeYyeO5KM6La7pRNSCIysET9Ie7WfXSBWkChAihv4vT CsmiHRfa/gws4S4HQgVuWvxqh3DQJg8fln6pHNjs3zX+rHRSLG1/ATuCAI0c1cANxg4q g/8yViutPPoZPR5cV9T/yy9E5agMM86cS54WjGc3rxHCXH3O/d5mA8EwpO/zIJfQZzfB Mb/g==
X-Gm-Message-State: AN3rC/4uWpD2sVwneZOxjG6Vi+iDQZxLosVSZ/a5mQY2HGC5UTg7L6bP Cgms+AWQ1oCQKp5lSixBoTDyzksPfu1agnA=
X-Received: by 10.46.76.10 with SMTP id z10mr50278lja.8.1492554301254; Tue, 18 Apr 2017 15:25:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.7 with HTTP; Tue, 18 Apr 2017 15:24:40 -0700 (PDT)
From: Nick Harper <nharper@google.com>
Date: Tue, 18 Apr 2017 15:24:40 -0700
Message-ID: <CACdeXiLF3G8tBO5z5L2mfe5N-kYMv_4TNFS2_0YdecquMM_kuw@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/CTgSjrXtzwPWlzo5PHJiQ-izdA8>
Subject: [Unbearable] Switching exporters for 0-RTT Token Binding
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: Tue, 18 Apr 2017 22:25:07 -0000

One of the issues raised in Chicago around 0-RTT Token Binding is
whether or not to switch from the 0-RTT exporter to the normal
exporter, and I'd like to get some feedback from the Working Group on
this.

The two options I'm considering are as follows:
1) Always use the 0-RTT exporter on connections where 0-RTT data is accepted.
2) Use the 0-RTT exporter for Token Binding messages sent in 0-RTT.
The client switches to using the normal exporter soon after the
handshake finishes, but it may send some Token Binding messages
post-handshake using the 0-RTT exporter.
In both cases, if the server rejects 0-RTT data, the client uses the
normal exporter (i.e. the client behaves the same as in TBPROTO).

I'm currently leaning towards option 1. Below are my arguments for
each option. I'm interested in hearing additional arguments
for/against each option and what people's preference is. I'm
particularly interested in the opinion of server operators who would
be implementing this.

For option 1:
Option 1 is simple to implement. No extension (or other mechanism) is
needed in the TokenBinding struct to indicate which exporter was used
to avoid the server needing to do trial verification. Code paths are
simpler on both the client and server when the exporter value remains
constant for the whole connection.

When a server is choosing whether to accept or reject 0-RTT data, it
cannot base this decision on the content of the 0-RTT data, which
means that a server that chooses to accept a 0-RTT Token Binding makes
that decision without knowing what the message contents are. It
follows that said server finds the security properties of 0-RTT Token
Binding acceptable on any request received in 0-RTT. If a server finds
the security properties of 0-RTT Token Binding acceptable on a request
when it is received in 0-RTT data, then it would only be logical for
it to find those security properties acceptable when that request is
not in 0-RTT data (i.e. post-handshake), and since that server will
accept any message (with 0-RTT Token Binding) in 0-RTT data (because
it can't choose whether or not to do 0-RTT based on message contents),
there would be no case where the server would only accept the normal
exporter.

For option 2:
A server might have some requests where it is fine with the security
properties of 0-RTT Token Binding, and others where it wants the full
protection of the (normal) exporter. If the server can ask the client
to re-send a request with the normal Token Binding exporter, it can
accept some requests sent in 0-RTT with the 0-RTT exporter, and for
others it can request the client to re-send, which if the client is
switching exporters, it will re-send with the normal exporter.

Option 2 relies on the application layer having some mechanism that a
server can use to ask a client to retry a request - TLS has no
mechanism to reject 0-RTT data after it has been accepted (or to
request the client to re-send the 0-RTT data under 1-RTT keys). For
HTTP, I think this can be done with a 307 response code. Option 1
needs no such application layer support.