Re: [TLS] DTLS 1.3 ACKs

[Eric Rescorla <[e-mail]>]

On Sat, Jun 24, 2017 at 9:47 AM, Ilari Liusvaara <[e-mail]>
wrote:

> On Sat, Jun 24, 2017 at 07:57:21AM -0700, Eric Rescorla wrote:
> > 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.
>
> 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).
>

That's a good point.


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

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



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

That seems correct to me.

-Ekr