Re: [TLS] DTLS 1.3 ACKs

[Ilari Liusvaara <[e-mail]>]

On Sun, Jul 02, 2017 at 12:30:09PM -0700, Eric Rescorla wrote:
> On Sun, Jul 2, 2017 at 12:54 AM, Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > Suppose that certificate is rather big (needs spliting to four parts),
> > and:
> >
> >
> > * The server preprares its flight, giving:
> >
> > - RSN 2:0 -> EncryptedExtensions, Certificate part 1/4
> > - RSN 2:1 -> Certificate part 2/4
> > - RSN 2:2 -> Certificate part 3/4
> > - RSN 2:3 -> Certificate part 4/4, CertificateVerify, Finished.
> >
> > * Now, RSNs 2:1, 2:3 disappear, 2:0 and 2:2 make it through.
> >
> > * Client ACKs RSNs 2:0 and 2:2.
> >
> > * Server sees the ACK, and re-encrypts the offending packets:
> >
> > - RSN 2:4 -> Certificate part 2/4
> > - RSN 2:5 -> Certificate part 4/4, CertificateVerify, Finished.
> >
> > * Now, RSN 2:4 disappears, 2:5 makes it through.
> >
> > * Client is one-message at a time. It can't ACK anything new. RSNs 2:1,
> >   2:3 and 2:4 are lost.  RSN 2:5 can not be ACKed, because that would
> >   imply the client received CV and F, which it did not.
> 
> 
> 
> Thanks for clarifying your case. I think what you're assuming here is
> that when the client receives out of order handshake messages, it discards
> them rather than buffering them. Is that correct? 

Yes, that is what one message at a time means.

> In that case, yes, it
> should pretend it didn't get the records as well, and I think the right
> answer would be to not generate a new ACK and rely on the server's
> retransmission timer (which needs to run anyway).

One thing to note that there is no way for either side to say: "I
received _something_, but nothing useful". One could presumably trigger
fast retransmit on that. However, using that to trigger fast retransmits
of ServerHello might be a bit dubious...


There can also be interactions with giving up on fragment transmissions
(in order to limit memory usage).

Suppose similar case as before, but 2:1 gets lost instead of disappearing,
and is found after 2:5 is received by the client.

The client will then generate second ACK, which ACKs 2:1. The server then
receives the ACK and has no idea what the client is talking about, since
server has dropped the state. But presumably fast-retransmits 2:4 and 2:5,
now as 2:6 and 2:7 (3rd transmission for both).



-Ilari