Subject: [TLS] Extensions and state during a resume

From: Bill Cox <[email-masked]>
Date: Thu, 21 Apr 2016 06:12:40 -0700

In TLS 1.3, do we renegotiate all extensions on a PSK resumption, or do we
assume the full state of the prior connection is remembered (either in the
ticket, or in session caches)?  Alternatively, do we let some extensions
require remembered state while other extensions require renegotiation?
This was a bit of a mess in TLS 1.2, IMO.

In TLS 1.3 we have the concept of the resume master secret (RMS).  Ideally,
this is all that would be needed, in addition to the new ticket, to
resume.  This would add some security in that the full session state would
not need to be remembered, and some simplification in that the client and
server may not require a full session cache.  This would make it simpler
and safer to write the RMS and ticket to disk, considerably improving
resumption rates.  The RMS is also a candidate for storing more securely
than a full session state.

OTOH, the spec appears to assume the security parameters from the initial
connection are inherited on resumed connections, and this requires
potentially a lot of state from multiple negotiated extensions to be
remembered.  This means the client would have to write the entire session
cache to disk to achieve high resumption rates, which is less safe and more
complex.

Thanks,
Bill

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 21 Apr 2016 17:40:49 +0300

> This was a bit of a mess in TLS 1.2, IMO.

My understanding is that TLS 1.3 replaces the entiere resumption with
what is essentially dynamic PSK provosioning. So state to be remembered
is to be kept at minimum.

Certainly remembering extensions from past handshake would be quite
nasty to implement (especially correctly).

-Ilari

---

From: Bill Cox <[email-masked]>
Date: Thu, 21 Apr 2016 08:05:53 -0700

> nasty to implement (especially correctly).

That sounds reasonable, except for PSK 0-RTT resumption.  In that case, the
first flight of data is protected with whatever extensions the client
decides to use on its own.  I think it should be all the extensions
negotiated on the original handshake in this case, which requires a
client-side cache.

In this case, I think the client should replace the secrets in the
serialized session state with the RMS, to protect the prior connection
data.  I also think the client should write this session state to disk,
preferably encrypted, since this results in a huge reduction in 1-RTT
handshakes.

If we accept the need for a client-side cache, then it seems reasonable to
expect that either the server session state is in the ticket for stateless
servers, or in a server-side cache for servers with replay protection.

If all this is basically acceptable, then should we simply mandate that all
extension data must be remembered, and that extensions are not sent on
resumes unless they specifically are needed to change the state on the new
connection?

This has implications on custom extension APIs.  There seem to be very few
uses of it today in OpenSSL, and I think one reason is that extensions
generally need to have remembered state, such as whether or not it was
negotiated.  I think we may want to look into enhancing the API to allow
custom extensions to serialize custom state to the session state.

Bill

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 21 Apr 2016 18:28:45 +0300

> negotiated on the original handshake in this case, which requires a

IMO, there is no "PSK 0-RTT resumption", it is just PSK 0-RTT with
dynamically provisioned PSK.
 
> preferably encrypted, since this results in a huge reduction in 1-RTT

Obviously, the client shouldn't save any secrets from connection except
for RMS, and no extension should require it to do so.

> servers, or in a server-side cache for servers with replay protection.

The session state is source of subtle bugs.

> resumes unless they specifically are needed to change the state on the new

The extension data can not be guaranted to be preserved. The client has to
send extensions it wants anyway.

> custom extensions to serialize custom state to the session state.

Ever seen what kind of mess the interaction between extensions and re-
sumption is? E.g. the interaction between ALPN and resumption is not what
one could quickly think based of general type of ALPN extension...

-Ilari

---

From: Bill Cox <[email-masked]>
Date: Thu, 21 Apr 2016 09:02:17 -0700

> dynamically provisioned PSK.

This sounds good, but there are exceptions.  Any extension that needs to be
negotiated that impacts security needs to be remembered for a PSK 0-RTT
resume.

> The session state is source of subtle bugs.

Agreed.  I'm no TLS expert, but I've already experienced significant pain
resulting from these bugs.

> send extensions it wants anyway.

Good point.  The client has to send extensions in the handshake anyway, in
case we fall back to 1-RTT.

> one could quickly think based of general type of ALPN extension...

Yes, I've worked with EMS and session resumption.  This is very messy stuff
which makes me long for the relative simplicity of QUIC crypto.  Without
remembering the APLN negotiation results from the 1-RTT handshake, should
the client send first flight application data over HTTP/1 or HTTP/2?

What if we merged the server-config feature from the ECDH 0-RTT mode into
the PSK mode?  Most of the data that needs to be remembered from the 1-RTT
handshake is semi-static, and suitable for a server-config.  In particular,
I would like to know about the server:

- Does it support replay protection?  This impacts whether or not I would
use client certs, for example.
- Does it support HTTP/2?  I want to encode my first flight data in HTTP/2
if possible.

What do you think?

Bill

---

From: Bill Cox <[email-masked]>
Date: Thu, 21 Apr 2016 09:32:30 -0700

I'm just going through an example which is related to what I work on, which
currently is token binding.  Client certs are very similar.

If client certs (or token binding) were supported by the server, as well as
replay protection, then I would prefer to send the ClientVerify message in
a PSK 0-RTT resume.  Without replay protection, I would prefer to avoid
client certs and token binding.

Basically, I think we have two choices for remembering server feature
support, which is required when doing PSK 0-RTT:

1) negotiate all supported features in the 1-RTT handshake and use session
caches to remember the results
2) use server configs instead

Given all the bugs resulting from 1), I think I prefer 2).

Bill

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 21 Apr 2016 20:54:31 +0300

> client certs and token binding.

0-RTT client certificate auth is very annoying to implement properly. In
fact, any handshake messages in 0-RTT causes the 0-RTT to couple into
the main handshake state machine. This causes all sorts of less than fun
problems with implementing it properly.

Also, 1-RTT client certs with GDHE-PSK are much less annoying, but wonder
how many will get that right, given that TLS 1.2 doesn't support that,
only client certs for GDHE-CERT...

> Given all the bugs resulting from 1), I think I prefer 2).

3) Eliminate any coupling between connections to the extent possible.

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Thu, 21 Apr 2016 18:47:02 +0000

> In TLS 1.3 we have the concept of the resume master secret (RMS).  Ideally, this is all that would be needed, in addition to the new ticket, to resume.
Even without any extensions, the client needs to remember certain things about the TLS session, e.g. negotiated protocol version, cipher suite, curve, server cert, session lifetime info... Some of this could be stored per server, rather than per session, but that's implementation-specific details. I agree that we should minimize protocol features (including extensions) that increase the size of the session state, esp. on the server side.

> This would make it simpler and safer to write the RMS and ticket to disk, considerably improving resumption rates.  The RMS is also a candidate for storing more securely than a full session state.
MS TLS stack does not currently store session cache items or resumptions secrets on disk, so I'm curious: why is it easier to store and protect RMS alone, rather than storing a session cache item that contains RMS? Isn't it just a BLOB in either case, from the perspective of protected storage?

Thanks,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
Sent: Thursday, April 21, 2016 10:55 AM
To: Bill Cox <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Extensions and state during a resume

-Ilari

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

---

From: Bill Cox <[email-masked]>
Date: Thu, 21 Apr 2016 11:55:07 -0700

I was able to chat a bit with someone who had been to the recent IETF
meeting and has more insight into the current state of things.  The most
important insight is that it seems that TLS 1.3 will be going with a TLS
1.2 style serialized session state.  Server-configs mean the server offers
security parameters and the client chooses, which is backwards from TLS
1.2.  That would be too hard to merge into the existing TLS code base.

> problems with implementing it properly.

Yep.  Unfortunately it looks like this particular form of TLS complexity is
going to be inherited in TLS 1.3.  Channel ID is also a very complex
addition, which is one motivation for moving to token binding, to get that
complexity out of the TLS state machine.

> 3) Eliminate any coupling between connections to the extent possible.

Looks like we're going with 1).  It's ugly, but I think I understand the
motivation now.  Maybe we can finally dump the coupling between connections
in TLS 2.0 :)

I am very concerned that the default mode of operation for popular web
server software might be stateless PSK 0-RTT.  My main concern is that most
web sites out there have too little testing for resistance to infinite
replay of 0-RTT requests.  My preference would be for the default mode to
be 1-RTT only, and if admins enable 0-RTT, replay protection would be
enabled by default.  Turning on 0-RTT and turning off replay protection
should be a conscious and well-informed choice, IMO.

It also sounds like the proposal to inform the client in the new ticket
whether or not the server supports replay is not popular, but that the
client will most likely be informed of whether the server supports PSK
0-RTT resumption.  I think servers supporting replay protection should be
allowed (but not required) to let authenticated clients connect with 0-RTT
resumption, and servers without replay protection should only offer
authenticated clients 1-RTT resumption, or drop client authentication.

Bill

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Apr 2016 08:01:11 +1000

> is to be kept at minimum.

This is a point that is not clear, but here's my view on it:

Unlike pure PSK, using PSK for resumption needs to always come with
enough information to fall back to a full handshake.  This means
signaling a non-PSK cipher suite and all the extensions that you would
normally include in a ClientHello.  Thus, anything that depends on the
state of those extensions is covered.  (For the most part, those
extensions only apply to subsequent connections.)

As for what you need to remember for the 0-RTT data.  Well, by default
that's everything, unless you know that you can forget it.

We agreed at the meeting that 0-RTT data would not explicitly signal
parameters, so peers would have to remember things from the previous
session.  That means that you will need to bind everything you need
into the stored state.  That includes any extensions that aren't
already bound to the keys or are only relevant to the 1-RTT.  You
don't have to remember the old key_share extension, and
certificate_status[_v2].

Client authentication is one thing that you can remember.  Of course,
if you know you don't need it, don't save it.  If you don't want it,
don't save it.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 22 Apr 2016 15:19:21 +0300

> don't have to remember the old key_share extension, and

What exactly needs to be remembered in dynamically created state (for
baseline TLS 1.3 and all extensions currently defined allowed therein)?

Looking at the extension list, I only see the following at coupling
level for PSK 0-RTT data:

- RMS (which acts as PSK key).
- Ciphersuites allowed.
- ALPN (ALPN needs to redefined for this!)

(And a few more at non-coupled level, like identities of both peers).

Also, what should happen if you try to do PSK 0-RTT with static PSK?
In practicular, with what application protocol the data is interpretted
as?

And for subsequent handshake and operation, I consider any implicit
extensions at TLS level to be nasty source of bugs (possibly even
breaking protocol-level security)..

-Ilari

---

From: Bill Cox <[email-masked]>
Date: Fri, 22 Apr 2016 06:13:25 -0700

> - ALPN (ALPN needs to redefined for this!)

There is more state that must be remembered:

- client authentication status (if client certs are used)
- most likely the EKM seed from the 1-RTT connection
- whether 0-RTT is supported

The list will likely grow over time much like it has in the past.  My guess
is that most clients will simply reuse the existing session cache from TLS
1.2.  All state will be remembered.

Bill

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 22 Apr 2016 16:49:30 +0300

> - client authentication status (if client certs are used)

Included in "identities of peers".

> - most likely the EKM seed from the 1-RTT connection

Looks dangerous to me. There is at least one standards track protocol
that would interact badly with (destroy forward security).

> - whether 0-RTT is supported

Oh yeah...

> 1.2.  All state will be remembered.

If I was to implement this, I would implement it as dynamic provisioning of
PSKs (because that it is) with fixed-schema database table (not SQL tho) for
PSK data. And then never resume sessions but treat every connection as in-
depedently as possible (PSK priorized over GDHE-CERT).

That is, anything remembered should only be used for 0-RTT interpretation
anything else looks to be a nasty trap (at least don't assume it will be
implemented correctly!).. 

Also thanks for flashbacks from realizing that TLS 1.2 session resumption is
much nastier than what I thought, and I already considered it nasty enough to
put choice DJB quote about TLS as code comment...

-Ilari

---

From: Bill Cox <[email-masked]>
Date: Fri, 22 Apr 2016 07:29:32 -0700

> put choice DJB quote about TLS as code comment...

I think we're in agreement now.  Imagine all that code dedicated to session
state interaction with extensions, and now instead of a clean slate TLS
2.0, do a TLS 1.3 that is as different as possible from TLS 1.2 without
actually requiring rewriting the code...  It will be awesome to have the
speed of 0-RTT in TLS 1.3, but I look forward to the TLS 2.0 effort.

Bill