Change:
An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field.  This provides an opportunity for senders to pad any DTLS record by a chosen amount as long as the <del> total stays within record size limits.  See Section 5.4 of for RFC8446 more details.  (Note that TLSInnerPlaintext in that section refers to DTLSInnerPlaintext in this specification.) </del> <ins> total stays within record size limits.  See Section 5.4 of RFC8446 for more details.  (Note that the term TLSInnerPlaintext in RFC 8446 refers to DTLSInnerPlaintext in this specification.) </ins> The outer opaque_type field of a DTLSCiphertext record is always set to the value 25 (tls12_cid).  The actual content type of the

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