Subject: [TLS] Simpler backward compatibility rules for 0-RTT

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Jun 2016 11:15:39 +1000

David Benjamin wrote our section on 0-RTT backward compatibility to be
a little bit lenient about server deployment.  On consideration, I
think that a simpler set of rules are better:

1. If the server advertises support for 0-RTT, then it implies a
commitment to support TLS 1.3 for the duration of that advertisement.
2. Therefore, if the client attempts 0-RTT, then it should reject a
ServerHello with TLS 1.2 or older.

https://github.com/tlswg/tls13-spec/pull/502

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 21 Jun 2016 10:07:17 -0700

> ServerHello with TLS 1.2 or older.

​How does this affect the situation where a server might attempt to deploy
TLS 1.3, discover a bug, and need to rollback? Does it just magically work?​

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 21 Jun 2016 20:54:13 +0300

> TLS 1.3, discover a bug, and need to rollback? Does it just magically work?​

AFAIU, if one has 0-RTT-capable dynamic PSKs out there, one can only roll
back 0-RTT support, but has to wait for all the PSKs to expire beefore
being able to roll back TLS 1.3.

Of course, the period between deploying TLS 1.3 and deploying 0-RTT
should test how things work without 0-RTT (but it does not test 0-RTT
failing, which is _critical_ to work correctly).

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Tue, 21 Jun 2016 18:45:12 +0000

> failing, which is _critical_ to work correctly).

Right, this is the deployment complexity I was hoping to avoid with the
section. I expect that large companies with TLS experts on staff will be
able to navigate this difficulty. We can deploy TLS 1.3, wait for
everything to stick, and then turn on 0-RTT.

But smaller and medium-size deployments may simply have a handful of stock
installs of their favorite operating system and server software. People
like things being fast, so either 0-RTT will be on by default on web
servers or people will copy-and-paste config options. It's those
deployments which I don't expect to get this right.

This isn't a theoretical concern. OpenSSL and very early revisions of
BoringSSL had a bug around session handling with similar effects. If one
established a TLS 1.2 session and then later did a full TLS 1.0 handshake,
even though the TLS 1.2 session was *not* resumed, merely offering it
caused OpenSSL to lock the version. Very early on in switching Chrome from
NSS to BoringSSL, we hit interoperability issues due to this.
https://www.debian.org, at the time, had a heterogeneous deployment of TLS
1.0 and 1.2. This was rather messy to diagnose. Flaky failures are the
worst.

I can also imagine this sort of thing happening if users turn antivirus
products with TLS MITMs on and off, or if they have a work machine with a
TLS MITM certificate and enter/leave their networks. (I'm sure no one on
this list, myself included, has any love for this sort of configuration,
but it is reality.)

David

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jun 2016 10:24:30 +1000

To be clear about this, I expect that browsers will do some fairly
horrific things in response to this.  We will attempt to use 0-RTT,
get TLS 1.2 and abort as described.

But then we will do the shameful thing and fall back to 1.2.  Plotting
out the alternatives, I don't really see a better option.

On 22 June 2016 at 04:45, David Benjamin <[email-masked]> wrote:
>> > How does this affect the situation where a server might attempt to
>> > deploy
>> > TLS 1.3, discover a bug, and need to rollback? Does it just magically
>> > work?
>>
> able to navigate this difficulty. We can deploy TLS 1.3, wait for everything
> to stick, and then turn on 0-RTT.
>
> installs of their favorite operating system and server software. People like
> things being fast, so either 0-RTT will be on by default on web servers or
> people will copy-and-paste config options. It's those deployments which I
> don't expect to get this right.
>
> even though the TLS 1.2 session was *not* resumed, merely offering it caused
> OpenSSL to lock the version. Very early on in switching Chrome from NSS to
> BoringSSL, we hit interoperability issues due to this.
> this list, myself included, has any love for this sort of configuration, but
> it is reality.)
>
> David
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Watson Ladd <[email-masked]>
Date: Tue, 21 Jun 2016 17:27:14 -0700

> get TLS 1.2 and abort as described.

Isn't 0-RTT refusable? Why not treat 1.2 negotiation as a refusal?
> > able to navigate this difficulty. We can deploy TLS 1.3, wait for
everything
> > installs of their favorite operating system and server software. People
like
> > even though the TLS 1.2 session was *not* resumed, merely offering it
caused

---

From: Bill Frantz <[email-masked]>
Date: Tue, 21 Jun 2016 17:30:21 -0700

>out the alternatives, I don't really see a better option.

Well, it seems like a browser could try TLS 1.3 without 0-RTT first.

If it connects with 1.3 non-0-RTT, then it could mark the host 
as not supporting 0-RTT for a day or so and after that time 
retry to see if the host has been fixed.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Since the IBM Selectric, keyboards have gotten
408-356-8506       | steadily worse. Now we have touchscreen keyboards.
www.pwpconsult.com | Can we make something even worse?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jun 2016 10:44:00 +1000

> Isn't 0-RTT refusable? Why not treat 1.2 negotiation as a refusal?

The problem isn't that you get a 1.2 ServerHello, it's what happens
after that.  The server is going to choke on your 0-RTT data when it
receives that instead of the client's second flight.  If it doesn't,
it's probably passing your 0-RTT ciphertext to the application as
plaintext and that's even worse.

I don't expect people to update their 1.2 implementations to be able
to ignore 0-RTT data.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jun 2016 10:45:13 +1000

On 22 June 2016 at 10:30, Bill Frantz <[email-masked]> wrote:
> If it connects with 1.3 non-0-RTT, then it could mark the host as not
> supporting 0-RTT for a day or so and after that time retry to see if the
> host has been fixed.

Yes, that is an option.  Harder to manage, but certainly possible and
(overall) preferable to falling back to 1.2.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 21 Jun 2016 19:01:19 -0700

> plaintext and that's even worse.

Why isn't 0-RTT an extension in the Client Hello to deal with this?

---

From: David Benjamin <[email-masked]>
Date: Wed, 22 Jun 2016 02:31:22 +0000

> (overall) preferable to falling back to 1.2.

Right, that (minus the statefulness because I don't care for adding state
here) was exactly my intent with the specification text. Don't change the
ClientHello version and only retry with the 0-RTT data dropped. It
explicitly says "It is NOT RECOMMENDED to retry the connection in response
to a more generic error or advertise lower versions of TLS."

The version fallback is also inevitable (unless the version negotiation is
moved elsewhere), but at least we can separate the two and someday retire
the version fallback half.

(Also, it's unlikely, but one could also imagine that the retry switches
back to hitting a 1.3-capable server. Then changing the ClientHello version
will trip fallback detection and the connection will fail again. Whereas
retrying with only 0-RTT off is a handshake that will work against 1.2 and
1.3 servers alike.)

I don't care much about the exact distribution of MAY/SHOULD/MUST, if
that's all we disagree on. If we both agree that browsers will have to
fallback, I want the mechanism written down somewhere. Because it's not
obvious that this fallback may be triggered without a version downgrade and
without a broad trigger, both of which have been problems with the past
fallbacks. (The version downgrade has clear security implications and a
broad trigger means debugging harder and, worse, it hides bugs. I've seen
many cases of server software shipping new code that flat-out doesn't work
but fallbacks are so easy to trigger that no one noticed.)

Note that, since TLS stacks typically are not in charge of creating
sockets, the implementation is the same with or without the fallback. The
TLS stack needs to return a very specific error code (<= 1.2 ServerHello in
response to 0-RTT ClientHello) and higher-level logic can condition on it
as it pleases.

David

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jun 2016 13:54:25 +1000

I've added this option to my PR.  I've also weakened the deployment
requirement to a SHOULD in light of that.  I'll learn to live with the
bad taste that leaves :)

On 22 June 2016 at 12:31, David Benjamin <[email-masked]> wrote:
> I don't care much about the exact distribution of MAY/SHOULD/MUST, if that's
> all we disagree on. If we both agree that browsers will have to fallback, I
> want the mechanism written down somewhere. Because it's not obvious that
> this fallback may be triggered without a version downgrade and without a
> broad trigger, both of which have been problems with the past fallbacks.
> (The version downgrade has clear security implications and a broad trigger
> means debugging harder and, worse, it hides bugs. I've seen many cases of
> server software shipping new code that flat-out doesn't work but fallbacks
> are so easy to trigger that no one noticed.)
>
> Note that, since TLS stacks typically are not in charge of creating sockets,
> the implementation is the same with or without the fallback. The TLS stack
> needs to return a very specific error code (<= 1.2 ServerHello in response
> to 0-RTT ClientHello) and higher-level logic can condition on it as it
> pleases.
>
> David

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jun 2016 13:58:11 +1000

> Why isn't 0-RTT an extension in the Client Hello to deal with this?

You can't stream extensions, which unfortunately is required given how
most software interacts with their TLS stack.

Let's be clear, the actual risk we're talking about is pretty-much
confined to screw-ups.  The deployment screwup where you left one
server speaking TLS 1.2 somewhere before turning 0-RTT on; and TLS
MitM, which calling a screw-up might be too positive a statement.

Of course, David is right that screw-ups like this are too common for
us to do nothing about them.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 23 Jun 2016 07:26:37 -0700

> most software interacts with their TLS stack.

A few months ago we had a lengthy discussion on the list and at TRON
about how risky 0-RTT is. This culminated in the idea that 0RTT data
should be provided through a distinct channel to the application,
along with feedback about whether it was not accepted. If we're
willing to change the interaction pattern to support that, we can
accommodate using 0RTT as an extension by gathering it all and sending
when the handshake happens. But it sounds like you are discussing a
design where the handshake fakes completion if 0-RTT is on, and at
some point later "well, i didn't actually send the data you wanted
to". Or am I missing something about the API design that is motivating
this streaming approach?

> MitM, which calling a screw-up might be too positive a statement.

Or you turned on 0-RTT and then got a security advisory resulting in
rolling back to TLS 1.2.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 23 Jun 2016 18:53:39 +0300

> to". Or am I missing something about the API design that is motivating

Sticking 0-RTT data into ClientHello also has the following problems:
- One needs to mangle ClientHello (strip an extension on receiver side)
  to obtain hash suitable for key derivation for 0-RTT. To do it any
  other way either doesn't work, or are cryptographically quite risky.
- It bloats ClientHello, something you rather not bloat, especially
  with DTLS.

And one still has to keep the data separate. For one, one can't
guarantee non-replay (no, the ticket age won't cut it, for both
fundamental and practical reasons).

The streaming appoach on client end could take forms of either
pre-collecting the data, or callback after ClientHello (and the
assorted hashes being known, altough the latter is somewhat more
dangerous...)

And BTW, that 0-RTT Finished message is quite annoying...

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Jun 2016 07:03:38 +1000

On 24 June 2016 at 00:26, Watson Ladd <[email-masked]> wrote:
> If we're
> when the handshake happens.

That's a very different constraint on the usage.  In one, you have to
identify data as being "for 0-RTT" very explicitly.  In the other, you
have to have all the data available when you send a ClientHello.  The
latter is rarely the case.

> But it sounds like you are discussing a

I don't think that's what I'm suggesting.  I don't intend to change
the signals in the current draft, namely that the handshake indicates
the presence (ClientHello) and acceptance (ServerHello) of 0-RTT.

---

From: Erik Nygren <[email-masked]>
Date: Thu, 23 Jun 2016 10:18:27 +0200

There are also very common cases of using multiple CDNs or server farms
with different capabilities but with the same host name, or of switching a
live site between platforms. As others have mentioned, the behaviors need
to be well defined and result in extra rtt rather than hard failure to
allow 0rtt to be safely deployable.

- Erik
On Jun 22, 2016 5:58 AM, "Martin Thomson" <[email-masked]> wrote:

---

From: Hubert Kario <[email-masked]>
Date: Tue, 28 Jun 2016 19:01:51 +0200

> - It bloats ClientHello, something you rather not bloat, especially

here's a crazy idea:

 - introduce a new extension which has meaning of "more data follows"
 - if the server finds it, it expects another Handshake Protocol message
   from the client
 - the client sends a new "ClientHelloExtension" message that includes
   additional data, in practice it's continuation of the extension list
   (just let's use 3 byte length fields in the structure)

the obvious downside is, that TLSv1.2 servers do not support it now

the upsides are:
 * TLSv1.2 servers can be fairly easily updated to support
   it but ignore it (just feed the next message to handshake hash, but not
   interpret it) - that fixes the upgrade scenario and allows the process to
   be performed in two steps, either of which can then be safely reversed
 * makes it possible in the future, if we are forced to, support post quantum
   crypto that requires key shares that won't fit in current extensions field

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: David Benjamin <[email-masked]>
Date: Tue, 28 Jun 2016 17:40:45 +0000

>    be performed in two steps, either of which can then be safely reversed

We could just as easily update TLS 1.2 servers to know how to skip early
data. Or, better yet, update those servers to TLS 1.3.

The problem is requiring those servers to update to begin with. At least
for browsers and the web, any solution that assumes we will get the entire
install-base updated in bounded time won't work. It took us 15 years to get
rid of SSL 3.0 and even then, with a widely publicized protocol bug and a
cutesy name, it was *still* a hassle and took a lot out of metaphorical
breakage budget.

David

> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech
> Republic_______________________________________________
> TLS mailing list
> [email-masked]

---

From: Hubert Kario <[email-masked]>
Date: Tue, 28 Jun 2016 20:26:25 +0200

> data. Or, better yet, update those servers to TLS 1.3.

you need to update the TLS1.2 server implementation only if you have a farm, are
planning to use 0-rtt and only when you plan TLS 1.3 deployment soon

> cutesy name, it was *still* a hassle and took a lot out of metaphorical

but we did, and the same thing will happen with TLS1.0, TLS1.1 and 
most likely TLS1.2

and at that time this mechanism will be usable for all servers as TLS1.3
servers will depend on it

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 28 Jun 2016 22:46:53 +0300

> the obvious downside is, that TLSv1.2 servers do not support it now

And that is the killer. Remember, what we are discussing is a feature
that server has to explicitly enable: Clients aren't going to use it
uninvited.

TLS 1.2 is going to be around for a long time (unfortunately). Including
bad implementations with serious issues.

-Ilari