1413368 - KeyUpdate for DTLS 1.3

Status: RESOLVED DUPLICATE of bug 1797503

(NSS :: Libraries, enhancement, P3)

Description

[Martin Thomson [:mt:]]

This requires a few changes to the spec before we can conclude on the design.

Comment 1

[Eric Rescorla (:ekr)]

What changes are those? I believe that the spec is complete on this point.

Comment 2

[Martin Thomson [:mt:]]

We need to agree on when a KeyUpdate is applied.  If we go with the current design, there is the potential for entire round trips of datagrams to be dropped.  It's true that the existing logic for retransmission will work, but the design is unnecessarily exposed to packet loss.

1. A sends KeyUpdate, switches to new keys.
2. KeyUpdate is lost.
3. A eventually re-sends KeyUpdate.

In between steps 1 and 3, all the records that A transmits have to be dropped by B.

Even if the KeyUpdate isn't lost, you still have the possibility that the records sent after the KeyUpdate are reordered so that they arrive before the KeyUpdate.  Those would have to be dropped too.

I think that an endpoint should wait until the KeyUpdate is acknowledged before switching write keys.  At the reader we would install keys for receiving when we receive a KeyUpdate, but retain the old keys until the holddown timer pops (if we aren't sending a KeyUpdate of our own), or when we receive an ACK for our own KeyUpdate.

Comment 3

[Eric Rescorla (:ekr)]

I made comments in the CL.

I'm aware of this case, of course, but this is effectively the same situation as applies with TCP, and the peer can (a) buffer or (b) look ahead in the epoch. So, rather than deviate from the TLS behavior, I think it's better to tell implementations how they can behave in these cases.

Comment 4

[Martin Thomson [:mt:]]

I assumed that you were comfortable with a deferred update based on your rejection of my earlier DTLS KeyUpdate patch, which did (b).  I think that we should deviate from the TLS model.  Buffering doesn't make any sense to me (we use DTLS because we want timely delivery), and a look ahead is annoying to implement for all the reasons you didn't like my earlier patch.