Subject: [Dtls-iot] Session resumption (was: [TLS] New draft: draft-rescorla-tls13-new-flows-01)

From: Klaus Hartke <[email-masked]>
Date: Tue, 25 Feb 2014 15:06:50 +0100

Eric Rescorla wrote:
> - There is no currently defined support for any kind of resumption.
> We need to decide if resumption is still an important feature in light
> of the trend towards more PFS and faster processors.  I'm particularly
> looking for input from the IoT/DICE guys here.

I'm not really sure what's being done in existing deployments, but I'd
be inclined to say that session resumption is not really needed.

The feature allows a client to create a session and get a Session ID.
This Session ID can be used by the client to duplicate the session or
to later resume the previous session. The server has to store the
session state with the Session ID in a cache.

- Duplicate the session: I'd assume that a constrained node typically
maintains only one session to a given destination. For example, with
CoAP a session can be used for as many requests as needed; CoAP does
not need a new session for every request.

- Resume a previous session: I'm not exactly sure what a client should
do when it has established a session but hasn't used it for a while.
For example, if the client has created a session to make a CoAP
request and later wants to make another request, should it first
resume the session? Or just try to use it, get an alert, and then
resume it? Or try to use it, get an alert, and create a new session?
I'd say that the server either has the session state still (then the
client should be able to make the request right away without resuming
the session) or it doesn't (then the client has to create a new
session).

Are there other use cases?
Are my assumptions valid?
Am I missing something?
What's implemented in existing IoT DTLS deployments?

Best regards,
Klaus

---------- Forwarded message ----------
From: Eric Rescorla <[email-masked]>
Date: 19 February 2014 21:40
Subject: [TLS] New draft: draft-rescorla-tls13-new-flows-01
To: "[email-masked]" <[email-masked]>

Folks,

I have prepared a new version of the TLS 1.3 flows document which
should appear in the repository shortly and in the meantime can be
found at:

https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.txt

This version fleshes out a "recommended" set of flows:

- 2-RTT where the client has no knowledge of the
  server's capabilities.

- 1-RTT where the client knows the server's semi-permanent
  DHE/ECDHE key pair.

- 0-RTT where the client and the server have shared anti-replay
  state.

There are still a number of open issues, but this should be clear
enough to see the direction I am trying to go. These flows are
structured so that the 1-RTT case is the base case with the 2-RTT and
0-RTT versions being variants of the basic 1-RTT handshake. All
variants encrypt the client extensions that are not required
to define the cryptographic processing (e.g., SNI is encrypted
but curve negotiation is not).

I think the high order bit here is whether we want to have
encrypted SNI, because that dictates the position of the DHE
exchanges with respect to the server's messages.

There are three options here:

- Never
- Sometimes
- Always

The flows in this draft take the position of "Always" which is
simple. "Never" is actually simpler. "Sometimes" is the most
complicated.  There are two cases where we could shave off latency if
we were willing to disclose the SNI to passive attackers (and in cases
where the client and server have never talked before.) My sense of
recent discussion is that people feel it's important to have modes
that protect SNI even if those are not the only modes. However, that
means that if we want to have non-SNI protecting modes, they are
additional complexity. Please let me know if I have misread the WG
here.

Here are some other things to keep in mind as you read the document.

- Per my sense of the list, I have totally removed static RSA.  If
people strongly object to that, please speak up and let me know.

- There has been no real security analysis of this material other than
at the hand-wavy level. We clearly need that, but the first thing we
need is to be clear on whether this is approximately the right set of
points in the complexity/performance/privacy tradeoff space and then
make sure that the security properties are correct. So, if you see
something that looks wrong or even grievously wrong, don't panic (but
do point it out).

- There is no currently defined support for any kind of resumption.
We need to decide if resumption is still an important feature in light
of the trend towards more PFS and faster processors.  I'm particularly
looking for input from the IoT/DICE guys here.

- We will probably need to work out some of the details for DTLS, but
I wanted to get TLS nailed down first.

- We also need to do some work on the symmetric crypto, e.g., to make
encrypt-then-MAC the default, perhaps to deprecate some ciphers,
compression, etc. I haven't forgotten that, but I want to deal with
the handshakes first.

- As before, this incorporates ideas from a lot of different people
(and many times the same idea from different people). If you think
you should acknowledged in the text and/or acknowledgements
differently, please let me know.

Thanks and comments welcome
-Ekr