Subject: [TLS] One stream to rule them all (was Re: Security review of TLS1.3 0-RTT)

From: Martin Thomson <[email-masked]>
Date: Thu, 4 May 2017 11:35:56 +1000

On 4 May 2017 at 11:31, Salz, Rich <[email-masked]> wrote:
> Well, for example, Chrome/boringSSL should arguably know better but are treating it all as one equivalent stream.
>
> Is FF/NSS doing the same thing?

Yes.

> Why?

Because doing anything else makes it a lot harder for the application.

I realize that you *want* that, but clearly we disagree about the
utility of API hurdles.  Given that the application already took
extraordinary steps to enable 0-RTT, we don't think that adding
artificial hurdles is going to change things.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 3 May 2017 20:41:40 -0500

> artificial hurdles is going to change things.

A related question is whether NSS wants to be a general-purpose TLS
library, or an HTTP-specific TLS library.  I have mostly come to terms
with the HTTP application profile for 0-RTT saying "combine the streams"
(but still want to see it written down with a proper security analysis
before it gets widespread), but other application profiles might do
different things!  Are you painting yourself into a corner?

-Ben

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 May 2017 11:51:58 +1000

On 4 May 2017 at 11:41, Benjamin Kaduk <[email-masked]> wrote:
> A related question is whether NSS wants to be a general-purpose TLS library,
> or an HTTP-specific TLS library.  I have mostly come to terms with the HTTP
> application profile for 0-RTT saying "combine the streams" (but still want
> to see it written down with a proper security analysis before it gets
> widespread), but other application profiles might do different things!  Are
> you painting yourself into a corner?

Sure, in a multi-dimensional space, corners can appear in the
strangest places.  But given that TLS is streams on both sides, I
can't think of a way that an alternative model would make sense.  It's
definitely the case that an application protocol could be designed to
deal with 0-RTT as a separate stream, but when all they wanted was a
stream abstraction, the idea that there might be an antechamber stream
they have to deal with separately is hard to reason about.

It's harder still when you consider data limits on 0-RTT and the need
to complete the handshake in a timely fashion.  A separate thing could
mean that sending 0-RTT would block handshake completion because the
sender might want to ensure that a complete "thing" was sent in 0-RTT.
Either that or you have to deal with truncation.

If we need another API, it's not impossible to build one, with options
to cause 0-RTT to be routed to it.  I just don't see us needing one
any time soon.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 May 2017 02:29:02 +0000

> artificial hurdles is going to change things.
 
 That's kind of inflammatory.  Apology accepted :)
 
 I don't want to make things hard.  I want to make them clear and merging
 two sets of data with different security properties does not seem like it's
 helpful.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 May 2017 12:31:58 +1000

>  That's kind of inflammatory.  Apology accepted :)

Yep, a bit stronger than ideal, sorry.

>  two sets of data with different security properties does not seem like it's

A clear delineation of security properties exists, if the handshake is
done, then you are in the clear.  Otherwise, beware.  The separation
of the streams doesn't help if you consider the possibility that 0-RTT
data can be retroactively blessed.

I agree that it's complicated and we'll need to learn more.  I fully
appreciate that you want to be conservative in how to implement this
feature.  As a predominantly client stack with far fewer consumers, I
guess we are taking a few more liberties.  Are we not both entitled to
our own approaches in this regard?

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 21:00:03 -0700

> our own approaches in this regard?

I just wanted to chime in on this thread too and this:

I think that single-stream is the way to go .. if servers prevent 0-RTT
replays.  That does leave the DKG attack, but I think that's ok. That might
seem like a contradictory view from me, so here's my nuanced take:

* The DKG attack is real and does cause the client to repeat a request.

* It's basically impossible for the server to do anything about it. The
ticket isn't re-used, so clever tricks like CloudFlare's X- header don't
work here. I thought for a while that the server could maybe fingerprint
the plaintext, but even that doesn't work, because a client might repeat it
intentionally.

* Thankfully this doesn't have to be a show-stopper. The failure mode is, I
think, identical to  existing time outs.  The client knows that the request
may have succeeded, or may have failed. At that point it's up to the client
what to do. Browsers retry, makes sense for them. Other clients don't, good
for them. But they get to choose; and it's compatible with today's
behavior.  From the server's perspective, the same is true - the server
knows that the original client may not have received any response, because
that connection fails.

* So in broad terms, existing client and server behavior should cover us
here; all of this happens when connections time out today - and an attacker
can already cause that to happen. It's not a big ecosystem change to the
layering we have already.

* If the above logic holds; then the whole "needs a profile" stuff and
signaling early data and application data to applications separately is
needless complexity IMO. Probably more harm than good, and seems to be
getting ignored anyway.

>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Colm