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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
