Subject: [TLS] DTLS 1.3 ACKs

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Oct 2017 18:14:33 -0700

We now have DTLS 1.3 implemented in NSS, which went pretty cleanly.

The one thing we ran into was the potential need to ACK in cases where you
can't process *any* records (e.g., you receive what's actually EE, but you
can't decrypt it). In this case, you want to send an empty ACK.

See PR:
https://github.com/tlswg/dtls13-spec/pull/14

This will be going into -02 modulo big objections.
-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Oct 2017 16:59:29 +0300

> We now have DTLS 1.3 implemented in NSS, which went pretty cleanly.

What is the _worst_ case memory usage (both sending and receving) for
handling the acknowledgements and guaranteeing forward progress in all
reasonable cases?

There is not much discussion in the draft about memory usage of ACK
handling and how to limit it.

This matters very much if using DTLS for (effectively) small devices,
which are seemingly a major usecase.

One strategy I see on receive side is just keeping fixed 150 RSN ack
buffer on receive side, reset for every flight, and if this ever
overflows, abort the connection. Maintaining this buffer needs 1201
bytes of memory (the odd byte is for occupancy count). On limited
devices, one might shrink this buffer further.

And then have per-byte bitmasks and unreceived count for buffered
handshake message (eats n/8 + few bytes for n byte message).

On sending side, one resource-limited strategy is to keep newest
retransmit number and acknowledged flag for each 480 byte chunk.
Unencrypted records can be special. This eats (8 bytes for each starting
480 bytes in each message in flight buffer plus about two dozen fixed
bytes)...

With 480-byte chunking, single-chunk packets would confortably fit
in IPv4 minMTU, and double-chunk/double-length packets would
comfortably fit in IPv6 minMTU.

The sender-side strategy can not handle receivers that signal maximum
fragment size below 512 bytes or so... Actually, I don't think maximum
fragment size is actually useful in DTLS, what you want for DTLS is
maximum *packet* size.  Also, this strategy limits the flight size,
but should be enough for anything reasonable.

> https://github.com/tlswg/dtls13-spec/pull/14

The ACK structure definition does not seem to allow empty ACK.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Oct 2017 08:40:55 +1100

> handling the acknowledgements and guaranteeing forward progress in all

Exact numbers are difficult, but in general, the sender needs to
remember an entire flight, plus the records that it sends and the
parts of the flight that were in those records.  In our
implementation, we use ~35 octets per handshake message fragment,
which could be reduced, possibly by quite a bit.  Worst case is with
large messages and small MTU/record limit with lots of packet loss,
where you might have a fairly large number of these records to track
what was sent.  That is in addition to whatever messages you send,
which you have to remember once they are constructed (Certificate
being a real wild card here, of course).  As you say, you can limit
this by ensuring that you limit the size of messages and the number of
fragments that you have outstanding.

The receiver really only needs to track the data it receives.  We
(currently) pretend not to receive packets if they aren't contiguous
with the data we have, so our outstanding memory is at most one
handshake message and a couple of status variables.  Once the
handshake message is complete, we process it.  If we had progressive
parsing and processing, that might go lower, but we don't target
constrained devices.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 25 Oct 2017 08:48:56 +0200

> https://github.com/tlswg/dtls13-spec/pull/14

Would it make sense to spell out the goals (and maybe some motivation)
for the DTLS 1.3 revision in the draft? The TLS WG charter contains the
goals for the TLS 1.3 revision but changes in DTLS like the ACK
although nice, seem to be unrelated to them.

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 25 Oct 2017 12:24:27 +0300

> although nice, seem to be unrelated to them.

The ACK message has two goals:

The more important one: To acknowledge some flights that do not have
reply messages. NewSessionTicket is especially relevant case. Also
client authentication flights.

The less important one: To reduce amount that needs to be retransmitted
on packet loss.

-Ilari