Original text:
The length (in bytes) of the serialised DTLSInnerPlaintext (two- byte integer).  The length MUST NOT exceed 2^14.  Note "+" denotes concatenation. 5.1. The following MAC algorithm applies to block ciphers that do not use the with Encrypt-then-MAC processing described in RFC7366.  5.2. The following MAC algorithm applies to block ciphers that use the

Reviewer comments:
I added a placeholder seqnum in order to put the tls12cid in the right place. Note that I also did not add an ivlength. This is implicit in the ciphersuite selection and so you'd have to be making some quite strong assumptions to have the ivlength be necessary, it seems, and that's already the way things were without the CID, so presumably if those obtained you could still mount an attack.
NAME WDYT?
In my opinion, there is no reason to use a fixed head with "0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x19".
Well, I think I've explained the rationale for it in the text. Do you believe that the claimed properties are incorrect or merely that they're not necessary?
I understand your explanation to put 0xff 8 times in the front of the marker copy of tlscid. Though that results in a fixed header of 9 bytes, I'm curious, why that should improve the MAC. So back to my question before, why should there be the marker copy of the tlscid in front at all? It was said, that all versions use such marker (maybe that's also a misunderstanding). But at least, for 1.2, such markers wasn't the case. So, the discussion starts with: Why should the , a copy of something, which is already in the MAC, be additionally at the begin? Anyway, if the explanation gets too complex, and others don't feel curious as well, there is also no reason not to agree on that MAC definition of this PR; it could be obviously calculated.
Let me add: I'm not too happy with this proposal. But I will be even more unhappy, if this turns into a endless discussion. I would prefer some signs from others (NAME NAME if they are OK with it. Not to start in some weeks again with discussing the MAC over and over ...
The idea here is to provide domain separation between the MAC inputs when CID is in use and when it is not, for the reason Ben indicated, namely ensuring that an active attacker cannot create confusion about the inputs to the MAC. When CID is not in use, the first bytes are the 8-byte epoch/seq and the content type. Thus, if we want to ensure that the input is different when in use, then we must have 8 placeholder bytes and a different content type (or some other fixed-position distinguisher).
Isn't there is already a separator? In my opinion, the record-type does already provide that! All MAC starts with 8 bytes (epoch +seqn) followed by the record-type. Though that record-type of cid-records already differ from the other, non-cid, record-types, I simply don't see the benefit. An non-cid application-record use 0x17 at the 9th byte, with cid an application-record use 0x19.
Yes, that would be true if we weren't also moving the sequence number to make the DTLS header input into the MAC as-is rather than broken apart as it currently is. Once you've done that, then the type byte would be somewhere later in the packet -- in the version number if I am counting correctly.
I start to understand: In difference to RFC6347, now the header goes as on the wire into the MAC. For that, a artificial dummy header (fixed 9 byte) is put again in front of that, in order to ensure, that this differs from other records. Also as consequence, the cid-length is now between the dummy-header and the on-wire header.
LGTM
Good catch on the . Still looks good.
Duh. One more piece of evidence that it's hard to edit yourself. Updated.
NAME this LGTM. Let's run this past the list!
I am OK with the changes. It is time to wrap this work up.

Revised text:
The length (in bytes) of the serialised DTLSInnerPlaintext (two- byte integer).  The length MUST NOT exceed 2^14. <ins> 8 bytes of 0xff </ins> Note "+" denotes concatenation. 5.1. The following MAC algorithm applies to block ciphers that do not use the with Encrypt-then-MAC processing described in RFC7366. <ins> The rationale behind this construction is to separate the MAC input for DTLS without the connection ID from the MAC input with the connection ID.  The former always consists of a sequence number followed by some other content type than tls12_cid; the latter always consists of the seq_num_placeholder followed by tls12_cid.  Although 2^64-1 is potentially a valid sequence number, tls12_cid will never be a valid content type when the connection ID is not in use.  In addition, the epoch and sequence_number are now fed into the MAC in the same order as they appear on the wire. </ins> 5.2. The following MAC algorithm applies to block ciphers that use the