Subject: [TLS] [DTLS] State transition after last flight

From: Hanno Becker <[email-masked]>
Date: Fri, 27 Mar 2020 16:44:40 +0000

Another comment on DTLS 1.3 draft 37.

I believe there is a slight ambiguity in the description of what
shall happen after a peer sends the last flight in a handshake.

On the one hand, the spec says:

```
   In the SENDING state, the implementation transmits the buffered
   flight of messages.  If the implementation has received one or more
   ACKs (see Section 7) from the peer, then it SHOULD omit any messages
   or message fragments which have already been ACKed.  Once the
   messages have been sent, the implementation then enters the FINISHED
   state if this is the last flight in the handshake.  Or, if the
   implementation expects to receive more messages, it sets a retransmit
   timer and then enters the WAITING state.
```

This suggests that after sending the last flight in a handshake,
a peer transitions SENDING->FINISHED.

However, there's also the following paragraph:

```
   There are four ways to exit the WAITING state:
   1.  The retransmit timer expires: the implementation transitions to
       the SENDING state, where it retransmits the flight, resets the
       retransmit timer, and returns to the WAITING state.
   2.  The implementation reads an ACK from the peer: upon receiving an
       ACK for a partial flight (as mentioned in Section 7.1), the
       implementation transitions to the SENDING state, where it
       retransmits the unacked portion of the flight, resets the
       retransmit timer, and returns to the WAITING state.  Upon
       receiving an ACK for a complete flight, the implementation
       cancels all retransmissions and either remains in WAITING, or, if
       the ACK was for the final flight, transitions to FINISHED.
```

Point 2. mentions a transition WAITING->FINISHED upon receipt of the
ACK for the last flight. This transition wouldn't be necessary if
there was an immediate SENDING->FINISHED, as suggested before.

I believe the transition SENDING->WAITING should happen
unconditionally, regardless of whether the flight is the
last one or not. I'd therefore suggest a rewording along
the following lines:

```
   In the SENDING state, the implementation transmits the buffered
   flight of messages.  If the implementation has received one or more
   ACKs (see Section 7) from the peer, then it SHOULD omit any messages
   or message fragments which have already been ACKed.  Once the
   messages have been sent, the implementation sets a retransmit
   timer and then enters the WAITING state.
```

Regards,
Hanno

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.