Subject: [TLS] DTLS 1.3 ACKs

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Jun 2017 07:57:21 -0700

Hi folks,

https://github.com/tlswg/dtls13-spec/pull/9

I have just posted a PR to implement ACKs, largely as we discussed in
Chicago.
Here's the pull comment:

I have taken a slightly different approach here than we discussed
in Chicago. Specifically:

   -

   ACKs are not handshake messages but a new content type. This
   avoids the need to ack ACKs or worry about reassembling
   when ACKs are lost.
   -

   The receipt of a flight also counts as an implicit ACK and
   so you shouldn't ACK full flights. I tried removing this
   feature but it leads to weird anomalies where you have
   two flights you should be retransmitting if the ACKs get
   lost.
   -

   ACKs are always encrypted with the then-current key.
   -

   I also removed the rule that you don't stop retransmitting
   when you receive a partial flight. That was intended to have
   fast retransmission for missing messages because the retransmit
   of flight A triggered retransmission of partial flight B, but
   ACKs serve this purpose

Comments welcome.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 24 Jun 2017 19:47:49 +0300

>    of flight A triggered retransmission of partial flight B, but

I think ACKing a post-handshake CertificateRequest would make sense, if
the response can't be generated immediately (e.g., prompting user to
select a certificate).

It seems ACKs work in terms of RSNs. This generates a weirdness that
a fragment can be known with multiple IDs, in case a packet gets
delayed enough to trigger retransmission but the original is then
accepted. But OTOH, retransmission at fragment granularity is useful
with potentially "obese" messages like Certificate.

And what is the precise interaction between restarts, 0-RTT and message
sequence numbers on client side? As far as I can tell,
end_of_early_data is always client message_seq=1, and appears only iff
server accepts 0-RTT. Restart client_hello is also always client
message_sseq=1.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Jun 2017 12:05:44 -0700

> the response can't be generated immediately (e.g., prompting user to

That's a good point.

> with potentially "obese" messages like Certificate.

This is the calculation I made as well. Note that removing aliasing in this
fashion actually is useful in measuring packet loss (this is what QUIC
does).

> server accepts 0-RTT. Restart client_hello is also always client

That seems correct to me.

-Ekr