Draft: draft-ietf-tls-dtls13

Commentary: The DTLS 1.2 Connection ID draft ( soon - to - be - RFC9146 ) section on " peer address update " and the text in DTLS 1.3 seems quite different . The " unless they first perform some reachability test " seems preferable to the soft text in soon - to - be - RFC9146 , but DTLS 1.3 seems to be missing the DTLS 1.2 requirement on " The received datagram is " newer " " . Feels spontanously like DTLS 1.2 and 1.3 should have similar requirements / guidance on " peer address update " . FYI , I started writing some analysis of Peer Address Update in a draft that I intend to submit to T2TRG 
 Would be good to warn implementations that clients must not update the permanent server address based on the “ Peer Address Update ” mechanism . Using IP addresses instead of DNS names is not uncommon in e.g. , IoT , DNS over DTLS ( RFC 8094 ) , and 3GPP DTLS interfaces . An client updating the permanent server address based on an MITM attack could be unable to recover . Would be good with a sentence or two on the problems changing the IP address of a gateway multiplexing a lot of DTLS connections with Connection ID . All the client and servers would have to send at least one record before the old IP address can be deactivated . Might take some time in a IoT deployment . 
 I tend to think we should at most provide warnings about how it 's dangerous . would you be willing to provide a quick PR ? 
 In the interest of being done I opted for basically punting it to a future spec .
Paragraph (version A):
The cookie exchange provides address validation during the initial
handshake.  DTLS with Connection IDs allows for endpoint addresses to
change during the association; any such updated addresses are not
covered by the cookie exchange during the handshake.  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 B):
The cookie exchange provides address validation during the initial
handshake.  DTLS with Connection IDs allows for endpoint addresses to
change during the association; any such updated addresses are not
covered by the cookie exchange during the handshake.  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 and
a future specification would need to specify a complete procedure for
how and when to update addresses.  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.