Re: [TLS] DTLS 1.3 ACKs

[Ilari Liusvaara <[e-mail]>]

On Sat, Jul 01, 2017 at 03:52:37PM -0700, Eric Rescorla wrote:
> On Sat, Jul 1, 2017 at 2:00 PM, Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > On Sat, Jul 01, 2017 at 10:26:17AM -0700, Eric Rescorla wrote:
> > > On Sat, Jul 1, 2017 at 10:01 AM, Ilari Liusvaara <
> > [e-mail]>
> > > wrote:
> > >
> > Just noticed that DTLS allows packing multiple independent fragments
> > into one record (and then multiple records into one packet).
> >
> > Which impiles that an implementation that only prcesses one message at
> > a time is not guaranteed to even be able to generate a valid list of
> > RSNs to ACK, in case the peer sends sufficiently twisted (but still
> > seemingly in-spec) input.
> >
> 
> I'm not following how that's true. When you decrypt, you record the received
> RSNs and when you send an ACK you send the entire list. Then when you
> finish a flight, you reset the list. Can you maybe show me a sequence of
> events that would cause an error here?

I think I figured out a case that doesn't involve peer intentionally
generating very dubious input:


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.



-Ilari