Draft: draft-ietf-tls-dtls13

Commentary: Also , use nicer labels for those references . 
 merged by hand
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 I-D.ietf-tls-tls13.
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
backwards 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):
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 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.
Paragraph (version A):
Variable length connection ID.  The connection ID concept is
described in I-D.ietf-tls-dtls-connection-id.  An example can be
found in connection-id-example.
Paragraph (version B):
Variable length connection ID.  The connection ID concept is
described in DTLS-CID.  An example can be found in connection-id-
example.
Paragraph (version A):
DTLS records, as defined in this document, 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.
However, the Connection ID extension defined in I-D.ietf-tls-dtls-
connection-id adds an association identifier to DTLS records.
Paragraph (version B):
DTLS records, as defined in this document, 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.
However, the Connection ID extension defined in DTLS-CID adds an
association identifier to DTLS records.
Paragraph (version A):
With these exceptions, the DTLS message formats, flows, and logic are
the same as those of TLS 1.3.  DTLS implementations SHOULD not use
the TLS 1.3 "compatibility mode" described in I-D.ietf-tls-tls13,
Section D.4 and DTLS servers SHOULD ignore the "session_id" value
generated by the client rather than sending ChangeCipherSpec
messages.  Implementations MUST still ignore ChangeCipherSpec
messages received during the handshake and at all other times SHOULD
treat them as if they had failed to deprotect.
Paragraph (version B):
With these exceptions, the DTLS message formats, flows, and logic are
the same as those of TLS 1.3.  DTLS implementations SHOULD not use
the TLS 1.3 "compatibility mode" described in TLS13, Section D.4 and
DTLS servers SHOULD ignore the "session_id" value generated by the
client rather than sending ChangeCipherSpec messages.
Implementations MUST still ignore ChangeCipherSpec messages received
during the handshake and at all other times SHOULD treat them as if
they had failed to deprotect.
Paragraph (version A):
The cookie extension is defined in Section 4.2.2 of I-D.ietf-tls-
tls13.  When sending the initial ClientHello, the client does not
have a cookie yet.  In this case, the cookie extension is omitted and
the legacy_cookie field in the ClientHello message SHOULD be set to a
zero length vector (i.e., a single zero byte length field) and MUST
be ignored by a server negotiating DTLS 1.3.
Paragraph (version A):
When responding to a HelloRetryRequest, the client MUST create a new
ClientHello message following the description in Section 4.1.2 of I-
D.ietf-tls-tls13.
Paragraph (version A):
If the HelloRetryRequest message is used, the initial ClientHello and
the HelloRetryRequest are included in the calculation of the
Transcript-Hash.  The computation of the message hash for the
HelloRetryRequest is done according to the description in
Section 4.4.1 of I-D.ietf-tls-tls13.
Paragraph (version B):
The cookie extension is defined in Section 4.2.2 of TLS13.  When
sending the initial ClientHello, the client does not have a cookie
yet.  In this case, the cookie extension is omitted and the
legacy_cookie field in the ClientHello message SHOULD be set to a
zero length vector (i.e., a single zero byte length field) and MUST
be ignored by a server negotiating DTLS 1.3.
Paragraph (version B):
When responding to a HelloRetryRequest, the client MUST create a new
ClientHello message following the description in Section 4.1.2 of
TLS13.
Paragraph (version B):
If the HelloRetryRequest message is used, the initial ClientHello and
the HelloRetryRequest are included in the calculation of the
Transcript-Hash.  The computation of the message hash for the
HelloRetryRequest is done according to the description in
Section 4.4.1 of TLS13.
Paragraph (version A):
If a server receives a ClientHello with an invalid cookie, it MUST
NOT respond with a HelloRetryRequest.  Restarting the handshake from
scratch, without a cookie, allows the client to recover from a
situation where it obtained a cookie that cannot be verified by the
server.  As described in Section 4.1.4 of I-D.ietf-tls-tls13, clients
SHOULD also abort the handshake with an "unexpected_message" alert in
response to any second HelloRetryRequest which was sent in the same
connection (i.e., where the ClientHello was itself in response to a
HelloRetryRequest).
Paragraph (version B):
If a server receives a ClientHello with an invalid cookie, it MUST
NOT respond with a HelloRetryRequest.  Restarting the handshake from
scratch, without a cookie, allows the client to recover from a
situation where it obtained a cookie that cannot be verified by the
server.  As described in Section 4.1.4 of TLS13, clients SHOULD also
abort the handshake with an "unexpected_message" alert in response to
any second HelloRetryRequest which was sent in the same connection
(i.e., where the ClientHello was itself in response to a
HelloRetryRequest).
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 I-D.ietf-tls-
tls13) and the legacy_version field MUST be set to {254, 253},
which was the version number for DTLS 1.2.
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.
Paragraph (version A):
CertificateVerify and Finished messages have the same format as in
TLS 1.3.  Hash calculations include entire handshake messages,
including DTLS-specific fields: message_seq, fragment_offset, and
fragment_length.  However, in order to remove sensitivity to
handshake message fragmentation, the CertificateVerify and the
Finished messages MUST be computed as if each handshake message had
been sent as a single fragment following the algorithm described in
Section 4.4.3 and Section 4.4.4 of I-D.ietf-tls-tls13, respectively.
Paragraph (version B):
CertificateVerify and Finished messages have the same format as in
TLS 1.3.  Hash calculations include entire handshake messages,
including DTLS-specific fields: message_seq, fragment_offset, and
fragment_length.  However, in order to remove sensitivity to
handshake message fragmentation, the CertificateVerify and the
Finished messages MUST be computed as if each handshake message had
been sent as a single fragment following the algorithm described in
Section 4.4.3 and Section 4.4.4 of TLS13, respectively.
Paragraph (version A):
A recipient of a DTLS message needs to select the correct keying
material in order to process an incoming message.  With the
possibility of message loss and re-order an identifier is needed to
determine which cipher state has been used to protect the record
payload.  The epoch value fulfills this role in DTLS.  In addition to
the key derivation steps described in Section 7 of I-D.ietf-tls-tls13
triggered by the states during the handshake a sender may want to
rekey at any time during the lifetime of the connection and has to
have a way to indicate that it is updating its sending cryptographic
keys.
Paragraph (version B):
A recipient of a DTLS message needs to select the correct keying
material in order to process an incoming message.  With the
possibility of message loss and re-order an identifier is needed to
determine which cipher state has been used to protect the record
payload.  The epoch value fulfills this role in DTLS.  In addition to
the key derivation steps described in Section 7 of TLS13 triggered by
the states during the handshake a sender may want to rekey at any
time during the lifetime of the connection and has to have a way to
indicate that it is updating its sending cryptographic keys.
Paragraph (version A):
The traffic key calculation is described in Section 7.3 of I-D.ietf-
tls-tls13.
Paragraph (version B):
The traffic key calculation is described in Section 7.3 of TLS13.
Paragraph (version A):
If the client and server have negotiated the "connection_id"
extension I-D.ietf-tls-dtls-connection-id, either side can send a new
connection ID which it wishes the other side to use in a
NewConnectionId message.
Paragraph (version B):
If the client and server have negotiated the "connection_id"
extension DTLS-CID, either side can send a new connection ID which it
wishes the other side to use in a NewConnectionId message.
Paragraph (version A):
Note: The connection_id extension is defined in I-D.ietf-tls-dtls-
connection-id, which is used in ClientHello and ServerHello messages.
Paragraph (version B):
Note: The connection_id extension is defined in DTLS-CID, which is
used in ClientHello and ServerHello messages.
Paragraph (version A):
Security issues are discussed primarily in I-D.ietf-tls-tls13.
Paragraph (version B):
Security issues are discussed primarily in TLS13.