Re: [TLS] DTLS 1.3 ACKs

[Eric Rescorla <[e-mail]>]

On Sun, Jul 2, 2017 at 1:13 PM, Ilari Liusvaara <[e-mail]>
wrote:

> 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.
>

Well it could mean other things. That's why I asked.


> 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".


Well, we could in fact use an ACK for that, which is basically what TCP
does.


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).
>

It's not clear to me it's useful for implementations to delete state in
this case.

-Ekr


>
>
> -Ilari
>