Draft: draft-ietf-tls-dtls13

Commentary: Well , clients can recover by tearing down the connection and starting over . 
 Sure , sure . I think this was in the context of a " single " connection . Perhaps it 's not that important to clarify ? 
 I 'll add text . 
 I think the only comment that 's left to be addressed is this : Perhaps what 's missing is precisely that clarifying statement . Namely , that clients which find themselves in such a situation can not recover .
Paragraph (version B):
This 64-bit value is used in the ACK message as well as in the
"record_sequence_number" input to the AEAD function.
Paragraph (version A):
The received packet counter for a session MUST be initialized to zero
when that session is established.  For each received record, the
receiver MUST verify that the record contains a sequence number that
does not duplicate the sequence number of any other record received
during the lifetime of the session.  This check SHOULD happen after
deprotecting the packet; otherwise the packet discard might itself
serve as a timing channel for the sequence number.
Paragraph (version B):
The received packet counter for a session MUST be initialized to zero
when that session is established.  For each received record, the
receiver MUST verify that the record contains a sequence number that
does not duplicate the sequence number of any other record received
during the lifetime of the session.  This check SHOULD happen after
deprotecting the packet; otherwise the packet discard might itself
serve as a timing channel for the record number.  Note that
decompressing the records number is still a potential timing channel
for the record number, though a less powerful one than whether it was
deprotected.
Paragraph (version A):
DTLS implementations do not use the TLS 1.3 "compatibility mode"
described in Section D.4 of TLS13.  DTLS servers MUST NOT echo the
"session_id" value from the client and endpoints MUST NOT send
ChangeCipherSpec messages.  Note however that implementations MUST
ignore ChangeCipherSpec messages received in unprotected records.
Paragraph (version B):
DTLS implementations do not use the TLS 1.3 "compatibility mode"
described in Section D.4 of TLS13.  DTLS servers MUST NOT echo the
"session_id" value from the client and endpoints MUST NOT send
ChangeCipherSpec messages.
Paragraph (version A):
In previous versions of DTLS, this field was used for version
negotiation and represented the highest version number supported
by the client.  Experience has shown that many servers do not
properly implement version negotiation, leading to "version
intolerance" in which the server rejects an otherwise acceptable
ClientHello with a version number higher than it supports.  In
DTLS 1.3, the client indicates its version preferences in the
"supported_versions" extension (see Section 4.2.1 of TLS13) and
the legacy_version field MUST be set to {254, 253}, which was the
version number for DTLS 1.2.
Paragraph (version B):
In previous versions of DTLS, this field was used for version
negotiation and represented the highest version number supported
by the client.  Experience has shown that many servers do not
properly implement version negotiation, leading to "version
intolerance" in which the server rejects an otherwise acceptable
ClientHello with a version number higher than it supports.  In
DTLS 1.3, the client indicates its version preferences in the
"supported_versions" extension (see Section 4.2.1 of TLS13) and
the legacy_version field MUST be set to {254, 253}, which was the
version number for DTLS 1.2.  The version fields for DTLS 1.0 and
DTLS 1.2 are 0xfeff and 0xfefd (to match the wire versions) but
the version field for DTLS 1.3 is 0x0304.
Paragraph (version A):
When transmitting the handshake message, the sender divides the
message into a series of N contiguous data ranges.  These ranges MUST
NOT be larger than the maximum handshake fragment size and MUST
jointly contain the entire handshake message.  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.
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 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 range MUST be delivered in a single packet.
Paragraph (version B):
If no CID is negotiated, then the receiver MUST reject any records it
receives that contain a CID.