Change:
not wish the client to include a CID (or again, alternately, to use a zero-length CID). <del> When a session is resumed, the "connection_id" extension is negotiated afresh, not retained from previous connections in the session. </del> Because each party sends the value in the "connection_id" extension <del> that it wants to receive as a connection identifier in encrypted records, it is possible for an endpoint to use a globally constant length for such connection identifiers.  This can in turn ease parsing and connection lookup, </del> <ins> it wants to receive as a CID in encrypted records, it is possible for an endpoint to use a globally constant length for such connection identifiers.  This can in turn ease parsing and connection lookup, </ins> for example by having the length in question be a compile-time constant.  Implementations, which want to use variable-length CIDs, are responsible for constructing the CID in such a way that its <del> length can be determined on reception.  Note that such implementations must still be able to send connection identifiers of different length to other parties. Note that it is not possible to parse the records without knowing how long the CID is. </del> <ins> length can be determined on reception.  Such implementations must still be able to send CIDs of different length to other parties. Note that there is no CID length information included in the record itself. </ins> In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only.  There is no dedicated "CID update" message that allows new CIDs to be established mid-session, because DTLS 1.2 in general does not allow TLS 1.3-style post-handshake messages that do not <del> themselves begin other handshakes. DTLS peers switch to the new record layer format, i.e., the record layer format containing the CID, when encryption is enabled. </del> <ins> themselves begin other handshakes.  When a DTLS session is resumed or renegotiated, the "connection_id" extension is negotiated afresh. If DTLS peers have not negotiated the use of CIDs then the RFC 6347-defined record format and content type MUST be used. If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages then the peers need to take the following steps. The DTLS peers determine whether incoming and outgoing messages need to use the new record format, i.e., the record format containing the CID.  The new record format with the the tls12_cid content type is only used once encryption is enabled.  Plaintext payloads never use the new record type and the CID content type. For sending, if a zero-length CID has been negotiated then the RFC 6347-defined record format and content type MUST be used (see Section 4.1 of RFC6347) else the new record layer format with the tls12_cid content type defined in dtls-record12 MUST be used. When transmitting a datagram with the tls12_cid content type, the new MAC computation defined in mac MUST be used. For receiving, if the tls12_cid content type is set, then the CID is used to look up the connection and the security association.  If the tls12_cid content type is not set, then the connection and security association is looked up by the 5-tuple and a check MUST be made to determine whether the expected CID value is indeed zero length.  If the check fails, then the datagram MUST be dropped. When receiving a datagram with the tls12_cid content type, the new MAC computation defined in mac MUST be used.  When receiving a datagram with the RFC 6347-defined record format the MAC calculation defined in Section 4.1.2 of RFC6347 (and Section 4.1.2.4 of RFC6347 for use with AEAD ciphers) MUST be used. </ins> 4. This specification defines the DTLS 1.2 record layer format and I- D.ietf-tls-dtls13 specifies how to carry the CID in DTLS 1.3. <del> In order to allow a receiver to determine whether a record has CID or not, connections which have negotiated this extension use a distinguished record type tls12_cid(25).  Use of this content type has the following two implications: </del> <ins> To allow a receiver to determine whether a record has a CID or not, connections which have negotiated this extension use a distinguished record type tls12_cid(25).  Use of this content type has the following three implications: The CID field is present and contains one or more bytes. </ins> <del> The CID field is present </del> <ins> The MAC calculation follows the process described in mac. </ins> The true content type is inside the encryption envelope, as described below.

Discussion:
Text to address the discussion in URL
Completely re-wrote PR
Great work! So alternative I made it, right?
We now have to wait for Martin, Thomas, and Ekr to agree that the proposed changes are inline with their thinking and then I would submit a new version of the draft for the working group to look at.
Martin wrote: So proposal has not been made so far. We should discuss this idea. This is a new privacy-enhancing feature that does not necessarily have anything to do with the CID idea. In some sense this would allow the client and the server to negotiate the use of a traffic obfuscation technique. Achim, Ekr, Martin, etc. -- what do you think?
That's the discussions in issues and I linked to that issue in the previous PR as "Alternative III" URL To follow up the discussion is really difficult and time intensive. There is also one change left here URL That request to use the first CID not in FINISH and instead in the record after that.
I agree, this adds a new use-case to this draft and is not related to the CID idea. It's related to the usage of the new introduced record type. I created a issue about the scope of this draft , which mentions that additional use-case. In the meantime I closed that scope issue. My current impression is, that the discussions are split and really hard to follow. Therefore I closed my additional issues in hope, that focus on the CID idea makes it possible to "release" this draft sooner.
You are correct. The proposal has been made before. I was confused....
Achim, do you prefer to use "alternative III" instead of what I wrote-up today?
Btw, I added notes to the draft about the additional privacy features. So, I believe I captured the scope issue you raised.
I prefer any of the solutions! The difference between the flavours is for me much smaller, than the difference in shifting the timelines would be. For me, Hannes did a really great job. It would be also great, if you can give your "final" votes to give him a chance to finalize his work :-).
I can live with that proposal as well, as long as we agree that it's a violation to send an empty CID when one is expected.

The idea was to use the new record type even if an empty CID is negotiated. If a none empty CID is negotiated, then this none empty CID has to be used. The mentioned "violation" was, at least from my understand, not intended.
Fine! AFAIK all discussion about features/scope are concluded with that! FMPOV , . are fixed, when this PR is merged. will then be the only open issue, asking for implementations :-).
Uups, I think, I got a very late catch: URL If a zero-length CID has been negotiated, and therefore no CID appears on the wire, a cid_length of zero (0) MUST be added. Is not longer valid! For a empty CID, the RFC6347 record is used with the RFC6347 MAC and not the new MAC.

A zero-length value indicates that the client is prepared to send with a connection ID but does not wish the server to use one when sending (alternately, this can be interpreted as the client wishes the server to use a zero-length CID; the result is the same). This implies that an empty CID and an absent CID are identical. But they don't have to be. If both endpoints negotiate a zero- length CID, then this extension could be used to enable record padding. The doc is not clear on this point. If a peer sends an empty connectionid extension, what are you supposed to do: MUST send records in the old format. MUST send tls12cid records (which could be padded). MAY send either. It seems like option 2 or 3 give us a nice new feature - the ability to pad records - though 2 forces an additional overhead of 1 byte. Option 3 is somewhat less deterministic though (it doesn't seem like it would be harder to implement though).
I agree that the old text is wrong. It comes from a previous encoding and MAC structure. I don't care about the padding feature for (2) or (3), as this is a point fix for DTLS 1.2. I could live with (2) but the nondeterminism in (3) seems bad.
Addressed in submitted version -04
During the discussion of the last weeks, my impression of the scope of this draft has changed.

At the begin it was clearly the solution for issues caused by a NAT. With the questions from others about the usage of a empty CID in the MAC, I started to wonder, why this should be used. In the meantime in think, using the new record type (even with an empty CID) would enable peers to obfuscate the DTLS payload length. That feature may be even used without a real CID (therefore using a empty CID). I'm not sure, if this is really planned. I asked for it, but unfortunately, didn't receive an answer. If that usage is planned, I think it should be addressed explicitly. See: Issue URL And working on the implementation, I got also the idea, to use this extension to improve the protection of the handshake itself (see ). Currently the protection seems to be mainly the "randomness of the ip-address:port". But this randomness is not really defined and so using a random CID to lock the handshake may help. The interesting point of this usage would be, that it get's more important, when the address doesn't change (less randomness), so it targets the opposite environment as the original idea (frequently changing (by NAT) to static reachable). In the end this may end up in a "large CID used in the handshake" and no need to use the CID after the handshake. With these other "use-cases", I'm not sure, if the "strict" definitions in should be implemented or if the definitions should be "relaxed". The worst case would be, that the "strict" is mostly implemented, but the users also want the other scenarios independent for the "original idea".
See URL
URL FMPOV, searching for the "length field" assuming that it's that uint16 pointing to the end of the UDP datagram, should result in many cases in the right length for the connection id. Moving the connection id after the "length field", will hide it from that search, but with the AEAD explicit nonce copied from the header, it will also be easy to find there. Therefore, if it's intended to hide the connection id length in tls12_cid records, it must be after the "length field", and the explicit nonce could not longer be copied from the header to the fragment (saving 8 bytes).

It's no issue, if there is no intention to hide the connection id length. But then the misguided note above should be removed.
We're not hiding the CID length. It's transmitted in the clear in the handshake.
So what's the message of it is in many cases possible.
URL According RFC5246, the record layer protection is split into 3 sections NULL and stream (stream is not used for DTLS) CBC AEAD in this draft, only the NULL is referenced URL If the CID value should be included in that MAC, I would expect, that this draft specifies how to do this for all three variants. By the way, I'm not sure, why the CID should be explicitly included. The CID "points" to the "keys" used to calculate the MAC, with a wrong CID, the wrong "key" will be used and that should cause a MAC violation anyway.
I can fix this text, but there are multiple CIDs pointing to the same keys, so we need to have the CID in the MAC
Sorry, I didn't get that. Why are "multiple CIDs" pointing to the same keys? Is "keys" referring to URL may be I miss something, if ip-address:port is used to identify the "keys", the MAC ensures, that the same keys are used. But the MAC itself is not based on the ip-address:port. or I'm wrong? If, I didn't miss something, then the cid is not required to be directly included in the MAC, as the ip-address:port. Instead is indirect validated with the MAC, as the ip-address:port would also be validated.
You can change CIDs during the connection. Thus, if it's not included in the MAC, you can substitute CIDs.
Sorry, I still can't see the point. Do you mean, the CID could be exchanged during the transmission? FMPOV this seems to be no issue, which could be fixed by including it explicit in the MAC. The ip-address:port may also be exchanged, but are not included explicit in the MAC (this would fail on every NAT). Receiver side: Record contents get protected by a MAC calculated with . If the is exchanged during transmission with , this fails, because, no keys are mapped at the receiver.

If the is exchanged during transmission with , this fails, because, the receiver would try to validate the MAC using . For me, it's pretty the same, if you use the ip-address:port or CID to point to the keys, both are considered indirect and don't need to be included explicit. Or is there still a case, I missed?
You can have multiple valid CIDs for the same connection (and hence the same keys) at once. In this case, the attacker can swap them. Including the CID in the MAC protects against that. I understand your analogy with IP address, but this is internal to TLS and might be used by the implementation, and therefore the safest practice is to protect it, like everything else in the header.
I can't see, that this is valid for this version of the draft! If that is true, and the keys are generated in a way, which ensures that they are very likely to be unique for each session, how can I establish connections using different connections id but resulting in the same keys?
May be an handshakes example, which results in that, will clarify it.
Yes, but it might be true with some extension in the future. Moreover, authenticating the whole header is just good practice. In DTLS, connection ids are exchanged at the beginning of the DTLS session Ah.
But isn't the future DTLS 1.3? But the CID is authenticated! Indirect! And, if it's not included in the MAC, then the changes in the implementations should be much smaller. Unfortunately, I had some other reported issues in californium, so I was just able to start to implement CID, but I couldn't finish it right now. I would really prefer, if this draft focus on fixing the NAT pain in DTLS 1.2 and leave the future to DTLS 1.3. But that's just my preference, and not really an argument.
Is for? my argument is that wrong, that no more comment is required takes some time to think on it
typo.
Given that the CID replaces the IP:PORT tuple for TCP, not including in the MAC doesn't make the connection vulnerable to any attack that was not possible before. Indeed leaving it outside the calculations would make the DTLS1.2 implementation simpler and that's a plus.

Regarding the earlier point of not using the correct MAC definition I agree. Here is a proposed change: URL My suggestion is to only focus on AEAD ciphers. Regarding the question whether the inclusion of the cid, cid_length, etc. is necessary or not I am not entirely sure myself either since I cannot see the attack. I do, however, understand that it is good practice to include more information in the MAC.
I still feel, that this extended/changed MAC will introduce some misunderstandings.
I tried to improve clarity in the description. If there is a way to improve the text please let me know. I fear that not making any changes to the additional data computation will require a formal analysis to ensure that it is safe to use.
Yes, and I welcome that very much. FMPOV, it's open, what the "good practice" really includes. In TLS 1.2 it's the header and the "internal" seqnum to prevent repeats. With DTLS 1.2 it's parts of the header in order of the header, and, with the seqnum now also in the header, parts of the header not in order of that header. With this draft, not only the additional header field cid is added, it also adds the "internal" cidlength, and I'm wondering, why. With URL I'm not sure, what the order of the "good practice" should be. And agreeing with URL the other modes need to be defined also.
Will be fixed with
It probably makes sense to be a little more consistent.
Makes sense. I will do this after the current wave of pull requests have been reviewed and accepted/rejected.
I addressed this issue in PR
Addressed with submitted draft version -04