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

From: [email-masked]
Date: Wed, 28 Jun 2017 15:12:18 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Token Binding of the IETF.

        Title           : Token Binding for 0-RTT TLS 1.3 Connections
        Author          : Nick Harper
	Filename        : draft-ietf-tokbind-tls13-0rtt-02.txt
	Pages           : 11
	Date            : 2017-06-28

Abstract:
   This document describes how Token Binding can be used in the 0-RTT
   data of a TLS 1.3 connection.  This involves a new TLS extension to
   negotiate and indicate the use of Token Binding in 0-RTT data.  A
   TokenBindingMessage sent in 0-RTT data has different security
   properties than one sent after the TLS handshake has finished, which
   this document also describes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tokbind-tls13-0rtt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tokbind-tls13-0rtt-02
https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-tls13-0rtt-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-tls13-0rtt-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Nick Harper <[email-masked]>
Date: Wed, 28 Jun 2017 15:25:13 -0700

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?

- 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 editorial and document structure changes

On Wed, Jun 28, 2017 at 3:12 PM,  <[email-masked]> wrote:
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Jun 2017 21:48:18 -0500

> reached consensus on the mailing list or whether we should take a hum

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.

> - 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.)

-Ben

---

From: Leif Johansson <[email-masked]>
Date: Thu, 29 Jun 2017 11:05:31 +0200

> going to an in-room hum seems backwards, procedurally.

Judging consensus is sometimes tricky. I think what Nick meant was that
we may want to do a hum in Prague /in addition to/ seeking confirmation
on the list.

---

From: Nick Harper <[email-masked]>
Date: Thu, 29 Jun 2017 11:33:01 -0700

> we may want to do a hum in Prague /in addition to/ seeking confirmation

It is unclear to me whether consensus was reached (hence deferring to
the chairs on that judgement). If we don't have consensus, I'm fine
continuing the discussion on list and in Prague. Let me check that I
understand the process properly: first, discuss (on list and possibly
in person), then if the discussion sounds like it's reached a
consensus, optionally hum in person, and then confirm consensus on the
list. Does that sound about right?
>> and perhaps 6.3.1 reworded somewhat.

I read over the "New Version Notification for
draft-thomson-http-replay-00.txt" thread on the httpbis list. My
understanding of the issue raised on that list is simply that there
are attacks on 0-RTT Token Binding if there isn't a strict global
anti-replay mechanism. There are still attacks possible on 0-RTT Token
Binding even if there is a strict global anti-replay mechanism. I need
to consider what additional attacks are possible without such a
mechanism, and if any of those attacks require less privileges than
the attacks possible with the mechanism.
>> to have that discussion.)
I'm aware that multiple people think that 0-RTT token binding is a bad
idea in general. So far, the impression I've gotten of this sentiment
is "0-RTT Token Binding is not something I have any interest in
implementing". If the sentiment is closer to "0-RTT Token Binding is
such a horrible thing that no one should be implementing it", then
maybe we should discuss that sooner.

---

From: John Bradley <[email-masked]>
Date: Thu, 29 Jun 2017 15:02:05 -0400

Inline

> On Jun 29, 2017, at 2:33 PM, Nick Harper <[email-masked]> wrote:
> 
> On Thu, Jun 29, 2017 at 2:05 AM, Leif Johansson <[email-masked] <mailto:[email-masked]>> wrote:

Yes
> maybe we should discuss that sooner.

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.

I don’t believe the WG has any real consensus on this yet.   The draft spec is helpfull for us to discuss the issues.   

I encourage more discussion on the list on the topic of the draft and if this is the correct way to deal with 0-rtt if there are counter opinions.

Regards
John B.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 29 Jun 2017 20:16:33 +0000

*   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.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Thursday, June 29, 2017 12:02 PM
To: Nick Harper <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>; Leif Johansson <[email-masked]>; [email-masked]; Benjamin Kaduk <[email-masked]>
Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-tls13-0rtt-02.txt

Inline

On Jun 29, 2017, at 2:33 PM, Nick Harper <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Jun 29, 2017 at 2:05 AM, Leif Johansson <[email-masked]<mailto:[email-masked]>> wrote:

Yes

-Ben

Regards
John B.