Draft: draft-ietf-tls-dtls13

Commentary: Use CID where possible .
Paragraph (version A):
Variable length connection ID.  The connection ID concept is
described in DTLS-CID.  An example can be found in connection-id-
example.
Paragraph (version B):
Variable length CID.  The CID 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 DTLS-CID 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 CID extension defined in DTLS-CID adds an association
identifier to DTLS records.
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.ietf-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 CID,
such as the one specified in I-D.ietf-tls-dtls-connection-id.
Paragraph (version A):
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 B):
If the client and server have negotiated the "connection_id"
extension DTLS-CID, either side can send a new CID which it wishes
the other side to use in a NewConnectionId message.
Paragraph (version A):
Endpoints MUST NOT send either of these messages if they did not
negotiate a connection ID.  If an implementation receives these
messages when connection IDs were not negotiated, it MUST abort the
connection with an unexpected_message alert.
Paragraph (version A):
Below is an example exchange for DTLS 1.3 using a single connection
id in each direction.
Paragraph (version B):
Endpoints MUST NOT send either of these messages if they did not
negotiate a CID.  If an implementation receives these messages when
CIDs were not negotiated, it MUST abort the connection with an
unexpected_message alert.
Paragraph (version B):
Below is an example exchange for DTLS 1.3 using a single CID in each
direction.
Paragraph (version A):
The use of the Post-Handshake message allows the client and the
server to update their connection IDs and those values are
exchanged with confidentiality protection.
Paragraph (version A):
With multi-homing, an adversary is able to correlate the
communication interaction over the two paths, which adds further
privacy concerns.  In order to prevent this, implementations
SHOULD attempt to use fresh connection IDs whenever they change
local addresses or ports (though this is not always possible to
detect).  The RequestConnectionId message can be used to ask for
new IDs in order to ensure that you have a pool of suitable IDs.
Paragraph (version A):
Switching connection ID based on certain events, or even
regularly, helps against tracking by onpath adversaries but the
sequence numbers can still allow linkability.  For this reason
this specification defines an algorithm for encrypting sequence
numbers, see sne.
Paragraph (version B):
The use of the Post-Handshake message allows the client and the
server to update their CIDs and those values are exchanged with
confidentiality protection.
Paragraph (version B):
With multi-homing, an adversary is able to correlate the
communication interaction over the two paths, which adds further
privacy concerns.  In order to prevent this, implementations
SHOULD attempt to use fresh CIDs whenever they change local
addresses or ports (though this is not always possible to detect).
The RequestConnectionId message can be used to ask for new IDs in
order to ensure that you have a pool of suitable IDs.
Paragraph (version B):
Switching CID based on certain events, or even regularly, helps
against tracking by onpath adversaries but the sequence numbers
can still allow linkability.  For this reason this specification
defines an algorithm for encrypting sequence numbers, see sne.
Note that sequence number encryption is used for all encrypted
DTLS 1.3 records irrespectively of the use of a CID.
Paragraph (version B):
Only AEAD ciphers are supported.  Additional data calculation has
been simplified.