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

Benjamin Kaduk <> Thu, 29 June 2017 02:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB135126C22; Wed, 28 Jun 2017 19:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ze_yeyMD3Gwl; Wed, 28 Jun 2017 19:48:26 -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 15D8E12420B; Wed, 28 Jun 2017 19:48:25 -0700 (PDT)
X-AuditID: 12074422-365ff70000007251-3a-59546a77bd30
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 E9.91.29265.77A64595; Wed, 28 Jun 2017 22:48:24 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id v5T2mMlq030950; Wed, 28 Jun 2017 22:48:23 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v5T2mIdQ007455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Jun 2017 22:48:21 -0400
Date: Wed, 28 Jun 2017 21:48:18 -0500
From: Benjamin Kaduk <>
To: Nick Harper <>
Cc: IETF Tokbind WG <>,
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+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrVuRFRJpMO+ChUX/jn2MFsvnz2ez OPd4IZMDs8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKaJlyl7HgH3fFpjkn2RsYT3F2MXJy SAiYSJzedoCti5GLQ0hgMZNER287M4SzkVHi3OEZUJmrTBK3zq5jB2lhEVCVWLz9JAuIzSag ItHQfZkZxBYBsudfvc4KYjMLOEl8e9HHBGILC3hJzFj0BKieg4MXaN37SSEgYSGBTkaJhwvl QGxeAUGJkzOfsEC0aknc+PeSCaScWUBaYvk/DpAwp0CgxL31G8EuEBVQlvh7+B7LBEaBWUi6 ZyHpnoXQvYCReRWjbEpulW5uYmZOcWqybnFyYl5eapGuqV5uZoleakrpJkZQsLK7KO1gnPjP 6xCjAAejEg8vw9rgSCHWxLLiytxDjJIcTEqivNEJIZFCfEn5KZUZicUZ8UWlOanFhxglOJiV RHi5zIFyvCmJlVWpRfkwKWkOFiVxXnGNxgghgfTEktTs1NSC1CKYrAwHh5IEb2kmUKNgUWp6 akVaZk4JQpqJgxNkOA/QcLZ4kOHFBYm5xZnpEPlTjIpS4rx3MoASAiCJjNI8uF5QMpHI3l/z ilEc6BVh3t0gK3iAiQiu+xXQYCagwSzzAkAGlyQipKQaGHlnrlKqP7BMikvYqOH8vfX/5Vd+ OHJOOIx7e4q7/9Fl/+4zXnp1+6D+TOklbFeXKrC+s5w0a631/les796e9ujq6/h1P0zv0IU9 twSKAx6Z+28NeJla0i2bwLI/su/08Sa+h5OnrHxjHctzVuc/U3/+pOr1zF4GxlsclhbxdK9N M8go9e97nqbEUpyRaKjFXFScCAA/fa1mAQMAAA==
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: Thu, 29 Jun 2017 02:48:28 -0000

On Wed, Jun 28, 2017 at 03:25:13PM -0700, Nick Harper wrote:
> Here's a summary of the changes since the last draft:
> - If TB is accepted in 0-RTT data, keep using the early exporter for
> the whole connection. There was some discussion on this in Chicago,
> with more on the mailing list. Chairs, can you confirm whether we
> reached consensus on the mailing list or whether we should take a hum
> in Prague?

I am a WG chair, but not a tokbind chair, but that question does not
seem to make sense.  Consensus must be reached (or confirmed) on the
mailing list, so deciding there wasn't enough feedback on the list and
going to an in-room hum seems backwards, procedurally.

> - 0-RTT TB cannot be used with externally provisioned PSKs or with a
> PSK-only key exchange mode
> - A new TLS extension is used for negotiating and indicating use of 0-RTT TB
> - The replay indication TLS extension has been removed

Some discussion on the httpbis list brought up that this document should
mandate that 0-RTT token binding is only used in conjunction with
a TLS stack that provides strong anti-replay protections (i.e., zero
additional replays possible and one retransmission via DKG attack).  In other
words, the time-based scheme of (draft-02) section 6.4 should be removed,
and perhaps 6.3.1 reworded somewhat.

(It also brought up multiple peoples' sentiments that 0-RTT token binding
is a bad idea in general, but this may not be procedurally the right time
to have that discussion.)