Change:
time constant.  Note that such implementations must still be able to send other length connection identifiers to other parties. <del> In DTLS 1.2, connection ids are exchanged at the beginning of the DTLS session only.  There is no dedicated "connection id update" message that allows new connection ids to be established mid-session, because DTLS 1.2 in general does not allow post-handshake messages that do not themselves begin other handshakes.  In DTLS 1.3, which does allow such messages, we use post-handshake message to update the connection ID post-handshake-messages and to request new IDs. DTLS 1.2 peers switch to the new record layer format when encryption is enabled.  The same is true for DTLS 1.3 but since the DTLS 1.3 enables encryption early in the handshake phase the connection ID will be enabled earlier.  For this reason, the connection ID needs to go in the DTLS 1.3 ServerHello. </del> <ins> In DTLS, connection ids are exchanged at the beginning of the DTLS session only.  There is no dedicated "connection id update" message that allows new connection ids to be established mid-session, because DTLS in general does not allow TLS 1.3-style post-handshake messages that do not themselves begin other handshakes.  DTLS peers switch to the new record layer format when encryption is enabled. </ins> 4. <del> In DTLS 1.3, if the client and server have negotiated the "connection_id" extension, either side can send a new connection ID which it wishes the other side to use in a NewConnectionId message: Indicates the CID which the sender wishes the peer to use. </del> <ins> This extension is applicable for use with DTLS and dtls-record12 illustrates the record format. </ins> <del> Indicates whether the new CID should be used immediately or is a spare.  If usage is set to "cid_immediate", then the new CID MUST be used immediately for all future records.  If it is set to "cid_spare", then either CID MAY be used, as described in sec- cons. If the client and server have negotiated the "connection_id" extension, either side can request a new CID using the RequestConnectionId message. </del> <ins> Note that for both record formats, it is not possible to parse the records without knowing how long the Connection ID is. </ins> <del> Endpoints SHOULD respond to RequestConnectionId by sending a NewConnectionId with usage "cid_spare" as soon as possible.  Note that an endpoint MAY ignore requests which it considers excessive (though they MUST be ACKed as usual). </del> <ins> In order to allow a receiver to determine whether a record has CID or not, connections which have negotiated this extension use new record types for all protected records. new-cid-content-types shows the record types to use: </ins> 5. <del> This extension is applicable for use with DTLS 1.2 and DTLS 1.3. This extension can be used with the optimized DTLS 1.3 record layer format. dtls-record12 and dtls-record13 illustrate the record formats of DTLS 1.2 and DTLS 1.3, respectively. Besides the "cid" field, all other fields are defined in the DTLS 1.2 and DTLS 1.3 specifications. Note that for both record formats, it is not possible to parse the records without knowing if the connection ID is in use and how long it is. </del> <ins> The CID value, when present, is included in the MAC calculation for the DTLS record.  It is created as follows: </ins> 6. <del> Below is an example exchange for DTLS 1.3 using a single connection id in each direction. Below is an example exchange for DTLS 1.2 using a connection id used uni-directionally from the client to the server. </del> <ins> dtls-example2 shows an example exchange where a connection id used uni-directionally from the client to the server in DTLS 1.2. </ins> 7.

Discussion:
Remove 1.3 references (based on Hannes's PR ); Protect CID; Initial sketch for explicit marking of CID records using ad hoc CTs.
I also do not understand that
Sorry, you're right. It needs to be in the MAC, but not the key derivation
I don't think we need to include the CID in the MAC since the CID is just the key name. In regular DTLS the 5 tuple is the key name and we don't include it in the MAC calculation either. If someone fakes a packet and places a wrong CID in there then they MAC will just fail since either (a) the wrong key will be looked up or (b) no key is found at all. In either case there is no issue.