Draft: draft-ietf-tls-dtls13

Commentary: Hopefully nothing controversial in here . I went for adding the missing reserved handshake types rather than removing all the reserved ones , since I assume that we will eventually fix up the automation to only show the reserved values in the appendix and skip them in the body text .
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 B):
When receiving protected DTLS records, the recipient does not have a
full epoch or sequence number value in the record 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 AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_SHA256, does
not have a limit on the number of records that fail authentication
that both limits the probability of forgery by the same amount and
does not expose implementations to the risk of denial of service; see
ccm-short.  Therefore, TLS_AES_128_CCM_SHA256 MUST NOT used in DTLS
without additional safeguards against forgery.  Implementations MUST
set usage limits for AEAD_AES_128_CCM_8 based on an understanding of
any additional forgery protections that are used.
Paragraph (version A):
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 packets that can fail authentication.  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):
The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_8_SHA256,
does not have a limit on the number of records that fail
authentication that both limits the probability of forgery by the
same amount and does not expose implementations to the risk of denial
of service; see ccm-short.  Therefore, TLS_AES_128_CCM_8_SHA256 MUST
NOT used in DTLS without additional safeguards against forgery.
Implementations MUST set usage limits for AEAD_AES_128_CCM_8 based on
an understanding of any additional forgery protections that are used.
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 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.
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):
An attacker can use the server as an amplifier by sending
connection initiation messages with a forged source of the 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 it is the case for a Certificate
message.
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 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):
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):
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 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.  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 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):
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):
The implementation receives some or all 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 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):
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 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 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 B):
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 record 1 indicating loss of record 0, the entire
flight would be retransmitted.  When DTLS 1.3 is used in deployments
with lossy 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):
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 B):
DTLS implementations MUST NOT update the address they send to 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 active 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 A):
Since TLS 1.3 introduces a large number of changes 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.
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.