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

[Andrei Popov <[e-mail]>]

  *   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:[e-mail]] On Behalf Of John Bradley
Sent: Thursday, June 29, 2017 12:02 PM
To: Nick Harper <[e-mail]>
Cc: IETF Tokbind WG <[e-mail]>; Leif Johansson <[e-mail]>; [e-mail]; Benjamin Kaduk <[e-mail]>
Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-tls13-0rtt-02.txt

Inline

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

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

On 2017-06-29 04:48, Benjamin Kaduk wrote:

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.

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.

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?

Yes





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

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.


(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

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.

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.