Draft: draft-ietf-tls-dtls13

Commentary: Generally fine ; just a nit
Paragraph (version A):
Implementations that speak both DTLS 1.2 and DTLS 1.3 can
interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of
course), just as TLS 1.3 implementations can interoperate with TLS
compatibility with DTLS 1.0 is possible the use of DTLS 1.0 is not
recommended as explained in Section 3.1.2 of RFC 7525 RFC7525.
Paragraph (version B):
Implementations that speak both DTLS 1.2 and DTLS 1.3 can
interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of
course), just as TLS 1.3 implementations can interoperate with TLS
compatibility with DTLS 1.0 is possible the use of DTLS 1.0 is not
recommended as explained in Section 3.1.2 of RFC 7525 RFC7525 and
DEPRECATE.
Paragraph (version A):
connection: A transport-layer connection between two endpoints.
Paragraph (version A):
handshake: An initial negotiation between client and server that
establishes the parameters of their transactions.
Paragraph (version B):
association: Shared state between two endpoints established with a
DTLS handshake.
Paragraph (version B):
connection: Synonym for association.
Paragraph (version B):
handshake: An initial negotiation between client and server that
establishes the parameters of the connection.
Paragraph (version A):
session: An association between a client and a server resulting
from a handshake.
Paragraph (version A):
Identical to the encrypted_record field in a TLS 1.3 record.
Paragraph (version A):
The three high bits of the first byte of the DTLSCiphertext header
are set to 001.
Paragraph (version B):
This value MUST be set to {254, 253} for all records other than
the initial ClientHello (i.e., one not generated after a
HelloRetryRequest), where it may also be {254, 254} for
compatibility purposes.  It MUST be ignored for all purposes.  See
TLS13; Appendix D.1 for the rationale for this.
Paragraph (version B):
The AEAD-encrypted form of the serialized DTLSInnerPlaintext
structure.
Paragraph (version A):
When receiving protected DTLS records 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 A):
If the epoch bits match those of 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 A):
During the handshake phase, the epoch bits unambiguously indicate the
correct key to use.  After the handshake is complete, if the epoch
bits do not match those from the current epoch implementations SHOULD
use the most recent past epoch which has matching bits, and then
reconstruct the sequence number as described above.
Paragraph (version B):
If the epoch bits match those of 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 in the
current epoch.
Paragraph (version B):
During the handshake phase, the epoch bits unambiguously indicate the
correct key to use.  After the handshake is complete, if the epoch
bits do not match those from the current epoch implementations SHOULD
use the most recent past epoch which has matching bits, and then
reconstruct the sequence number for that epoch as described above.
Paragraph (version A):
DTLS records without CIDs do not contain any association identifiers
and applications must arrange to multiplex between associations.
With UDP, the host/port number is used to look up the appropriate
security association for incoming records.
Paragraph (version B):
DTLS records without CIDs do not contain any association identifiers
and applications must arrange to multiplex between associations.
With UDP, the host/port number is used to look up the appropriate
security association for incoming records without CIDs.
Paragraph (version A):
If repeated retransmissions do not result in a response, and the
PMTU is unknown, subsequent retransmissions SHOULD back off to a
smaller record size, fragmenting the handshake message as
appropriate.  This standard does not specify an exact number of
retransmits to attempt before backing off, but 2-3 seems
appropriate.
Paragraph (version B):
If repeated retransmissions do not result in a response, and the
PMTU is unknown, subsequent retransmissions SHOULD back off to a
smaller record size, fragmenting the handshake message as
appropriate.  This specification does not specify an exact number
of retransmits to attempt before backing off, but 2-3 seems
appropriate.
Paragraph (version A):
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 computing
the full record number from the partial is still a potential timing
channel for the record number, though a less powerful one than
whether the record was deprotected.
Paragraph (version B):
Any TLS cipher suite that is specified for use with DTLS MUST define
limits on the use of the associated AEAD function that preserves
margins for both confidentiality and integrity.  That is, limits MUST
be specified for the number of packets that can be authenticated and
for the number of packets that can fail authentication before a key
update is required.  Providing a reference to any analysis upon which
values are based - and any assumptions used in that analysis - allows
limits to be adapted to varying usage conditions.
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
"legacy_session_id" value from the client and endpoints MUST NOT send
ChangeCipherSpec messages.
Paragraph (version A):
In order to counter both of these attacks, DTLS borrows the stateless
cookie technique used by Photuris RFC2522 and IKE RFC7296.  When the
client sends its ClientHello message to the server, the server MAY
respond with a HelloRetryRequest message.  The HelloRetryRequest
message, as well as the cookie extension, is defined in TLS 1.3.  The
HelloRetryRequest message contains a stateless cookie generated using
the technique of RFC2522.  The client MUST retransmit the ClientHello
with the cookie added as an extension.  The server then verifies the
cookie and proceeds with the handshake only if it is valid.  This
mechanism forces the attacker/client to be able to receive the
cookie, which makes DoS attacks with spoofed IP addresses difficult.
This mechanism does not provide any defense against DoS attacks
mounted from valid IP addresses.
Paragraph (version B):
An attacker can use the server as an amplifier by sending
connection initiation messages with a forged source address that
belongs to a victim.  The server then sends its response to the
victim machine, thus flooding it.  Depending on the selected
parameters this response message can be quite large, as is the
case for a Certificate message.
Paragraph (version B):
In order to counter both of these attacks, DTLS borrows the stateless
cookie technique used by Photuris RFC2522 and IKE RFC7296.  When the
client sends its ClientHello message to the server, the server MAY
respond with a HelloRetryRequest message.  The HelloRetryRequest
message, as well as the cookie extension, is defined in TLS 1.3.  The
HelloRetryRequest message contains a stateless cookie (see TLS13;
Section 4.2.2).  The client MUST send a new ClientHello with the
cookie added as an extension.  The server then verifies the cookie
and proceeds with the handshake only if it is valid.  This mechanism
forces the attacker/client to be able to receive the cookie, which
makes DoS attacks with spoofed IP addresses difficult.  This
mechanism does not provide any defense against DoS attacks mounted
from valid IP addresses.
Paragraph (version A):
The handshake transcript is not reset with the second ClientHello and
a stateless server-cookie implementation requires the transcript of
the HelloRetryRequest to be stored in the cookie or the internal
state of the hash algorithm, since only the hash of the transcript is
required for the handshake to complete.
Paragraph (version B):
The handshake transcript is not reset with the second ClientHello and
a stateless server-cookie implementation requires the transcript or
hash of the HelloRetryRequest to be stored in the cookie, since the
initial ClientHello is included in the handshake transcript as a
synthetic "message_hash" message, so only the hash value is needed
for the handshake to complete.
Paragraph (version A):
DTLS servers SHOULD perform a cookie exchange whenever a new
handshake is being performed.  If the server is being operated in an
environment where amplification is not a problem, the server MAY be
configured not to perform a cookie exchange.  The default SHOULD be
that the exchange is performed, however.  In addition, the server MAY
choose not to do a cookie exchange when a session is resumed or, more
generically, when the DTLS handshake uses a PSK-based key exchange.
Clients MUST be prepared to do a cookie exchange with every
handshake.
Paragraph (version A):
If a server receives a ClientHello with an invalid cookie, it MUST
NOT terminate the handshake with an "illegal_parameter" alert.  This
allows the client to restart the connection from scratch without a
cookie.
Paragraph (version B):
DTLS servers SHOULD perform a cookie exchange whenever a new
handshake is being performed.  If the server is being operated in an
environment where amplification is not a problem, the server MAY be
configured not to perform a cookie exchange.  The default SHOULD be
that the exchange is performed, however.  In addition, the server MAY
choose not to do a cookie exchange when a session is resumed or, more
generically, when the DTLS handshake uses a PSK-based key exchange.
Servers which process 0-RTT requests and send 0.5-RTT responses
without a cookie exchange risk being used in an amplification attack
if the size of outgoing messages greatly exceeds the size of those
that are received.  A server SHOULD limit the amount of data it sends
toward a client address before it verifies that the client is able to
receive data at that address.  A client address is valid after a
cookie exchange or handshake completion.  A server MAY apply a higher
limit based on heuristics, such as if the client uses the same IP
address as the connection on which the cookie was created.  Clients
MUST be prepared to do a cookie exchange with every handshake.
Paragraph (version B):
If a server receives a ClientHello with an invalid cookie, it MUST
terminate the handshake with an "illegal_parameter" alert.  This
allows the client to restart the connection from scratch without a
cookie.
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 supported_versions entries 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):
Same as for TLS 1.3.
Paragraph (version B):
Same as for TLS 1.3; only suites with DTLS-OK=Y may be used.
Paragraph (version A):
Each DTLS message MUST fit within a single transport layer datagram.
However, handshake messages are potentially bigger than the maximum
record size.  Therefore, DTLS provides a mechanism for fragmenting a
handshake message over a number of records, each of which can be
transmitted separately, thus avoiding IP fragmentation.
Paragraph (version B):
Each DTLS record MUST fit within a single transport layer datagram.
However, handshake messages are potentially bigger than the maximum
record size.  Therefore, DTLS provides a mechanism for fragmenting a
handshake message over a number of records, each of which can be
transmitted separately, thus avoiding IP fragmentation.
Paragraph (version A):
Note: The application data sent by the client is not included in the
timeout and retransmission calculation.
Paragraph (version B):
DTLS handshake messages are grouped into a series of message flights.
A flight starts with the handshake message transmission of one peer
and ends with the expected response from the other peer.  Table tab-
flights contains a complete list of message combinations that
consitute flights.
Paragraph (version B):
Remarks: * The HelloRetryRequest shown in is an optional message sent
by the server.  ** When a handshake flight is sent without any
expected response as with the client's final flight or
NewSessionTicket, the peer must acknowledge the peer's flight.
Paragraph (version B):
Below are several example message exchange illustrating the flight
concept.
Paragraph (version B):
KeyUpdate, NewConnectionId and RequestConnectionId follow a similar
pattern to NewSessionTicket: a single message sent by one side
followed by an ACK by the other.
Paragraph (version B):
The implementation receives some or all of the next flight of
messages: if this is the final flight of messages, the
implementation transitions to FINISHED.  If the implementation
needs to send a new flight, it transitions to the PREPARING state.
Partial reads (whether partial messages or only some of the
messages in the flight) may also trigger the implementation to
send an ACK, as described in sending-acks.
Paragraph (version A):
In addition, for at least twice the default MSL defined for RFC0793,
when in the FINISHED state, the server MUST respond to retransmission
of the client's second flight with a retransmit of its ACK.
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 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 B):
In addition, for at least twice the default MSL defined for RFC0793,
when in the FINISHED state, the server MUST respond to retransmission
of the client's final flight with a retransmit of its ACK.
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 epoch 3 and above
until they have received the Finished message from the peer.
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):
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 B):
Implementations SHOULD retain the current timer value until a message
is transmitted and acknowledged without having to be retransmitted,
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 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 use CIDs.
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 use CIDs to avoid the 5-
tuple-based ambiguity.
Paragraph (version A):
After the handshake, ACKs SHOULD be sent once for each received and
processed handshake record (potentially subject to some delay) and
MAY cover more than one flight.  This includes messages which are
discarded because a previous copy has been received.
Paragraph (version B):
After the handshake, ACKs SHOULD be sent once for each received and
processed handshake record (potentially subject to some delay) and
MAY cover more than one flight.  This includes records containing
messages which are discarded because a previous copy has been
received.
Paragraph (version B):
Handshake flights other than the client's final flight of the main
handshake.
Paragraph (version A):
ACKs SHOULD NOT be sent for these flights unless generating the
responding flight takes significant time.  In this case,
implementations MAY send explicit ACKs for the complete received
flight even though it will eventually also be implicitly acknowledged
through the responding flight.  A notable example for this is the
case of post-handshake client authentication in constrained
environments, where generating the CertificateVerify message can take
considerable time on the client.  All other flights MUST be ACKed.
Implementations MAY acknowledge the records corresponding to each
transmission of each flight or simply acknowledge the most recent
one.  In general, implementations SHOULD ACK as many received packets
as can fit into the ACK record, as this provides the most complete
information and thus reduces the chance of spurious retransmission;
if space is limited, implementations SHOULD favor including records
which have not yet been acknowledged.
Paragraph (version A):
Note: While some post-handshake messages follow a request/response
pattern, this does not necessarily imply receipt.  For example, a
KeyUpdate sent in response to a KeyUpdate with update_requested does
not implicitly acknowledge that message because the KeyUpdates might
have crossed in flight.
Paragraph (version B):
ACKs SHOULD NOT be sent for these flights unless generating the
responding flight takes significant time.  In this case,
implementations MAY send explicit ACKs for the complete received
flight even though it will eventually also be implicitly acknowledged
through the responding flight.  A notable example for this is the
case of client authentication in constrained environments, where
generating the CertificateVerify message can take considerable time
on the client.  All other flights MUST be ACKed.  Implementations MAY
acknowledge the records corresponding to each transmission of each
flight or simply acknowledge the most recent one.  In general,
implementations SHOULD ACK as many received packets as can fit into
the ACK record, as this provides the most complete information and
thus reduces the chance of spurious retransmission; if space is
limited, implementations SHOULD favor including records which have
not yet been acknowledged.
Paragraph (version B):
Note: While some post-handshake messages follow a request/response
pattern, this does not necessarily imply receipt.  For example, a
KeyUpdate sent in response to a KeyUpdate with request_update set to
'update_requested' does not implicitly acknowledge the earlier
KeyUpdate message because the two KeyUpdate messages might have
crossed in flight.
Paragraph (version A):
In the first case the use of the ACK message is optional because the
peer will retransmit in any case and therefore the ACK just allows
for selective retransmission, as opposed to the whole flight
retransmission in previous versions of DTLS.  For instance in the
flow shown in Figure 11 if the client does not send the ACK message
when it received and processed record 1 indicating loss of record 0,
the entire flight would be retransmitted.  When DTLS 1.3 is used in
deployments with loss networks, such as low-power, long range radio
networks as well as low-power mesh networks, the use of ACKs is
recommended.
Paragraph (version A):
The use of the ACK for the second case is mandatory for the proper
functioning of the protocol.  For instance, the ACK message sent by
the client in Figure 12, acknowledges receipt and processing of
record 2 (containing the NewSessionTicket message) and if it is not
sent the server will continue retransmission of the NewSessionTicket
indefinitely.
Paragraph (version B):
The use of the ACK for the second case is mandatory for the proper
functioning of the protocol.  For instance, the ACK message sent by
the client in Figure 12, acknowledges receipt and processing of
record 4 (containing the NewSessionTicket message) and if it is not
sent the server will continue retransmission of the NewSessionTicket
indefinitely until its transmission cap is reached.
Paragraph (version A):
As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to
indicate that they are updating their sending keys.  As with other
handshake messages with no built-in response, KeyUpdates MUST be
acknowledged.  In order to facilitate epoch reconstruction
reconstructing implementations MUST NOT send with the new keys or
send a new KeyUpdate until the previous KeyUpdate has been
acknowledged (this avoids having too many epochs in active use).
Paragraph (version B):
As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to
indicate that they are updating their sending keys.  As with other
handshake messages with no built-in response, KeyUpdates MUST be
acknowledged.  In order to facilitate epoch reconstruction
reconstructing implementations MUST NOT send records with the new
keys or send a new KeyUpdate until the previous KeyUpdate has been
acknowledged (this avoids having too many epochs in active use).
Paragraph (version B):
dtls-key-update shows an example exchange illustrating that a
successful ACK processing updates the keys of the KeyUpdate message
sender, which is reflected in the change of epoch values.
Paragraph (version A):
Application data messages are carried by the record layer and are
fragmented and encrypted based on the current connection state.  The
messages are treated as transparent data to the record layer.
Paragraph (version A):
The primary additional security consideration raised by DTLS is that
of denial of service.  DTLS includes a cookie exchange designed to
protect against denial of service.  However, implementations that do
not use this cookie exchange are still vulnerable to DoS.  In
particular, DTLS servers that do not use the cookie exchange may be
used as attack amplifiers even if they themselves are not
experiencing DoS.  Therefore, DTLS servers SHOULD use the cookie
exchange unless there is good reason to believe that amplification is
not a threat in their environment.  Clients MUST be prepared to do a
cookie exchange with every handshake.
Paragraph (version A):
DTLS implementations MUST NOT update their sending address in
response to packets from a different address unless they first
perform some reachability test; no such test is defined in this
specification.  Even with such a test, an on-path adversary can also
black-hole traffic or create a reflection attack against third
parties because a DTLS peer has no means to distinguish a genuine
address update event (for example, due to a NAT rebinding) from one
that is malicious.  This attack is of concern when there is a large
asymmetry of request/response message sizes.
Paragraph (version B):
Application data messages are carried by the record layer and are
split into records and encrypted based on the current connection
state.  The messages are treated as transparent data to the record
layer.
Paragraph (version B):
The primary additional security consideration raised by DTLS is that
of denial of service by excessive resource consumption.  DTLS
includes a cookie exchange designed to protect against denial of
service.  However, implementations that do not use this cookie
exchange are still vulnerable to DoS.  In particular, DTLS servers
that do not use the cookie exchange may be used as attack amplifiers
even if they themselves are not experiencing DoS.  Therefore, DTLS
servers SHOULD use the cookie exchange unless there is good reason to
believe that amplification is not a threat in their environment.
Clients MUST be prepared to do a cookie exchange with every
handshake.
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 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.
Paragraph (version B):
Since TLS 1.3 introduces a large number of changes with respect to
TLS 1.2, the list of changes from DTLS 1.2 to DTLS 1.3 is equally
large.  For this reason this section focuses on the most important
changes only.