Draft: draft-ietf-tls-dtls13

Commentary: This makes the handshake the same as TLS 1.3 ( modulo the version numbers , which are conveniently different . 
 As discussed at the meeting . PTAL . 
 This also LGTM . Let 's do a brief consensus call before merging .
Paragraph (version B):
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.
Paragraph (version B):
In DTLS 1.3, the message transcript is computed over the original TLS
fragment_offset, and fragment_length values.  Note that this is a
change from DTLS 1.2 where those values were included in the
transcript.
Paragraph (version A):
When transmitting the handshake message, the sender divides the
message into a series of N contiguous data ranges.  The ranges MUST
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.
Paragraph (version A):
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
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.
Paragraph (version B):
When transmitting the handshake message, the sender divides the
message into a series of N contiguous data ranges.  The ranges MUST
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.
Paragraph (version B):
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
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.
Paragraph (version B):
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.
Paragraph (version A):
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.