Draft: draft-ietf-tls-dtls-connection-id

Commentary: The part of PR did n't made to the draft , or did I miss it ? In the meantime , I would even go further : Applying and may validates the record cryptographically , and so the receive windows may be updated and the application data may be forwarded . But , if the epoch / sequencenumber is not newer than the newest successfully validate epoch / sequencenumber before , the address update event itself may be wrong ! Assuming , that a address - change is located somewhere on the message 's route , it seems to be not possible to distinguish , if the message was delayed after the " address change " ( and so that address is deprecated ) or before that ( and so the address would be the new one ) . If that could not be decided , I would go for updating the address only for newer records . Using that approach , updating the address only for newer records ( based on epoch / sequence_number ) with validated , would also mitigate the first two attacks of issue , though retransmitting an record with changed address will not update the address , because these records are NOT newer . 
 I have updated the text of and was wondering whether it captures your issue . I am not sure what steps I have to take to meet your requirements . 
 As long as does n't get mandatory ( MUST ) , everything for me will be OK . So , yes , PR addresses it in the right way . 
 It looks like closes this issue ? 
 Thanks ! 
 The changes look good to me . This split makes sense to me . Thanks for making the change !
Paragraph (version B):
The received datagram has been cryptographically verified using
the DTLS record layer processing procedures.
Paragraph (version B):
The received datagram is "newer" (in terms of both epoch and
sequence number) than the newest datagram received.  Reordered
datagrams that are sent prior to a change in a peer address might
otherwise cause a valid address change to be reverted.  This also
limits the ability of an attacker to use replayed datagrams to
force a spurious address change, which could result in denial of
service.  An attacker might be able to succeed in changing a peer
address if they are able to rewrite source addresses and if
replayed packets are able to arrive before any original.
Paragraph (version B):
There is a strategy for ensuring that the new peer address is able
to receive and process DTLS records.  No such test is defined in
this specification.
Paragraph (version B):
Application protocols that implement protection against these attacks
depend on being aware of changes in peer addresses so that they can
engage the necessary mechanisms.  When delivered such an event, an
application layer-specific address validation mechanism can be
triggered, for example one that is based on successful exchange of
minimal amount of ping-pong traffic with the peer.  Alternatively, an
DTLS-specific mechanism may be used, as described in I-D.tschofenig-
tls-dtls-rrc.
Paragraph (version A):
In addition, endpoints can use the CID to attach arbitrary metadata
to each record they receive.  This may be used as a mechanism to
communicate per-connection information to on-path observers.  There
is no straightforward way to address this with CIDs that contain
arbitrary values; implementations concerned about this SHOULD refuse
to use connection ids.
Paragraph (version A):
An on-path adversary, who is able to observe the DTLS protocol
exchanges between the DTLS client and the DTLS server, is able to
link the observed payloads to all subsequent payloads carrying the
same connection id pair (for bi-directional communication).  Without
multi-homing or mobility, the use of the CID is not different to the
use of the 5-tuple.
Paragraph (version A):
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 A):
With multi-homing, an adversary is able to correlate the
communication interaction over the two paths, which adds further
privacy concerns.  The lack of a CID update mechanism makes this
extension unsuitable for mobility scenarios where correlation must be
considered.
Paragraph (version A):
Importantly, the sequence number makes it possible for a passive
attacker to correlate packets across CID changes.  Thus, even if a
client/server pair do a rehandshake to change CID, that does not
provide much privacy benefit.
Paragraph (version A):
The CID-enhanced record layer introduces record padding; a privacy
feature not available with the original DTLS 1.2 RFC.  Padding allows
to inflate the size of the ciphertext making traffic analysis more
difficult.  More details about the padding can be found in
Section 5.4 and Appendix E.3 of RFC 8446.
Paragraph (version B):
An on-path adversary observing the DTLS protocol exchanges between
the DTLS client and the DTLS server is able to link the observed
payloads to all subsequent payloads carrying the same ID pair (for
bi-directional communication).  Without multi-homing or mobility, the
use of the CID exposes the same information as the 5-tuple.
Paragraph (version B):
With multi-homing, a passive attacker is able to correlate the
communication interaction over the two paths and the sequence number
makes it possible to correlate packets across CID changes.  The lack
of a CID update mechanism in DTLS 1.2 makes this extension unsuitable
for mobility scenarios where correlation must be considered.
Deployments that use DTLS in multi-homing environments and are
concerned about this aspects SHOULD refuse to use CIDs in DTLS 1.2
and switch to DTLS 1.3 where a CID update mechanism is provided and
sequence number encryption is available.
Paragraph (version B):
The specification introduces record padding for the CID-enhanced
record layer, which is a privacy feature not available with the
original DTLS 1.2 specification.  Padding allows to inflate the size
of the ciphertext making traffic analysis more difficult.  More
details about record padding can be found in Section 5.4 and
Appendix E.3 of RFC 8446.
Paragraph (version B):
Finally, endpoints can use the CID to attach arbitrary metadata to
each record they receive.  This may be used as a mechanism to
communicate per-connection information to on-path observers.  There
is no straightforward way to address this concern with CIDs that
contain arbitrary values.  Implementations concerned about this
aspects SHOULD refuse to use CIDs.
Paragraph (version B):
An on-path adversary can create reflection attacks 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):
Additionally, an attacker able to observe the data traffic exchanged
between two DTLS peers is able to replay datagrams with modified IP
address/port numbers.
Paragraph (version B):
The topic of peer address updates is discussed in peer-address-
update.