Draft: draft-ietf-tls-dtls13

Commentary: Lots of minor things in this batch .
Paragraph (version A):
There are applications that utilize UDP RFC0768 as a transport and to
offer communication security protection for those applications the
Datagram Transport Layer Security (DTLS) protocol has been designed.
DTLS is deliberately designed to be as similar to TLS as possible,
both to minimize new security invention and to maximize the amount of
code and infrastructure reuse.
Paragraph (version B):
There are applications that use UDP RFC0768 as a transport and to
offer communication security protection for those applications the
Datagram Transport Layer Security (DTLS) protocol has been designed.
DTLS is deliberately designed to be as similar to TLS as possible,
both to minimize new security invention and to maximize the amount of
code and infrastructure reuse.
Paragraph (version A):
DTLS 1.0 RFC4347 was originally defined as a delta from TLS 1.1
RFC4346 and DTLS 1.2 RFC6347 was defined as a series of deltas to TLS
in order to harmonize version numbers with TLS.  This specification
describes the most current version of the DTLS protocol aligning with
the efforts around TLS 1.3 TLS13.
Paragraph (version A):
The basic design philosophy of DTLS is to construct "TLS over
datagram transport".  Datagram transport does not require nor provide
reliable or in-order delivery of data.  The DTLS protocol preserves
this property for application data.  Applications such as media
streaming, Internet telephony, and online gaming use datagram
transport for communication due to the delay-sensitive nature of
transported data.  The behavior of such applications is unchanged
when the DTLS protocol is used to secure communication, since the
DTLS protocol does not compensate for lost or re-ordered data
traffic.
Paragraph (version A):
TLS does not allow independent decryption of individual records.
Because the integrity check indirectly depends on a sequence
number, if record N is not received, then the integrity check on
record N+1 will be based on the wrong sequence number and thus
will fail.  DTLS solves this problem by adding explicit sequence
numbers.
Paragraph (version A):
The TLS handshake is a lock-step cryptographic handshake.
Messages must be transmitted and received in a defined order; any
other order is an error.  This is incompatible with reordering and
message loss.
Paragraph (version A):
Not all TLS 1.3 handshake messages (such as the NewSessionTicket
message) are acknowledged.  Hence, a new acknowledgment message
has to be added to detect message loss.
Paragraph (version A):
Handshake messages are potentially larger than any given datagram,
thus creating the problem of IP fragmentation.
Paragraph (version A):
Datagram transport protocols, like UDP, are susceptible to abusive
behavior effecting denial of service attacks against
nonparticipants, and require a return-routability check with the
help of cookies to be integrated into the handshake.  A detailed
discussion of countermeasures can be found in dos.
Paragraph (version B):
The basic design philosophy of DTLS is to construct "TLS over
datagram transport".  Datagram transport does not require nor provide
reliable or in-order delivery of data.  The DTLS protocol preserves
this property for application data.  Applications such as media
streaming, Internet telephony, and online gaming use datagram
transport for communication due to the delay-sensitive nature of
transported data.  The behavior of such applications is unchanged
when the DTLS protocol is used to secure communication, since the
DTLS protocol does not compensate for lost or reordered data traffic.
Paragraph (version B):
TLS relies on an implicit sequence number on records.  If a record
is not received, then the recipient will use the wrong sequence
number when attempting to remove record protection from subsequent
records.  DTLS solves this problem by adding explicit sequence
numbers.
Paragraph (version B):
The TLS handshake is a lock-step cryptographic handshake.
Messages must be transmitted and received in a defined order; any
other order is an error.  DTLS handshake messages are also
assigned sequence numbers to enable reassembly in the correct
order in case datagrams are lost or reordered.
Paragraph (version B):
During the handshake, messages are implicitly acknowledged by
other handshake messages, but the last flight of messages and
post-handshake messages (such as the NewSessionTicket message) do
not result in any direct response that would allow the sender to
detect loss.  DTLS adds an acknowledgment message to enable better
loss recovery.
Paragraph (version B):
Handshake messages are potentially larger than can be contained in
a single datagram.  DTLS adds fields to handshake messages to
support fragmentation and reassembly.
Paragraph (version B):
Datagram transport protocols, like UDP, are susceptible to abusive
behavior effecting denial of service attacks against
nonparticipants.  DTLS adds a return-routability check that uses
the TLS HelloRetryRequest message (see dos for details).
Paragraph (version A):
In DTLS, each handshake message is assigned a specific sequence
number within that handshake.  When a peer receives a handshake
message, it can quickly determine whether that message is the next
message it expects.  If it is, then it processes it.  If not, it
queues it for future handling once all previous messages have been
received.
Paragraph (version B):
In DTLS, each handshake message is assigned a specific sequence
number.  When a peer receives a handshake message, it can quickly
determine whether that message is the next message it expects.  If it
is, then it processes it.  If not, it queues it for future handling
once all previous messages have been received.
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
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 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 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 A):
DTLS adds an explicit epoch and sequence number to the TLS record
header.  This sequence number allows the recipient to correctly
verify the DTLS MAC.  However, the number of bits used for the
epoch and sequence number fields in the DTLSCiphertext structure
have been reduced.
Paragraph (version B):
DTLS adds an explicit epoch and sequence number to the TLS record
header.  This sequence number allows the recipient to correctly
verify the DTLS MAC.  However, the number of bits used for the
epoch and sequence number fields in the DTLSCiphertext structure
have been reduced from those in previous versions.
Paragraph (version A):
The C bit is set if the connection ID is present.
Paragraph (version A):
The size of the sequence number.  0 means an 8-bit sequence
number, 1 means 16-bit.
Paragraph (version A):
The L bit is set if the length is present.
Paragraph (version A):
The low order two bits of the epoch.
Paragraph (version B):
The three high bits of the first byte of the DTLSCiphertext header
are set to 001.
Paragraph (version B):
The C bit (0x10) is set if the connection ID is present.
Paragraph (version B):
The S bit (0x08) indicates the size of the sequence number.  0
means an 8-bit sequence number, 1 means 16-bit.
Paragraph (version B):
The L bit (0x04) is set if the length is present.
Paragraph (version B):
The two low bits (0x03) include the low order two bits of the
epoch.
Paragraph (version A):
The length field may be omitted and therefore the record consumes the
entire rest of the datagram in the lower level transport.  In this
case it is not possible to have multiple DTLSCiphertext format
records without length fields in the same datagram.
Paragraph (version A):
Omitting the length field MUST only be used for data which is
protected with one of the application_traffic_secret values, and not
for messages protected with either [sender]_handshake_traffic_sercret
or [sender]_early_traffic_secret values.  When using an
[sender]_application_traffic_secret for message protection,
Implementations MAY include the length field at their discretion.
Paragraph (version B):
The length field MAY be omitted by clearing the L bit, which means
that the record consumes the entire rest of the datagram in the lower
level transport.  In this case it is not possible to have multiple
DTLSCiphertext format records without length fields in the same
datagram.
Paragraph (version B):
Omitting the length field MUST only be used for data which is
protected with one of the application_traffic_secret values, and not
for messages protected with either [sender]_handshake_traffic_secret
or [sender]_early_traffic_secret values.  When using an
[sender]_application_traffic_secret for message protection,
Implementations MAY include the length field at their discretion.
Paragraph (version A):
Note that some care needs to be taken during the handshake to ensure
that retransmitted messages use the right epoch and keying material.
Paragraph (version B):
Implementations MUST send retransmissions of lost messages using the
same epoch and keying material as the original transmission.
Paragraph (version A):
DTLS messages MAY be fragmentmented into multiple DTLS records.  Each
DTLS record MUST fit within a single datagram.  In order to avoid IP
fragmentation, clients of the DTLS record layer SHOULD attempt to
size records so that they fit within any PMTU estimates obtained from
the record layer.
Paragraph (version A):
Multiple DTLS records MAY be placed in a single datagram.  They are
simply encoded consecutively.  The DTLS record framing is sufficient
to determine the boundaries.  Note, however, that the first byte of
the datagram payload MUST be the beginning of a record.  Records MUST
NOT span datagrams.
Paragraph (version B):
DTLS messages MAY be fragmented into multiple DTLS records.  Each
DTLS record MUST fit within a single datagram.  In order to avoid IP
fragmentation, clients of the DTLS record layer SHOULD attempt to
size records so that they fit within any PMTU estimates obtained from
the record layer.
Paragraph (version B):
Multiple DTLS records MAY be placed in a single datagram.  Records
are encoded consecutively.  The length field from DTLS records
containing that field can be used to determine the boundaries between
records.  The final record in a datagram can omit the length field.
The first byte of the datagram payload MUST be the beginning of a
record.  Records MUST NOT span datagrams.
Paragraph (version A):
DTLS implementations do not use the TLS 1.3 "compatibility mode"
described in TLS13, Section D.4.  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.  Note however that implementations MUST
ignore ChangeCipherSpec messages received in unprotected records.
Paragraph (version A):
The DTLS 1.3 handshake has one important difference from the TLS 1.3
handshake: the EndOfEarlyData message is omitted both from the wire
and the handshake transcript: because DTLS records have epochs,
EndOfEarlyData is not necessary to determine when the early data is
complete, and because DTLS is lossy, attackers can trivially mount
the deletion attacks that EndOfEarlyData prevents in TLS.  Servers
SHOULD aggressively age out the epoch 1 keys upon receiving the first
epoch 1 record and SHOULD NOT accept epoch 1 data after the first
epoch 3 record is received.
Paragraph (version B):
The DTLS 1.3 handshake has one important difference from the TLS 1.3
handshake: the EndOfEarlyData message is omitted both from the wire
and the handshake transcript: because DTLS records have epochs,
EndOfEarlyData is not necessary to determine when the early data is
complete, and because DTLS is lossy, attackers can trivially mount
the deletion attacks that EndOfEarlyData prevents in TLS.  Servers
SHOULD aggressively age out the epoch 1 keys upon receiving the first
epoch 2 record and SHOULD NOT accept epoch 1 data after the first
epoch 3 record is received.
Paragraph (version A):
Implementations SHOULD retain the current timer value until a
transmission without loss occurs, at which time the value may be
reset to the initial value.  After a long period of idleness, no less
than 10 times the current timer value, implementations may reset the
timer to the initial value.  One situation where this might occur is
when a rehandshake is used after substantial data transfer.
Paragraph (version B):
Implementations SHOULD retain the current timer value until a
transmission without loss occurs, at which time the value may be
reset to the initial value.  After a long period of idleness, no less
than 10 times the current timer value, implementations may reset the
timer to the initial value.
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
connection identifier, such as the one specified in I-D.rescorla-tls-
dtls-connection-id.
Paragraph (version B):
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
connection identifier, such as the one specified in I-D.ietf-tls-
dtls-connection-id.
Paragraph (version A):
The ACK message is used by an endpoint to indicate handshake-
containing the TLS records it has received from the other side.  ACK
is not a handshake message but is rather a separate content type,
with code point TBD (proposed, 25).  This avoids it consuming space
in the handshake message sequence.  Note that ACKs can still be
piggybacked on the same UDP datagram as handshake records.
Paragraph (version B):
The ACK message is used by an endpoint to indicate handshake-
containing the TLS records it has received from the other side.  ACK
is not a handshake message but is rather a separate content type,
with code point TBD (proposed, 25).  This avoids having ACK being
added to the handshake transcript.  Note that ACKs can still be sent
in the same UDP datagram as handshake records.
Paragraph (version A):
Implementations MAY ACK the records corresponding to each
transmission of that flight or simply ACK the most recent one.
Paragraph (version B):
Implementations MAY acknowledge the records corresponding to each
transmission of that flight or simply acknowledge the most recent
one.
Paragraph (version A):
Note that in some cases it may be necessary to send an ACK which does
not contain any record numbers.  For instance, a client might receive
an EncryptedExtensions message prior to receiving a ServerHello.
Because it cannot decrypt the EncryptedExtensions, it cannot safely
ACK it (as it might be damaged).  If the client does not send an ACK,
the server will eventually retransmit its first flight, but this
might take far longer than the actual round trip time between client
and server.  Having the client send an empty ACK shortcuts this
process.
Paragraph (version B):
Note that in some cases it may be necessary to send an ACK which does
not contain any record numbers.  For instance, a client might receive
an EncryptedExtensions message prior to receiving a ServerHello.
Because it cannot decrypt the EncryptedExtensions, it cannot safely
acknowledge it (as it might be damaged).  If the client does not send
an ACK, the server will eventually retransmit its first flight, but
this might take far longer than the actual round trip time between
client and server.  Having the client send an empty ACK shortcuts
this process.
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 ACK 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 packet responding to a given
flight MUST be taken as an implicit acknowledgement for the entire
flight.
Paragraph (version A):
Although KeyUpdate MUST be ACKed, it is possible for the ACK to be
lost, in which case the sender of the KeyUpdate will retransmit it.
Implementations MUST retain the ability to ACK the KeyUpdate for up
to 2MSL.  It is RECOMMENDED that they do so by retaining the pre-
update keying material, but they MAY do so by responding to messages
which appear to be out-of-epoch with a canned ACK message; in this
case, implementations SHOULD rate limit how often they send such
ACKs.
Paragraph (version B):
Although KeyUpdate MUST be acknowledged, it is possible for the ACK
to be lost, in which case the sender of the KeyUpdate will retransmit
it.  Implementations MUST retain the ability to ACK the KeyUpdate for
up to 2MSL.  It is RECOMMENDED that they do so by retaining the pre-
update keying material, but they MAY do so by responding to messages
which appear to be out-of-epoch with a canned ACK message; in this
case, implementations SHOULD rate limit how often they send such
ACKs.
Paragraph (version A):
Endpoints SHOULD respond to RequestConnectionId by sending a
NewConnectionId with usage "cid_spare" containing num_cid CIDs soon
as possible.  Endpoints MUST NOT send a RequestConnectionId message
when an existing request is still unfulfilled; this implies that
endpoints needs to request new CIDs well in advance.  An endpoint MAY
ignore requests, which it considers excessive (though they MUST be
ACKed as usual).
Paragraph (version B):
Endpoints SHOULD respond to RequestConnectionId by sending a
NewConnectionId with usage "cid_spare" containing num_cid CIDs soon
as possible.  Endpoints MUST NOT send a RequestConnectionId message
when an existing request is still unfulfilled; this implies that
endpoints needs to request new CIDs well in advance.  An endpoint MAY
ignore requests, which it considers excessive (though they MUST be
acknowledged as usual).