Draft: draft-ietf-tls-dtls13

Commentary: 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 should n'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 do n'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 .
Paragraph (version A):
A new ACK message has been added for reliable message delivery of
certain handshake messages.
Paragraph (version B):
A new ACK content type has been added for reliable message
delivery of handshake messages.
Paragraph (version B):
The first message each side transmits in each association always has
message_seq = 0.  Whenever a new message is generated, the
message_seq value is incremented by one.  When a message is
retransmitted, the old message_seq value is re-used, i.e., not
incremented.  From the perspective of the DTLS record layer, the
retransmission is a new record.  This record will have a new
DTLSPlaintext.sequence_number value.
Paragraph (version A):
The first message each side transmits in each handshake always has
message_seq = 0.  Whenever a new message is generated, the
message_seq value is incremented by one.  When a message is
retransmitted, the old message_seq value is re-used, i.e., not
incremented.
Paragraph (version A):
From the perspective of the DTLS record layer, the retransmission is
a new record.  This record will have a new
DTLSPlaintext.sequence_number value.
Paragraph (version A):
The ACK handshake message is used by an endpoint to respond to a
message where the TLS 1.3 handshake does not foresee such return
message.  With the use of the ACK message the sender is able to
determine whether a transmitted request has been lost and needs to be
retransmitted.  Since the ACK message does not contain any
correlation information the sender MUST only have one such message
outstanding at a time.
Paragraph (version A):
DTLS messages are grouped into a series of message flights, according
to the diagrams below.  Although each flight of messages may consist
of a number of messages, they should be viewed as monolithic for the
purpose of timeout and retransmission.
Paragraph (version B):
DTLS messages are grouped into a series of message flights, according
to the diagrams below.
Paragraph (version A):
In the SENDING state, the implementation transmits the buffered
flight of messages.  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.
Paragraph (version B):
In the SENDING state, the implementation transmits the buffered
flight of messages.  If the implementation has received one or more
ACKs ack-msg 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.
Paragraph (version B):
The implementation reads a ACK from the peer: upon receiving an
ACK for a partial flight (as mentioned in sending-acks, 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.
Paragraph (version A):
The implementation receives the next flight of messages: if this
is the final flight of messages, the implementation transitions to
FINISHED.  If the implementation needs to send a new flight, it
transitions to the PREPARING state.  Partial reads (whether
partial messages or only some of the messages in the flight) do
not cause state transitions or timer resets.
Paragraph (version B):
The implementation receives some or all next flight of messages:
if this is the final flight of messages, the implementation
transitions to FINISHED.  If the implementation needs to send a
new flight, it transitions to the PREPARING state.  Partial reads
(whether partial messages or only some of the messages in the
flight) may also trigger the implementation to send an ACK, as
described in sending-acks.
Paragraph (version B):
The following is an example of a handshake with lost packets and
retransmissions.
Paragraph (version B):
The ACK message is used by an endpoint to indicate handshake-
containing the TLS records it has received from the other side.  ACK
is not a handshake message but is rather a separate content type,
with code point TBD.  This avoids it consuming space in the handshake
message sequence.  Note that ACKs can still be piggybacked on the
same UDP datagram as handshake records.
Paragraph (version B):
a list of the records containing handshake messages in the current
flight which the endpoint has received, in numerically increasing
order.  ACKs only cover the current outstanding flight (this is
possible because DTLS is generally a lockstep protocol).  Thus, an
ACK from the server would not cover both the ClientHello and the
client's Certificate.  Implementations can accomplish this by
clearing their ACK list upon receiving the start of the next
flight.
Paragraph (version B):
ACK records MUST be sent with an epoch that is equal to or higher
than the record which is being acknowledged.  Implementations SHOULD
simply use the current key.
Paragraph (version B):
In addition, implementations MUST send ACKs upon receiving all of any
flight which they do not respond to with their own messages.
Specifically, this means the client's final flight of the main
handshake and the server's transmission of the NewSessionTicket.
ACKs SHOULD NOT be sent for other complete flights because they are
implicitly acknowledged by the receipt of the next flight, which
generally immediately follows the flight.
Paragraph (version B):
ACKs MUST NOT be sent for other records of any content type other
than handshake.
Paragraph (version B):
When an implementation receives an ACK, it SHOULD record that the
messages or message fragments sent in the records being ACKed were
received and omit them from any future retransmissions.  Upon receipt
of an ACK for only some messages from a flight, an implementation
SHOULD retransmit the remaining messages or fragments.  Note that
this requires implementations to track which messages appear in which
records.  Once all the messages in a flight have been acknowledged,
the implemenation MUST cancel all retransmissions of that flight.  As
noted above, the receipt of any packet responding to a given flight
MUST be taken as an implicit ACK for the entire flight.