Re: [Unbearable] Switching exporters for 0-RTT Token Binding
Benjamin Kaduk <kaduk@mit.edu> Thu, 20 April 2017 02:08 UTC
Return-Path: <kaduk@mit.edu>
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 6065E12778E for <unbearable@ietfa.amsl.com>; Wed, 19 Apr 2017 19:08:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 fn1ZD0-ycti1 for <unbearable@ietfa.amsl.com>; Wed, 19 Apr 2017 19:08:52 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B339124D68 for <unbearable@ietf.org>; Wed, 19 Apr 2017 19:08:52 -0700 (PDT)
X-AuditID: 12074422-e03ff70000000cd4-54-58f81833b11d
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 50.50.03284.33818F85; Wed, 19 Apr 2017 22:08:51 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v3K28ocq026077; Wed, 19 Apr 2017 22:08:50 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v3K28kcf019049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Apr 2017 22:08:49 -0400
Date: Wed, 19 Apr 2017 21:08:46 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Nick Harper <nharper@google.com>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Message-ID: <20170420020846.GY30306@kduck.kaduk.org>
References: <CACdeXiLF3G8tBO5z5L2mfe5N-kYMv_4TNFS2_0YdecquMM_kuw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACdeXiLF3G8tBO5z5L2mfe5N-kYMv_4TNFS2_0YdecquMM_kuw@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUixG6nomss8SPC4MJWZYv+HfsYLc49Xsjk wOSxYFOpx5IlP5kCmKK4bFJSczLLUov07RK4MhZf3sNecFawYtqUN+wNjDP5uhg5OSQETCR6 TlxmA7GFBNqYJHoaBboYuYDsjYwSS67MZIZwrjJJrFv9mBGkikVAVeLsgUesIDabgIpEQ/dl ZhBbBMief/U6WJxZQFPiYsdvdhBbWMBV4tHls0C9HBy8QNta2+QglgVI/Nv6DqyVV0BQ4uTM JywQrVoSN/69ZAIpZxaQllj+jwMkzCkQKHH42WOwO0UFlCUaZjxgnsAoMAtJ9ywk3bMQuhcw Mq9ilE3JrdLNTczMKU5N1i1OTszLSy3SNdXLzSzRS00p3cQIDlAXpR2ME/95HWIU4GBU4uGN SPseIcSaWFZcmXuIUZKDSUmU1/UjUIgvKT+lMiOxOCO+qDQntfgQowQHs5II7zzRHxFCvCmJ lVWpRfkwKWkOFiVxXnGNxgghgfTEktTs1NSC1CKYrAwHh5IEr6k4UKNgUWp6akVaZk4JQpqJ gxNkOA/Q8CdiIMOLCxJzizPTIfKnGBWlxHk/gWwVAElklObB9YISiET2/ppXjOJArwjzLgdp 5wEmH7juV0CDmYAGRwR8ARlckoiQkmpgnOvSZHsqwOeOCP92GynuY4c3ef5ZwRB7/jRT6sdA gYuXA7pvvGITjano9Lx++wn73H9vJiyNUkyK3fT/rsHep4UrDHuUl18qXJXXlKmY/sz8aGHV Fx39xaxehzstFwrO0xRZubBtRmlI/90tdfOPu3xvrl/wLWmaZ9aqsGr7VVsupPwUWHHuuxJL cUaioRZzUXEiAFUGa8n7AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/0ysIGo9pspxestifXGXq0ciPhH0>
Subject: Re: [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: Thu, 20 Apr 2017 02:08:54 -0000
On Tue, Apr 18, 2017 at 03:24:40PM -0700, Nick Harper wrote: > 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). To make the obligatory statement of hopefully obvious facts, 0-RTT data MUST NOT be used absent a profile that defines its use. Presumably the situation of most interest here is HTTP right now, and many people would presume that the HTTP profile for early data will say "just concatenate the two streams", but those are just presumptions. Perhaps some other profile would be appropriate for non-HTTP cases, though with no concrete proposal it hardly seems worth time to think about other than to note that whatever decision may be reached here might be limited to HTTP in its applicability. If one presupposes that the profile for the use of 0-RTT is "concatenate the streams", then the arguments against (1) are weakened (though not entirely removed). But I'm not sure what level of consensus there is for such a (pre)supposition. Having not fully thought through the matter, I still lean towards (2), with the justification that token binding can be thought of as an attempt to prove live possession of a key [associated to a token] on a connection where that token is used. The 0-RTT exporter does not have a server contribution, so it's hard to really prove liveness of possession using just it. I acknowledge that there is engineering work remainng to be done in making (2) practical/usable, and am not really in a position to contribute much to that work, but that's my current thinking on the matter. -Ben
- [Unbearable] Switching exporters for 0-RTT Token … Nick Harper
- Re: [Unbearable] Switching exporters for 0-RTT To… Benjamin Kaduk
- Re: [Unbearable] Switching exporters for 0-RTT To… Nick Harper
- Re: [Unbearable] Switching exporters for 0-RTT To… Andrei Popov
- Re: [Unbearable] Switching exporters for 0-RTT To… Benjamin Kaduk
- Re: [Unbearable] Switching exporters for 0-RTT To… Nick Harper
- Re: [Unbearable] Switching exporters for 0-RTT To… Benjamin Kaduk
- Re: [Unbearable] Switching exporters for 0-RTT To… Bill Cox