Draft: draft-ietf-tls-dtls13

Commentary: I think that the older versions of the spec were good at using the term " datagram " to refer to the thing that holds DTLS records . This version now uses " packet " in a good number of places . Sometimes I think that it means " record " , other times " datagram " . I 'm sure that this is just the influence of QUIC and it can be fixed easily . 
 Actually 6357 uses " packet " all over the place . I 'll do an audit , but I 'm not going to ones that mean IP packet .
Paragraph (version A):
TLS and DTLS handshake messages can be quite large (in theory up to
2^24-1 bytes, in practice many kilobytes).  By contrast, UDP
datagrams are often limited to less than 1500 bytes if IP
fragmentation is not desired.  In order to compensate for this
limitation, each DTLS handshake message may be fragmented over
several DTLS records, each of which is intended to fit in a single IP
packet.  Each DTLS handshake message contains both a fragment offset
and a fragment length.  Thus, a recipient in possession of all bytes
of a handshake message can reassemble the original unfragmented
message.
Paragraph (version B):
TLS and DTLS handshake messages can be quite large (in theory up to
2^24-1 bytes, in practice many kilobytes).  By contrast, UDP
datagrams are often limited to less than 1500 bytes if IP
fragmentation is not desired.  In order to compensate for this
limitation, each DTLS handshake message may be fragmented over
several DTLS records, each of which is intended to fit in a single
UDP datagram.  Each DTLS handshake message contains both a fragment
offset and a fragment length.  Thus, a recipient in possession of all
bytes of a handshake message can reassemble the original unfragmented
message.
Paragraph (version A):
Conversely, it is possible for records that are protected with the
new epoch to be received prior to the completion of a handshake.  For
instance, the server may send its Finished message and then start
transmitting data.  Implementations MAY either buffer or discard such
packets, though when DTLS is used over reliable transports (e.g.,
SCTP RFC4960), they SHOULD be buffered and processed once the
handshake completes.  Note that TLS's restrictions on when packets
may be sent still apply, and the receiver treats the packets as if
they were sent in the right order.
Paragraph (version B):
Conversely, it is possible for records that are protected with the
new epoch to be received prior to the completion of a handshake.  For
instance, the server may send its Finished message and then start
transmitting data.  Implementations MAY either buffer or discard such
records, though when DTLS is used over reliable transports (e.g.,
SCTP RFC4960), they SHOULD be buffered and processed once the
handshake completes.  Note that TLS's restrictions on when records
may be sent still apply, and the receiver treats the records as if
they were sent in the right order.
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 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 B):
The received record 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 record; otherwise the record 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):
The "right" edge of the window represents the highest validated
sequence number value received on the session.  Records that contain
sequence numbers lower than the "left" edge of the window are
rejected.  Packets falling within the window are checked against a
list of received packets within the window.  An efficient means for
performing this check, based on the use of a bit mask, is described
in Section 3.4.3 of RFC4303.  If the received record falls within the
window and is new, or if the packet is to the right of the window,
then the packet is new.
Paragraph (version A):
The window MUST NOT be updated until the packet has been deprotected
successfully.
Paragraph (version B):
The "right" edge of the window represents the highest validated
sequence number value received on the session.  Records that contain
sequence numbers lower than the "left" edge of the window are
rejected.  Records falling within the window are checked against a
list of received records within the window.  An efficient means for
performing this check, based on the use of a bit mask, is described
in Section 3.4.3 of RFC4303.  If the received record falls within the
window and is new, or if the record is to the right of the window,
then the record is new.
Paragraph (version B):
The window MUST NOT be updated until the record has been deprotected
successfully.
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 range MUST be delivered in a single packet.
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 UDP datagram.
Paragraph (version A):
Note that because of packet loss, it is possible for one side to be
sending application data even though the other side has not received
the first side's Finished message.  Implementations MUST either
discard or buffer all application data packets for the new epoch
until they have received the Finished message for that epoch.
Implementations MAY treat receipt of application data with a new
epoch prior to receipt of the corresponding Finished message as
evidence of reordering or packet loss and retransmit their final
flight immediately, shortcutting the retransmission timer.
Paragraph (version B):
Note that because of packet loss, it is possible for one side to be
sending application data even though the other side has not received
the first side's Finished message.  Implementations MUST either
discard or buffer all application data records for the new epoch
until they have received the Finished message for that epoch.
Implementations MAY treat receipt of application data with a new
epoch prior to receipt of the corresponding Finished message as
evidence of reordering or packet loss and retransmit their final
flight immediately, shortcutting the retransmission timer.
Paragraph (version A):
Note: it is not always possible to distinguish which association a
given packet is from.  For instance, if the client performs a
handshake, abandons the connection, and then immediately starts a new
handshake, it may not be possible to tell which connection a given
protected record is for.  In these cases, trial decryption MAY be
necessary, though implementations could also use some sort of CID,
such as the one specified in I-D.ietf-tls-dtls-connection-id.
Paragraph (version B):
Note: it is not always possible to distinguish which association a
given record is from.  For instance, if the client performs a
handshake, abandons the connection, and then immediately starts a new
handshake, it may not be possible to tell which connection a given
protected record is for.  In these cases, trial decryption MAY be
necessary, though implementations could also use some sort of CID,
such as the one specified in I-D.ietf-tls-dtls-connection-id.
Paragraph (version A):
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 implementation 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 acknowledgement for the entire
flight.
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 implementation MUST cancel all retransmissions of that flight.
As noted above, the receipt of any record responding to a given
flight MUST be taken as an implicit acknowledgement for the entire
flight.
Paragraph (version A):
If implementations process out-of-epoch records as recommended in
key-updates, then this creates a denial of service risk since an
adversary could inject packets with fake epoch values, forcing the
recipient to compute the next-generation application_traffic_secret
using the HKDF-Expand-Label construct to only find out that the
message was does not pass the AEAD cipher processing.  The impact of
this attack is small since the HKDF-Expand-Label only performs
symmetric key hashing operations.  Implementations which are
concerned about this form of attack can discard out-of-epoch records.
Paragraph (version B):
If implementations process out-of-epoch records as recommended in
key-updates, then this creates a denial of service risk since an
adversary could inject records with fake epoch values, forcing the
recipient to compute the next-generation application_traffic_secret
using the HKDF-Expand-Label construct to only find out that the
message was does not pass the AEAD cipher processing.  The impact of
this attack is small since the HKDF-Expand-Label only performs
symmetric key hashing operations.  Implementations which are
concerned about this form of attack can discard out-of-epoch records.