Change:
Use a new extension type instead.
Yes, if tls-flags are not usable for DTLS 1.2, then go with this.
We'd like to use to negotiate RRC. At the moment, the document seems to be defined for (D)TLS 1.3 only, but the reason why the same scheme would not be applicable to 1.2 are not fully clear. For now (-01), optimistically, we are using it in a version agnostic fashion, hoping that eventually that will be the case. Achim has opened an . This issue is for tracking on the RRC side.

Discussion:
3. <del> This specification uses the tls_flags extension defined in I-D.ietf- tls-tlsflags to allow a client and a server to negotiate support for this extension. </del> <ins> The use of RRC is negotiated via the "rrc" DTLS-only extension.  On connecting, the client includes the "rrc" extension in its ClientHello if it wishes to use RRC.  If the server is capable of meeting this requirement, it responds with a "rrc" extension in its ServerHello.  The "extension_type" value for this extension is TBD1 and the "extension_data" field of this extension is empty.  The client and server MUST NOT use RRC unless both sides have successfully exchanged "rrc" extensions. </ins> <del> The RRC flag is assigned the value (TBD1) and is used in the ClientHello (CH) and the ServerHello (SH). </del> <ins> Note that the RRC extension applies to both DTLS 1.2 and DTLS 1.3. </ins> 4.

before cryptographically validating the enclosed record(s) but instead perform a return routability check. <del> The newly introduced return_routability_check message contains a </del> <ins> The newly introduced "return_routability_check" message contains a </ins> cookie.  The cookie is a 8-byte field containing arbitrary data. <del> The return_routability_check message MUST be authenticated and </del> <ins> The "return_routability_check" message MUST be authenticated and </ins> encrypted using the currently active security context. The receiver that observes the peer's address and or port update MUST

a TBD threshold) and initiate the return routability check that proceeds as follows: <del> A cookie is placed in a return_routability_check message of type </del> <ins> A cookie is placed in a "return_routability_check" message of type </ins> path_challenge; The message is sent to the observed new address and a timeout T is started; The peer endpoint, after successfully verifying the received <del> return_routability_check message echoes the cookie value in a return_routability_check message of type path_response; </del> <ins> "return_routability_check" message echoes the cookie value in a "return_routability_check" message of type path_response; </ins> When the initiator receives and verifies the <del> return_routability_check message contains the sent cookie, it </del> <ins> "return_routability_check" message contains the sent cookie, it </ins> updates the peer address binding; If T expires, or the address confirmation fails, the peer address

7. IANA is requested to allocate an entry to the TLS "ContentType" <del> registry, for the return_routability_check(TBD) defined in this document. IANA is requested to allocate an entry to the TLS Flags registry in the tls_flags type: Value: [[IANA please assign a value from the 32-63 value range.]] Flag Name: RRC Message: CH,SH Recommended: Y </del> <ins> registry, for the "return_routability_check(TBD2)" defined in this document.  The "return_routability_check" content type is only applicable to DTLS 1.2 and 1.3. </ins> <del> Reference: [[This document]] </del> <ins> IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext. </ins> 8.