Re: [Unbearable] I-D Action: draft-ietf-tokbind-tls13-0rtt-02.txt

Benjamin Kaduk <> Sat, 01 July 2017 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52A671296CF; Sat, 1 Jul 2017 09:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ia4noafoN33U; Sat, 1 Jul 2017 09:53:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD7EF128896; Sat, 1 Jul 2017 09:53:24 -0700 (PDT)
X-AuditID: 1209190d-2cfff7000000040f-63-5957d3834a5f
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 6E.E7.01039.383D7595; Sat, 1 Jul 2017 12:53:23 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id v61GrM7h018326; Sat, 1 Jul 2017 12:53:22 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v61GrHxS008113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 Jul 2017 12:53:20 -0400
Date: Sat, 01 Jul 2017 11:53:17 -0500
From: Benjamin Kaduk <>
To: Nick Harper <>
Cc: John Bradley <>, IETF Tokbind WG <>, Leif Johansson <>, "" <>
Message-ID: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT0W2+HB5pMPGVusWC3q3MFv079jFa LJ8/n83i3OOFTBar7/5lc2D1WLCp1GPJkp9MHns39bF73L69kSWAJYrLJiU1J7MstUjfLoEr 49aaN2wFN3kqHu5Yz9TA2MvVxcjJISFgIjHp43OWLkYuDiGBxUwS5xYsYINwNjBKzF73lgnC ucIkcfX8Y1aQFhYBFYkDbxcxg9hsQHZD92UwWwTInn/1OitIA7PAZkaJU/NegDUIC3hJzFj0 hAXE5gXad+X+b6ipW5glJpy8AZUQlDg5E6KIWUBL4sa/l0BFHEC2tMTyfxwgYU6BWIl/Wzew gdiiAsoSfw/fY5nAKDALSfcsJN2zELoXMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXSy80s 0UtNKd3ECAptTkneHYz/7nodYhTgYFTi4d0QEhYpxJpYVlyZe4hRkoNJSZR35bXQSCG+pPyU yozE4oz4otKc1OJDjBIczEoivEarwiOFeFMSK6tSi/JhUtIcLErivOIajRFCAumJJanZqakF qUUwWRkODiUJ3imXgBoFi1LTUyvSMnNKENJMHJwgw3mAhiu2gAwvLkjMLc5Mh8ifYlSUEudt vAiUEABJZJTmwfWCUo9E9v6aV4ziQK8I8zKAVPEA0xZc9yugwUxAg4VnhIAMLklESEk1MLKf Xjd/053uk1Kea3NCy39YZC1Z5fWhrCCpTinqzCK2dUfmBu0SfXcytCG/S1DTy2iKqOuc+rDz FcdMFGv8+1qZWGu6Z1nNNZv66PUKWWOR5cbf7wm+2/O+RG+H2T3DqRO+rWrY+E2rvtyzhmFr qMpyi20maRp6/L9W+fZ5pqjc61O7HHXqkBJLcUaioRZzUXEiAJcXeWIYAwAA
Archived-At: <>
Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-tls13-0rtt-02.txt
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.\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 01 Jul 2017 16:53:26 -0000

Hi Nick,

On Thu, Jun 29, 2017 at 08:16:33PM +0000, Andrei Popov wrote:
>   *   A good point,  if the attacks are still possible then supporting 0-RTT is problematic.
>   *   On the other hand 0-RTT is a big speed boost for resumed connections.  It is hard to imagine that servers are going to disable it to use token binding over the long term.
> There is often a tradeoff between security and performance; some servers may choose 0-RTT based on their business requirements, and others may choose TB. I do not think that it is necessary to reconcile TB and 0-RTT (although it would have been awesome if we could). From my perspective, it is more important to keep TB secure than to make it work with 0-RTT: replayable TB would be a waste of CPU cycles.

I agree with Andrei that there is a tradeoff and keeping TB secure is important.

For a long time I have been generally opposed to 0-RTT TB at a gut level,
but I may have recently gained an intuition for how to articulate my
concerns in a more concrete fashion.  That is, as a server, I am interested
in TB providing binding to the channel between the client and myself.
But, since 0-RTT does not include any server contributions, in some sense
0-RTT TB is only binding to "half of the channel" (the client's contribution),
and even though it is/ends up being bound to my (as the server) connection
to the client, the same octets on the wire could also end up being bound
to a different connection emanating from the client.  So I as a server
have a weaker security guarantee, and I would prefer to retain the stronger
security property.