Draft: draft-ietf-tls-dtls13

Commentary: PTAL 
 Oops . Thanks . 
 Sorry , I forgot to mention that I plan to do a separate PR for shrinking DTLS ciphertext . I have part of it in my buffer , but got this up and had to move on to something else for a bit . 
 I 'm happy to defer fixing KeyUpdate , which is basically non - functional as it is . This is fine on that basis .
Paragraph (version B):
The DTLS record layer includes an explicit epoch and sequence
number in the record.  This sequence number allows the recipient
to correctly verify the TLS MAC.
Paragraph (version B):
DTLS adds a short header format that can be used to reduce
overhead once the handshake is complete.
Paragraph (version B):
As with previous versions of DTLS, mutliple DTLSCiphertext records
can be included in the same underlying transport datagram.
Paragraph (version B):
The first three bits are set to 001 in order to allow multiplexing
between DTLS and VoIP protocols (STUN, RTP/RTCP, etc.)  RFC7983
and distinguish the short from long header formats.
Paragraph (version B):
The fourth bit is the low order bit of the epoch value.
Paragraph (version B):
The remaining bits contain the low order 12 bits of the sequence
number.
Paragraph (version B):
For deprotecion purposes, the nonce is computed using the full
sequence number, which can be reconstructed as described in
reconstructing.
Paragraph (version B):
In this format, the length field is omitted and therefore the record
consumes the entire rest of the datagram in the lower level
transport.  It is not possible to have multiple DTLSShortCiphertext
format records in the same datagram.
Paragraph (version B):
DTLSShortCiphertext MUST only be used for data which is protected
with one of the application_traffic_secrets, and not for either
handshake or early data.  When using an application_traffic_secret
for message protection, Implementations MAY use either DTLSCiphertext
or DTLSShortCiphertext at their discretion.
Paragraph (version B):
Implementations can distinguish the two header formats by examining
the first byte, which in the DTLSCiphertext header represents the
content type.  The only valid values for the content type are
alert(21), handshake(22), application_data(23), and ack(25), with
application_data actually representing protected data with the true
content type being encrypted.  If any of these values is present,
then the record MUST be handled as DTLSCiphertext.
Paragraph (version B):
If the first byte is any other other value, then receivers MUST check
to see if the leading bits of the first byte are 001.  If so, they
MUST process the record as DTLSShortCiphertext.  Otherwise, the
record MUST be rejected as if it had failed deprotection.
Paragraph (version B):
When receiving a DTLSShortCiphertext message, the recipient does not
have a full epoch or sequence number value and so there is some
opportunity for ambiguity.  Because the full epoch and sequence
number are used to compute the per-record nonce, failure to
reconstruct these values leads to failure to deprotect the record,
and so implementations MAY use a mechanism of their choice to
determine the full values.  This section provides an algorithm which
is comparatively simple and which implementations are RECOMMENDED to
follow.
Paragraph (version B):
If the epoch bit has the same parity as the current epoch, then
implementations SHOULD reconstruct the sequence number by computing
the full sequence number which is numerically closest to one plus the
sequence number of the highest successfully deprotected record.
Paragraph (version B):
If the epoch bit has a different parity from the current epoch, then
the record is either from a previous epoch or from a future epoch.
Implementations SHOULD use the epoch value which would produce a
sequence number which is numerically closest to what would be
reconstructed for that epoch, as determined by the algorithm in the
paragraph above.