Original text:
5.2. <del> In order to support message loss, reordering, and message fragmentation, DTLS modifies the TLS 1.3 handshake header: </del>  The first message each side transmits in each association always has message_seq = 0.  Whenever a new message is generated, the When transmitting the handshake message, the sender divides the message into a series of N contiguous data ranges.  The ranges MUST <del> NOT overlap.  The sender then creates N handshake messages, all with the same message_seq value as the original handshake message.  Each new message is labeled with the fragment_offset (the number of bytes contained in previous fragments) and the fragment_length (the length of this fragment).  The length field in all messages is the same as the length field of the original message.  An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length. Each handshake message fragment that is placed into a record MUST be delivered in a single UDP datagram. </del>  When a DTLS implementation receives a handshake message fragment corresponding to the next expected handshake message sequence number, it MUST process it, either by buffering it until it has the entire handshake message or by processing any in-order portions of the <del> message.  DTLS implementations MUST be able to handle overlapping fragment ranges.  This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes. Senders MUST NOT change handshake message bytes upon retransmission. Receivers MAY check that retransmitted bytes are identical and SHOULD abort the handshake with an "illegal_parameter" alert if the value of a byte changes. </del>  Note that as with TLS, multiple handshake messages may be placed in the same DTLS record, provided that there is room and that they are 5.9. <del> CertificateVerify and Finished messages have the same format as in TLS 1.3.  Hash calculations include entire handshake messages, including DTLS-specific fields: message_seq, fragment_offset, and fragment_length.  However, in order to remove sensitivity to handshake message fragmentation, the CertificateVerify and the Finished messages MUST be computed as if each handshake message had been sent as a single fragment following the algorithm described in Section 4.4.3 and Section 4.4.4 of TLS13, respectively. 5.10. </del> Section 7.1 of TLS13 specifies that HKDF-Expand-Label uses a label prefix of "tls13 ".  For DTLS 1.3, that label SHALL be "dtls13". This ensures key separation between DTLS 1.3 and TLS 1.3.  Note that overall label size inside of one hash iteration because "DTLS" is one letter longer than "TLS". <del> 5.11. </del>  Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake.  However, a DTLS implementation alerts are not reliably transmitted; implementation SHOULD NOT depend on receiving alerts in order to signal errors or connection closure. <del> 5.12. </del>  If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is

Reviewer comments:
This makes the handshake the same as TLS 1.3 (modulo the version numbers, which are conveniently different.
As discussed at the meeting. NAME PTAL.
This also LGTM. Let's do a brief consensus call before merging.

Revised text:
5.2.  <ins> DTLS uses the same Handshake messages as TLS 1.3.  However, prior to transmission they are converted to DTLSHandshake messages, which contain extra data needed to support message loss, reordering, and message fragmentation. In DTLS 1.3, the message transcript is computed over the original TLS 1.3-style Handshake messages without the message_seq, fragment_offset, and fragment_length values.  Note that this is a change from DTLS 1.2 where those values were included in the transcript. </ins> The first message each side transmits in each association always has message_seq = 0.  Whenever a new message is generated, the When transmitting the handshake message, the sender divides the message into a series of N contiguous data ranges.  The ranges MUST  <ins> NOT overlap.  The sender then creates N DTLSHandshake messages, all with the same message_seq value associated with the original handshake message.  Each new message is labeled with the fragment_offset (the number of bytes contained in previous fragments) and the fragment_length (the length of this fragment).  The length field in all messages is the same as the length field of the original message.  An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length.  Each handshake message fragment that is placed into a record MUST be delivered in a single UDP datagram. </ins> When a DTLS implementation receives a handshake message fragment corresponding to the next expected handshake message sequence number, it MUST process it, either by buffering it until it has the entire handshake message or by processing any in-order portions of the  <ins> message.  The transcript consists of complete TLS Handshake messages (reassembled as necessary).  Note that this requires removing the message_seq, fragment_offset, and fragment_length fields to create the Handshake structure. DTLS implementations MUST be able to handle overlapping fragment ranges.  This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes.  Senders MUST NOT change handshake message bytes upon retransmission.  Receivers MAY check that retransmitted bytes are identical and SHOULD abort the handshake with an "illegal_parameter" alert if the value of a byte changes. </ins> Note that as with TLS, multiple handshake messages may be placed in the same DTLS record, provided that there is room and that they are 5.9.  Section 7.1 of TLS13 specifies that HKDF-Expand-Label uses a label prefix of "tls13 ".  For DTLS 1.3, that label SHALL be "dtls13". This ensures key separation between DTLS 1.3 and TLS 1.3.  Note that overall label size inside of one hash iteration because "DTLS" is one letter longer than "TLS".  <ins> 5.10. </ins> Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake.  However, a DTLS implementation alerts are not reliably transmitted; implementation SHOULD NOT depend on receiving alerts in order to signal errors or connection closure.  <ins> 5.11. </ins> If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is