Re: [TLS] DTLS 1.3 ACKs

[Eric Rescorla <[e-mail]>]

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:
> >
> > > On Sat, Jun 24, 2017 at 12:05:44PM -0700, Eric Rescorla wrote:
> > > > On Sat, Jun 24, 2017 at 9:47 AM, Ilari Liusvaara <
> > > [e-mail]>
> > > > wrote:
> > >
> > > IMO, since handshake only occurs once per connection and DTLS needs to
> > > be implemented on all kinds of constrained devices (on both client and
> > > server sides), simplicity is more important than performance. Also,
> > > packet loss estimates do not seem useful: There are far too few packets
> > > to get useful statistics.
> > >
> >
> > I think we definitely want to allow acknowledgements of subcomponents of
> > messages, because otherwise you have to retransmit the entire message,
> > which is painful in the case of the obese messages. This seems to leave
> > one with the option of acknowledging either fragments (which we then
> > need to invent labels for) or records (which already have labels
> > but need a map of RSN to fragment). My feeling is that on balance the
> > latter is a better choice, but I'll have a better sense once we've
> > implemented....
>
> 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?

-Ekr