Subject: [TLS] Updated DTLS draft

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Mar 2017 16:41:52 -0700

I have just posted a new version of the DTLS 1.3 draft, updated for
draft-19.
It's still very rough with a lot of open issues (some of which are even
noted
in the draft), and no doubt contains egregious errors.

https://tools.ietf.org/html/draft-rescorla-tls-dtls13-01

As usual, comments welcome.

-Ekr

---

From: Matt Caswell <[email-masked]>
Date: Thu, 16 Mar 2017 23:58:49 +0000

> As usual, comments welcome.

Section 5.1

The cookie mechanism is meant to be entirely stateless on the server side.
However as it is currently specified it is not (and in fact DTLS1.2 suffers from
the same issue). The problem is that the ClientHello may be fragmented. In order
to reassemble it the server must allocate state.

In OpenSSL 1.1.0 for DTLS1.2 we require that the cookie is entirely held within
the first fragment of the ClientHello. This way the cookie can be validated
without needing to fully reassemble the message (assuming the cookie validation
function does not need any information contained within a later fragment). Only
once the cookie is validated do we then attempt to reassemble the rest of the
ClientHello.

If the cookie is not held within the first fragment then we drop the packet.

OpenSSL prior to 1.1.0 can't handle a fragmented DTLS ClientHello at
all (when running
in stateless mode - we have the option of running stateful which does work).

We kind of get away with this for DTLS1.2. The cookie is relatively
early in the CH
message (i.e. prior to ciphersuites etc). So a CH would have to be fairly
significantly fragmented for it to be a problem.

In DTLS1.3 the cookie is now (potentially) much larger and appears much later in
the ClientHello, making it much more likely that it will not fall
fully within the
first fragment. This could mean a fully stateless solution is impossible.

Matt

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Mar 2017 11:03:54 +1100

> first fragment. This could mean a fully stateless solution is impossible.

I think that it is feasible to simply require that ClientHello be
contained in a single datagram.  QUIC does this and when we did the
sums it wasn't completely unreasonable, even assuming several key
shares and a big-ish cookie.  And then we made it possible to make the
cookie even smaller in -19.

That assumes that you are willing to assume a 1k MTU, which I know
IPv4 doesn't guarantee.  I'd be OK with adding a caveat on that point
in the form of "Consequently, DTLS might not work with a small MTU".

---

From: Matt Caswell <[email-masked]>
Date: Fri, 17 Mar 2017 11:32:16 +0000

On 17 March 2017 at 00:03, Martin Thomson <[email-masked]> wrote:
> contained in a single datagram.

Yes, this is one of several solutions - although it is possibly a
retrograde step. With the assumptions that I currently have for
DTLSv1.2, even with max size cookie and session id the full cookie
will always be contained within the first 346 bytes of the record (if
I did my sums right) - which doesn't seem unreasonable. So as long as
the first fragment isn't smaller than that then, with our current
implementation, we are good.

By stating that the *whole* ClientHello must be within the first
fragment we are placing some significant restrictions on the
extensibility of the protocol and how much we can stuff into it.
Fragmenting the initial ClientHello does happen even in DTLS1.2
(before we've added extra ciphersuites and extensions for DTLSv1.3) -
we had a recent report of someone having problems when receiving
fragmented ClientHellos:

https://mta.openssl.org/pipermail/openssl-users/2017-February/005332.html

Another option is to say that the cookie extension must be fully
contained within the first fragment - which avoids the above
extensibility concerns. This option is much better but is still
retrograde from DTLS1.2 because the extensions block appears later in
the ClientHello (most importantly after ciphersuites, which could be
quite long).

A third option is to retain use of the cookie field in DTLSv1.3 and
require that the first fragment contains it, i.e. the server sends the
cookie in the HRR and the client reflects it back in the cookie field.
This would solve all of the above problems but introduces a new one -
the TLSv1.3 max cookie length is bigger than the length of the cookie
field. There are a couple of ways around that that I can think of -
the simplest being that DTLS1.3 could restrict the max cookie length -
but that in itself could cause some problems due to the fact that more
data needs to be stored in the cookie for DTLS1.3 (i.e. the transcript
hash).

>  QUIC does this and when we did the

Did we? How did we do that?

Matt

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 17 Mar 2017 04:45:29 -0700

> Did we? How did we do that?

By making the hash state you needed to store a hash value rather than a
hash checkpoint.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 17 Mar 2017 15:26:22 +0200

> we had a recent report of someone having problems when receiving

AFAIK, that mostly becomes problem only with group 260 (fortunately,
I don't think anyone is crazy enough to use that!) with its 1024-byte
public key, or various PQ exchanges (and there even relatively
compact ones can easily be even larger).

But of course, PQ might become rather important in future.

Also, 1200 bytes of packet payload should be feasible. That's
well within IPv6 minMTU, and also within reach of virtually all
IPv4 links.

> the ClientHello (most importantly after ciphersuites, which could be

There's also the supported versions extension which is important.

As for long ciphersuite lists, deimplementing some garbage would fix
that.

> data needs to be stored in the cookie for DTLS1.3 (i.e. the transcript

Well, here's one cookie design:

- Key tag: 4 bytes
- Encryption prelude: 32 bytes
- Timestamp: 8 bytes
- Peer address: 16 bytes
- Cipher: 2 bytes
- Group: 2 bytes
- Client Hello hash: 48 bytes
- Authentication tag: 16 bytes

Total: 128 bytes (could be shrunk to 112 by using prelude as tag, at
cost of more complex code).

-Ilari.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 18 Mar 2017 09:49:09 +1100

> well within IPv6 minMTU, and also within reach of virtually all

This was the rationale in QUIC.  Most links support an MTU of that
size, if only because they have to if they hope to ever support IPv6.