Change:
for more details.  (Note that the term TLSInnerPlaintext in RFC 8446 refers to DTLSInnerPlaintext in this specification.) <del> The outer opaque_type field of a DTLSCiphertext record is always set to the value 25 (tls12_cid).  The actual content type of the record is found in DTLSInnerPlaintext.type after decryption.  By encapsulating the true content type inside the encrypted payload the outer content type (special_type) can be used to signal the new record layer format containing the CID. </del> <ins> The DTLSInnerPlaintext value is then encrypted and the CID added to produce the final DTLSCiphertext. </ins> <del> The DTLSCiphertext.version field describes the protocol being employed.  This document describes an extension to DTLS version 1.2. </del> <ins> The outer content type of a DTLSCiphertext record carrying a CID is always set to the value 25 (tls12_cid).  The actual content type of the record is found in DTLSInnerPlaintext.real_type after decryption. </ins> <del> The DTLSCiphertext.length field indicates the length (in bytes) of the following DTLSCiphertext.encrypted_record, which is the sum of the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. </del> <ins> The CID value, cid_length bytes long, as agreed at the time the extension has been negotiated. </ins> <del> The CID value of length indicated with cid_length, as agreed during the exchange. </del> <ins> The encrypted form of the serialized DTLSInnerPlaintext structure. </ins> <del> The AEAD-encrypted form of the serialized DTLSInnerPlaintext structure. Other fields are defined in RFC 6347.  Note that this specification does not make use of the DTLSCompressed structure. </del> <ins> All other fields are as defined in RFC 6347. </ins> 5. <del> This specification changes the MAC calculation defined in Section 4.1.2 of RFC 6347.  At the time of writing ciphers using authenticated encryption with additional data (AEAD) were state-of- the-art.  Hence, this specification updates only the additional data calculation defined in Section 6.2.3.3 of RFC5246, which is re-used by Section 4.1.2.1 of RFC6347. </del> <ins> This specification modifies the MAC calculation defined in RFC6347 and RFC7366 as well as the definition of the additional data used with AEAD ciphers provided in RFC6347 for records with content type tls12_cid.  The modified algorithm MUST NOT be applied to records that do not carry a CID, i.e., records with content type other than tls12_cid. </ins> <del> The additional data calculation is extended as follows: </del> <ins> Block Ciphers: </ins> <del> As described in Section 6.2.3.3 of RFC5246 this 64-bit value is formed by concatenating the epoch and the sequence number in the order they appear on the wire. </del> <ins> Block Ciphers with Encrypt-then-MAC processing: </ins> <del> This value contains the outer-header content type, i.e. the tls12_cid. </del> <ins> AEAD Ciphers: </ins> <del> This value contains the version number. This value contains the length information in the outer-header. </del> Value of the negotiated CID. 1 byte field indicating the length of the negotiated CID. <ins> All other fields are as defined in the cited documents. The length (in bytes) of the serialised DTLSInnerPlaintext.  The length MUST NOT exceed 2^14. </ins> 6. dtls-example2 shows an example exchange where a CID is used uni-

Discussion:
As discussed with Hannes, this PR replaces
We currently only describe CID processing with AEAD ciphersuites, which seems to imply that the CID extension effectively influences ciphersuite negotiation. The draft should explain how the two - ciphersuite negotiation and CID ext - interact.
I'm not sure, what the scope of this explanation should be? For the MAC, it seems to be obvious, that the block cipher (URL ) extend the data for the MAC accordingly. URL will get That was already discussed in URL So, I'm not sure, if you are the intended "Thomas", which may write that :-)
The question is whether we should define the CID-enhanced MAC calculation for non-AEAD ciphers. The current draft only supports AEAD ciphers. If that's OK then we could just tell implementers that the ciphersuite selection should be influenced by this. Alternatively, we could define the MAC calculation also for non-AEAD ciphers. What would you prefer, Achim?
The latter, I think...
Though Leshan (LWM2M, also supporting CBC) is one of the major using and contributing projects, I would also prefer to have the MAC defined for the none-AEAD.
Here is the PR: URL