Section 4.2.2 of HTTP. When an HTTP/2 connection is established, both the client and server <del> have to send a SETTINGS_ENABLE_WEBTRANSPORT setting to indicate that they both support WebTransport over HTTP/2. The server also needs to send a SETTINGS_WEBTRANSPORT_MAX_SESSIONS setting with a value greater than "0" to indicate the number of concurrent sessions it is willing to receive. </del>  A client initiates a WebTransport session by sending an extended CONNECT request RFC8441.  If the server accepts the request, a 3.1. In order to indicate support for WebTransport, both the client and <del> the server MUST send a SETTINGS_ENABLE_WEBTRANSPORT value set to "1" in their SETTINGS frame.  Endpoints MUST NOT use any WebTransport- related functionality unless the parameter has been negotiated. </del>  3.2. RFC8441 defines an extended CONNECT method in features, enabled by the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  An endpoint needs to send both SETTINGS_ENABLE_CONNECT_PROTOCOL and <del> SETTINGS_ENABLE_WEBTRANSPORT for WebTransport to be enabled. </del>  3.3. 10.1. <del> The following entries are added to the "HTTP/2 Settings" registry </del>  established by RFC7540: <del> The "SETTINGS_ENABLE_WEBTRANSPORT" parameter indicates that the specified HTTP/2 connection is WebTransport-capable. ENABLE_WEBTRANSPORT 0x2b603742 0 This document </del> The "SETTINGS_WEBTRANSPORT_MAX_SESSIONS" parameter indicates that the specified HTTP/2 connection is WebTransport-capable and the number of <del> concurrent sessions it is willing to receive.  The default value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that the server is not willing to receive any WebTransport sessions. </del>  WEBTRANSPORT_MAX_SESSIONS

Remove SETTINGSENABLEWEBTRANSPORT in favor of SETTINGSWEBTRANSPORTMAX_SESSIONS.
I can't seem to remember or work out what the purpose of SETTINGSENABLEWEBTRANSPORT is now that we have SETTINGSWEBTRANSPORTMAXSESSIONS. This leads to the following questions: If the server sends SETTINGSWEBTRANSPORTMAXSESSIONS>0 but SETTINGSENABLEWEBTRANSPORT=0, what does that mean? If the client sends SETTINGSENABLEWEBTRANSPORT=0 but sends a WebTransport request, what is the purpose of having the server fail the request?
Yeah, I thought that we would remove SETTINGSENABLEWEBTRANSPORT when the session limit was added. If nothing else, it removes those awkward interactions.
Chair: discussed in editor's meeting, sounds like we should remove SETTINGSENABLEWEBTRANSPORT. We might add another setting to be removed by the RFC editor for versioning between drafts
IIRC, we discussed at IETF 115 and only the server needed to send MAX_SESSIONS, so we kept both. Can spell that either way though.
If we're doing this for H2, should we also do it for H3, since we have SETTINGSMAXWEBTRANSPORT_SESSIONS there, too?
h3 requires SETTINGSENABLEWEBTRANSPORT because it changes the format of server-initiated bidi streams h2 has no such requirement for a setting

Section 4.2.2 of HTTP. When an HTTP/2 connection is established, both the client and server  <ins> have to send a SETTINGS_WEBTRANSPORT_MAX_SESSIONS setting with a value greater than "0" to indicate that they both support WebTransport over HTTP/2.  For servers, the value of the setting is the number of concurrent sessions the server is willing to receive. Clients cannot receive incoming WebTransport sessions, so any value greater than "0" sent by a client simply indicates support for WebTransport over HTTP/2. </ins> A client initiates a WebTransport session by sending an extended CONNECT request RFC8441.  If the server accepts the request, a 3.1. In order to indicate support for WebTransport, both the client and  <ins> the server MUST send a SETTINGS_WEBTRANSPORT_MAX_SESSIONS value greater than "0" in their SETTINGS frame.  Endpoints MUST NOT use any WebTransport-related functionality unless the parameter has been negotiated. </ins> 3.2. RFC8441 defines an extended CONNECT method in features, enabled by the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  An endpoint needs to send both SETTINGS_ENABLE_CONNECT_PROTOCOL and  <ins> SETTINGS_WEBTRANSPORT_MAX_SESSIONS for WebTransport to be enabled. </ins> 3.3. 10.1.  <ins> The following entry is added to the "HTTP/2 Settings" registry </ins> established by RFC7540:  The "SETTINGS_WEBTRANSPORT_MAX_SESSIONS" parameter indicates that the specified HTTP/2 connection is WebTransport-capable and the number of  <ins> concurrent sessions an endpoint is willing to receive.  The default value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that the endpoint is not willing to receive any WebTransport sessions. </ins> WEBTRANSPORT_MAX_SESSIONS


10.1. <del> IANA is requested to add an extra column to the "TLS ExtensionType Values" registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. </del>  10.2. IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, for connection_id(TBD1) as described <del> in the table below. </del>  Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document

Suggest a column name. Deprecate the old connection_id codepoint.
NAME
We currently have an early allocation of the TLS extensiontype codepoint 53 that was allocated on 2019-07-02. An implementation of the draft at that time will no longer interoperate with the current specification due to changes in how the MAC inputs and AAD are laid out. If we want to allocate a new extensiontype value for the new semantics, we should tell IANA that there is an existing early allocation and, e.g., that it should be left to expire (and what version of the draft to use as a reference until it does), with a new codepoint to be allocated in its stead. We also have the option to direct IANA that "once this document is approved for publication, the early allocation will be deprecated and the following assignment will be made".
I think we should take your last option.
See suggestion inline, though even as-is this is probably enough to cause the right things to happen at IANA and the RPC.

10.1.  <ins> IANA is requested to add an extra column named "DTLS-Only" to the "TLS ExtensionType Values" registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. </ins> 10.2. IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, for connection_id(TBD1) as described  <ins> in the table below.  Although the value 53 has been allocated by early allocation for a previous version of this document, it is incompatible with this document.  Once this document is approved for publication, the early allocation will be deprecated in favor of this assignment. </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document


identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time constant.  Such implementations MUST still be able to send CIDs of <del> different length to other parties.  Implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception.  Note that there is no CID length information included in the record itself. </del>  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

Partly addresses
URL
Regarding: We could streamline that a bit: removing the affiliations (who knows which have become stale in the meantime?), and also Besides, is "task force" the right term? Would "QUIC CID design team" be a better designation? Robert Wilton has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Hi, I'm no DTLS expert, but I found the concepts/explanation in this document easy to follow. I was slightly confused by the requirement to encode the length in variable length CIDs, and had to read the relevant text a second time. As a suggestion, it might help if these two sentences were reworded the other way round: OLD: Implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception. Note that there is no CID length information included in the record itself. NEW: Since the CID length information is not included in the record itself, implementations that want to use ... . One minor question. In the contributors, I noted that Jana is listed as being associated with Google, but it might be worth checking if that is still accurate. Regards. Rob

identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time constant.  Such implementations MUST still be able to send CIDs of  <ins> different length to other parties.  Since the CID length information is not included in the record itself, implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception. </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


Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for <del> an endpoint to use a globally constant length for such connection identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time constant.  Such implementations MUST still be able to send CIDs of different length to other parties.  Since the CID length information is not included in the record itself, implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception. </del>  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

attempt at addressing Warren's concern about the use of "globally"
You're right, the "globally" seems to be used in the sense of a "programming language", so the scope is a peer and the CID emitted by this peer for other peers to be used, when the other peers sends records to the emitting peer. Maybe we find a better term than "globally" to describe that.
maybe "sitewide"?

Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for  <ins> an endpoint to use a deployment-specific constant length for such connection identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile- time constant.  Such implementations MUST still be able to send CIDs of different length to other parties.  Since the CID length information is not included in the record itself, implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception. </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


When receiving a datagram with the tls12_cid content type, the new MAC computation defined in mac MUST be used.  When receiving a <del> datagram with the RFC 6347-defined record format the MAC calculation </del>  defined in Section 4.1.2 of RFC6347 MUST be used. 4. The MAC calculation follows the process described in mac. <del> The true content type is inside the encryption envelope, as </del>  described below. Plaintext records are not impacted by this extension.  Hence, the 1 byte field indicating the length of the negotiated CID. <del> The length (in bytes) of the serialised DTLSInnerPlaintext (two- </del>  byte integer).  The length MUST NOT exceed 2^14. 8 bytes of 0xff 6. When a record with a CID is received that has a source address <del> different than the one currently associated with the DTLS connection, </del>  the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received <del> datagram unless the following three conditions are met: </del>  The received datagram has been cryptographically verified using the DTLS record layer processing procedures. 10. <del> This document requests three actions by IANA. </del>  10.1.

FWIW, I think some of these are gratuitous but they're not harmful.
URL Lars Eggert has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: All comments below are about potential very minor issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools, so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 3, paragraph 10, nit: Broken kramdown reference? Section 1, paragraph 4, nit: This document defines an extension to DTLS 1.2 to add a CID to the This document defines an extension to DTLS 1.2 to add a Connection ID (CID) to the ++++++++++ ++++++ Section 3, paragraph 7, nit: for example by having the length in question be a compile-time for example, by having the length in question be a compile-time + Section 3, paragraph 7, nit: different length to other parties. Implementations that want to use variable-length CIDs are responsible for constructing the CID in such different lengths to other parties. Implementations that want to use + variable-length CIDs are responsible for constructing the CIDs in such + Section 3, paragraph 12, nit: datagram with the RFC 6347-defined record format the MAC calculation datagram with the RFC 6347-defined record format, the MAC calculation + Section 4, paragraph 6, nit: The true content type is inside the encryption envelope, as - - The real content type is inside the encryption envelope, as ++ Section 6, paragraph 2, nit: datagram unless the following three conditions are met: datagram, unless all of the following three conditions are met: + +++++++ Section 10, paragraph 2, nit: This document requests three actions by IANA. ^^ This document requests three actions from IANA. ^^^^ Section 4, paragraph 17, nit: If 'type' is a classification term, 'a' is not necessary. Use "type of". (The phrases 'kind of' and 'sort of' are informal if they mean 'to some extent'.) Section 4, paragraph 19, nit: Make sure that 'use to' is correct. For habitual actions in the past or to mean 'accustomed to', use "used to". Section 5, paragraph 6, nit: Do not mix variants of the same word ('serialise' and 'serialize') within a single text. Section 6, paragraph 2, nit: Did you mean 'different "from"? 'Different than' is often considered colloquial style. Section 6, paragraph 2, nit: Consider using "all the". "Appendix A.", paragraph 1, nit: Maybe you need to remove the second determiner so that only "THE" or "THIS" is left. "Appendix A.", paragraph 29, nit: 'a la' is an imported foreign expression, which originally has a diacritic. Consider using "à la" "Appendix B.", paragraph 1, nit: Maybe you need to remove the second determiner so that only "THE" or "THIS" is left. "Appendix C.", paragraph 1, nit: Use a comma before 'and' if it connects two independent clauses (unless they are closely connected and short). These reference issues exist in the document: No reference entries found for: [ChangeCipherSpec], [length], [lengthofpadding], [URL], [draft-rescorla-tls-dtls-connection-id-00], [cid_length], [URL] Uncited references: [RFC5246] Obsolete reference to RFC5246, obsoleted by RFC8446 These URLs in the document did not return content: URL URL URL

When receiving a datagram with the tls12_cid content type, the new MAC computation defined in mac MUST be used.  When receiving a  <ins> datagram with the RFC 6347-defined record format, the MAC calculation </ins> defined in Section 4.1.2 of RFC6347 MUST be used. 4. The MAC calculation follows the process described in mac.  <ins> The real content type is inside the encryption envelope, as </ins> described below. Plaintext records are not impacted by this extension.  Hence, the 1 byte field indicating the length of the negotiated CID.  <ins> The length (in bytes) of the serialized DTLSInnerPlaintext (two- </ins> byte integer).  The length MUST NOT exceed 2^14. 8 bytes of 0xff 6. When a record with a CID is received that has a source address  <ins> different from the one currently associated with the DTLS connection, </ins> the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received  <ins> datagram, unless the following three conditions are met: </ins> The received datagram has been cryptographically verified using the DTLS record layer processing procedures. 10.  <ins> This document requests three actions from IANA. </ins> 10.1.


records without knowing how long the Connection ID is. In order to allow a receiver to determine whether a record has CID or <del> 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: </del>  5. <del> The CID value, when present, is included in the MAC calculation for the DTLS record.  The MAC algorithm described in Section 4.1.2.1 of RFC6347 and Section 6.2.3.1 of RFC5246 is extended as follows: </del>  6.

discussed in YUL. NAME
URL Still contains the content types removed in PR . alertwithcid(25) handshakewithcid(26) applicationdatawithcid(27) heartbeatwithcid(28) I guess, it should be updated towards PR ? tls12cid(25)
The PR can be found here: URL
The PR will fix it.
If you subscribe to the theory that DTLS has to mux with the realtime protocols, this takes a good slice of the remaining codepoints space. Though TLS has between 20 and 63, DTLS 1.3 takes 32-63 and the registration of 4 more would leave just 3: 29, 30, and 31. I submit that we might be better considering the TLS 1.3 record construction with a single codepoint. That would get us content type encryption and arbitrary padding as a secondary benefit. All for the modest cost of one octet.
If DTLS 1.3 used a demux prefix scheme like the one proposed , this should be no longer an issue.
Addressed in

records without knowing how long the Connection ID is. In order to allow a receiver to determine whether a record has CID or  <ins> 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: The CID field is present The true content type is inside the encryption envelope, as described below. </ins> 5.  <ins> When CID is being used, the DTLSCompressed value is first wrapped along with the true content type and padding into a DTLSWrappedCompressed value prior to encryption.  The DTLSWrappedCompressed value is then encrypted. The value of DTLSCompressed.fragment The true content type. Padding, as defined in RFC8446. In addition, the CID value is included in the MAC calculation for the DTLS record as shown below.  The MAC algorithm described in Section 4.1.2.1 of RFC6347 and Section 6.2.3.1 of RFC5246 is extended as follows: </ins> 6.


rebinding leads to connection failure, with the resulting cost of a new handshake. <del> This document defines an extension to DTLS to add a connection ID to the DTLS record layer.  The presence of the connection ID is </del>  negotiated via a DTLS extension. 2. The extension type is specified as follows. The extension_data field of this extension, when included in the <del> ClientHello, MUST contain the CID structure, which carries the CID which the client wishes the server to use when sending messages towards it.  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 </del>  client wishes the server to use a zero-length CID; the result is the same). With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further <del> privacy concerns.  In order to prevent this, implementations SHOULD attempt to use fresh connection IDs whenever they change local addresses or ports (though this is not always possible to detect). </del>  Importantly, the sequence number makes it possible for a passive attacker to correlate packets across CID changes.  Thus, even if a

This is pretty trivial, but the first use of CID in the draft isn't mated to the expanded "connection ID". Probably more seriously, that first mention is actually to cite a struct: The structure is called .

rebinding leads to connection failure, with the resulting cost of a new handshake.  <ins> This document defines an extension to DTLS to add a connection ID (CID) to the DTLS record layer.  The presence of the connection ID is </ins> negotiated via a DTLS extension. 2. The extension type is specified as follows. The extension_data field of this extension, when included in the  <ins> ClientHello, MUST contain the ConnectionId structure, which carries the CID which the client wishes the server to use when sending messages towards it.  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 </ins> client wishes the server to use a zero-length CID; the result is the same). With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further  <ins> privacy concerns. </ins> Importantly, the sequence number makes it possible for a passive attacker to correlate packets across CID changes.  Thus, even if a


the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm.  The AEAD-encrypted form of the serialized DTLSInnerPlaintext structure. does not make use of the DTLSCompressed structure. In addition, the CID value is included in the MAC calculation for the <del> DTLS record, as shown below.  The MAC algorithm described in Section 4.1.2.1 of RFC6347 and Section 6.2.3.1 of RFC5246 is extended as follows: </del>  <del> The "cid_length" field is a single octet containing the length of the connection ID. </del>  5.

According URL this is obvious far away from "appropriate". I would appreciate, if the scope of this draft could be clarified, before adding additional features.
The issue you raised in URL is important and will be addressed in a separate PR. I would like to merge some of the PRs to that we do not have too many conflicts. This PR only provides the text for the additional_data and, since we have changed our mind about it so many times already, I would like to get it into the working draft. Then, Thomas can make a contribution for the MAC calculation for non-AEAD ciphers.
NAME Thank you very much for great patience! It's sure still easy to implement, even with a new MAC for the old RFC 6347 record. As I tried to point out, if there are new use-cases, they should not be obfuscated by introducing only "maverick fields" somewhere, in my opinion, they should be addressed clearly. I still see no argument to include the cid_length into the MAC.
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 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
If this feature is negotiated on, then the MAC calculation changes, even if no connection ID is sent, because of . This needs to be clearly sign-posted.
My preferred interpretation is: uses the original RFC6347, section 4.1 record format URL indicated by the already used content type ids. That includes also the unchanged MAC.
Created a pull request to add clarifying text: URL
NAME it would be great, if you could explain, if you want to use the new record type with an empty CID in order to obfuscate the DTLS payload length. Please note, that currently the specification of this draft turns more into a "strict" usage (see issue ) which will not support the new record type with an empty CID.
Interesting question. Yes, I would like to be able to use the new record type to pad records, but I don't think that it is an especially important consideration. If the design is easier without that, and I suspect that it is, then I am OK with not doing that. A one-octet connection ID is not that much of a burden to pay to get this feature.
So you would then got for adding a 1 byte cid, but still use the ip-address:port to map it to the security context (keying stuff)? Or do you consider only a few connections? For me that is just one of the scenario's, I'm really afraid of! It makes the usage of cid more indeterministic, if the spec "ignores" that kind of usage instead of explicitly considering it! FMPOV, it will be easier, to support then a empty CID record indicating, that still the ip-address:port must be used instead of a 1 byte cid, but then being not strict on the mapping.
Addressed in submitted version -04
Is there a implementation available to test interoperability? I currently plan to introduce in a open source project (californium/scandium, URL) and it would make it much easier, if such a implementation is available.
Huawei is working an updated implementation and so do I. We can start interop testing in Jan 2019, if you want.
That would be great. At least "with itself", californium's scandium works in the meantime :-) ! For interop testing, the used number for the extension in the test should be clear. And the content and format of the additional data. My current state of work in progress: URL The demo-apps/cf-secure is prepared to used a CID (client -> server).
I have cloned the californium repo and switched to the branch. Unfortunately, I get errors when I try to compile the project using instructions in the URL file.
another WIP implementation is at URL
reports errors? Could you please provide the log with the errors? Here, or may be as comment in URL
Great, I will try that at the weekend.
NAME I managed to try your dtls-cid implementation. Unfortunately, the implementation seems not to share a common cipher suite with californium/scandium. From your CLIENTHELLO From my CLIENTHELLO using X509
NAME I add to my wip and validated its compatibility with openssl (see scripts in californium demo-apps/cf-secure folder). But with the GO implementation I could not establish successfully a connection. As far as I could analyze, the master secret is the same, but the hash of the messages differs. Anyway, maybe you can check the compatibility with openssl using that cipher suite ? (I would have created an issue in the linked github repo, but I couldn't find the button for new issues there.)
Though GO uses the currently next "unassigned number for extensions (52)", I can switch to that. Does mbedTLS uses also this number?
NAME I added now also TLSECDHEECDSAWITHAES128GCMSHA256 (0xc02b). Same result, works with openssl but GO reports: I pushed the changes to my wip. I tested using GO as server (port 5684) and the cf-secure with argument .
The californium wip is online :-). URL for coap over dtls supporting cid after the handshake URL for coap over dtls supporting cid also during the handshake For no coap clients, just send four bytes 40 00 12 35 (coap ping with MID 1235). The answer should be 70 00 12 35 (RST for MID 1235).
NAME great! I've just tried my client against this endpoint. Client sends the CID extension (I'm using 52) with a 0-length CID and gets back an handshake failure alert after CH.
I have fixed one thing on server side and now I have no problem interop'ing with openssl (both client and server). Could you please try again?
I adapted to that value in the wip. After CLIENTHELLO? Could your please provide the wireshark capture of your CH? The cid in the extension is documented as So I encoded it with "uint8 cidlength, cid-bytes". do you use also a length?
Thanks for the update! I will check it today a little later.
This is the 0-length CID extension sent by the client: Is this not what you'd expect?
Cool; one limitation to be aware of is that my client currently only handles certificate chains of length one :-)
FYI: I'm running locally and I get the same behaviour as above when I run it without specifying on the command line: Is this maybe the case for the public endpoint? Another interesting thing I've noticed while running locally is that even though my client sends the (0-length) CID extension, server seems to ignore it (it's not mirrored in the SH).
Please update my wip (git pull --force). You use cidlength and cid in the aad? With the go server and the cf-secure client using "X509TRUST CID:0" I get a "Connected" and then a "Disconnected" (maybe the binary payload is not expected). With cf-secure server "X509 NO_AUTH CID:4" and your client I get "panic: dtls: Expected and actual key signature do not match". I will check that more detailed at the weekend.
yes, please add "CID:4" to the argument line. And NO_AUTH to suppress the client certificate request.
The captures with the certificates. Where can I find your certificate? May be using that is more successful :-).
Some updates: The go implementation seems to have issues as client, if the group is used instead of . You may check this with openssl using "-namedcurve prime256v1" to force openssl to use the instead of . (Californium/scandium currently doesn't support .) The reported error from go is "Expected and actual key signature do not match", with both openssl and californium/scandium as server. Using go as server doesn't show this effect and the handshake can be finished. Using the cidlength in aad (PR would removed that) and always add a 0 pad (even if AEAD is used, which doesn't require padding) I can send data successfully to the go server. Go currently doesn't send the FINISHED with tlscid and if a FINISHED with tlscid is received, " unhandled wrapped content type: 22" is reported. I prepared a work around commit, but I must clean it up much more before I can PUSH it. I hope I can update the wip during this week (may be today). NAME If possible, can you check the go client forcing to use ?
I pushed the update and left a comment URL
hi NAME thanks! this should be fixed
quick update: Scandium and the go implementation interop OK, both client and server and over volatile 4-tuples. Cool :-)
Indeed! The basic idea of this draft is really straight forward to implement. Some of the crypto-details, which are discussed (e.g. MAC) must sure be implemented based on the same definition, but that's not too surprising. FMPOV, for sustainability, the scope of the draft should be discussed. Otherwise I would be afraid, that assumption for "special use-cases" will break too much the interoperability. But lets open a new issue for that.
NAME URL "I believe we should allow cid usage already in the handshake itself rather than just for application layer payloads." I will try to polish my approach over the next weekend and push it to the californium sandbox (URL) (5684 will be "cid not used in the handshake").
I tried to compile the Californium code and here are the error messages I get: [ERROR] /home/hannes/californium/californium-URL Undefined reference: void URL() [ERROR] /home/hannes/californium/californium-URL Undefined reference: void Throwable.addSuppressed(Throwable) [ERROR] /home/hannes/californium/californium-URL Undefined reference: void URL() [ERROR] Failed to execute goal URL (default) on project californium-core: Signature errors found. Verify them and ignore them with the proper annotation if needed. -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] URL [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :californium-core
Which java jdk do you use? If I remember well, I saw a similar error last year, when I used java11 on ubuntu 18.04. With the current jave update it seems to be solved. I use java8 (build 1.8.0191-8u191-b12-2ubuntu0.18.04.1-b12) and java11 (build 11.0.1+13-Ubuntu-3ubuntu118.04ppa1). If you use the "wipadddtlscid" please note, that the last commit contains fixes for go. Please use the commit before that (currently df6464eb9390). Scandium uses currently 52 for the hello extension.
The "tlscidrecord-already-in-handshake" is removed :-), "the commit before the go fixes" should comply to the current version of this spec.
openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4) OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed mode) javac 10.0.2 Do you have a virtual machine somewhere with Californium running properly?
URL it runs the "etsi plugtest server". PSK credentials identity "password" secret "sesame" (or hex 736573616D65) Since today, the snapshot of the plugtest server is also available at URL for download. If you put also direct before the class definition, it may also compile with java 10. But it's not that tested with java 10 (closer to not tested :-) ).
If you want to use a coap-request GET URL
I re-installed a new version of Ubuntu from scratch and the error is gone.
:-). That sounds good. Remember not to use the HEAD of the wip-branch, it contains the fixes for the "go" implementation (finish without cid). Please use the commit before.
NAME In the meantime I was able to test your update. The FINISH seems to be still a HANDSHAKE record instead of a TLS_CID record. All other issues are solved.
Just for those, who are interested: Based on the CID and the californium implementation I prepared a demonstration load-balancer setup. See URL
I'm going to close this because we want to get to issues 0.
These changes look appropriate.

the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. <ins> The cid value of length indicated with cid_length, as agreed during the exchange. </ins> The AEAD-encrypted form of the serialized DTLSInnerPlaintext structure. does not make use of the DTLSCompressed structure. In addition, the CID value is included in the MAC calculation for the  <ins> DTLS record layer.  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. The additional data calculation is extended as follows: 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. This value contains the outer-header content type, i.e. the tls12_cid. This value contains the version number. This value contains the length information in the outer-header. Value of the negotiated cid.  This field is empty in case a zero- length cid has been negotiated. </ins>  <ins> 1 byte field indicating the length of the negotiated cid.  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. </ins> 5.


Abstract <del> This document specifies the "Connection ID" concept for the Datagram Transport Layer Security (DTLS) protocol, version 1.2 and version 1.3. </del>  A Connection ID is an identifier carried in the record layer header that gives the recipient additional information for selecting the updated once the key lifetime expires. In the current version of DTLS, the IP address and port of the peer <del> is used to identify the DTLS association.  Unfortunately, in some </del>  cases, such as NAT rebinding, these values are insufficient.  This is <del> a particular issue in the Internet of Things when the device needs to enter extended sleep periods to increase the battery lifetime and is therefore subject to rebinding.  This leads to connection failure, with the resulting cost of a new handshake. </del>  This document defines an extension to DTLS to add a connection ID to <del> each DTLS record.  The presence of the connection ID is negotiated via a DTLS extension.  It also defines a DTLS 1.3 post-handshake message to change connection ids. </del>  2. "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. <del> The reader is assumed to be familiar with the DTLS specifications since this document defines an extension to DTLS 1.2 and DTLS 1.3. </del>  3. The extension type is specified as follows. The extension_data field of this extension, when included in the <del> ClientHello, MUST contain the CID structure, which contains the CID </del>  which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client is prepared to send with a connection ID but does not wish the server to same). A server which is willing to use CIDs will respond with its own <del> "connection_id" extension, containing the CID which it wishes the client to use when sending messages towards it.  A zero-length value indicates that the server will send with the client's CID but does not wish the client to use 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 Previous design ideas for using cryptographically generated session ids, either using hash chains or public key encryption, were dismissed due to their inefficient designs.  Note that a client <del> always has the chance to fall-back to a full handshake or more precisely to a handshake that uses session resumption (DTLS 1.2 language) or to a PSK-based handshake using the ticket-based approach. </del>  Because each party sends in the extension_data the value that it will receive as a connection identifier in encrypted records, it is 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>  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>  <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>  <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>  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>  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>  7. contain arbitrary values; implementations concerned about this SHOULD refuse to use connection ids. <del> An on-path adversary, who is able to observe the DTLS 1.2 protocol </del>  exchanges between the DTLS client and the DTLS server, is able to link the observed payloads to all subsequent payloads carrying the <del> same connection id pair (for bi-directional communication).  In DTLS 1.3, it is possible to provide new encrypted connection IDs, though of course those IDs are immediately used on the wire.  Without multi- homing and mobility the use of the connection id is not different to the use of the 5-tuple. </del>  With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further privacy concerns.  In order to prevent this, implementations SHOULD attempt to use fresh connection IDs whenever they change local addresses or ports (though this is not always possible to detect). <del> In DTLS 1.3, The RequestConnectionId message can be used to ask for new IDs in order to ensure that you have a pool of suitable IDs. This document does not change the security properties of DTLS 1.2 RFC6347 and DTLS 1.3 I-D.ietf-tls-dtls13.  It merely provides a more robust mechanism for associating an incoming packet with a stored security context. </del>  [[OPEN ISSUE: Sequence numbers leak connection IDs.  We need to update the document to address this.  One possibility would be the "ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD) defined in this document. <del> IANA is requested to allocate two values in the "TLS Handshake Type" registry, defined in RFC5246, for request_connection_id (TBD), and new_connection_id (TBD), as defined in this document. </del>

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.

Abstract  <ins> This document specifies the Connection ID construct for the Datagram Transport Layer Security (DTLS) protocol.  I-D.ietf-tls-dtls13 specifies the Connection ID for DTLS version 1.3. </ins> A Connection ID is an identifier carried in the record layer header that gives the recipient additional information for selecting the updated once the key lifetime expires. In the current version of DTLS, the IP address and port of the peer  <ins> are used to identify the DTLS association.  Unfortunately, in some </ins> cases, such as NAT rebinding, these values are insufficient.  This is  <ins> a particular issue in the Internet of Things when devices enter extended sleep periods to increase their battery lifetime.  The NAT rebinding leads to connection failure, with the resulting cost of a new handshake. </ins> This document defines an extension to DTLS to add a connection ID to  <ins> the DTLS record layer.  The presence of the connection ID is negotiated via a DTLS extension. </ins> 2. "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119.  <ins> The reader is assumed to be familiar with DTLS RFC6347. </ins> 3. The extension type is specified as follows. The extension_data field of this extension, when included in the  <ins> ClientHello, MUST contain the CID structure, which carries the CID </ins> which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client is prepared to send with a connection ID but does not wish the server to same). A server which is willing to use CIDs will respond with its own  <ins> "connection_id" extension, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value indicates that the server will send with the client's CID but does not wish the client to use a CID (or again, alternately, to use a zero-length CID). </ins> When a session is resumed, the "connection_id" extension is negotiated afresh, not retained from previous connections in the Previous design ideas for using cryptographically generated session ids, either using hash chains or public key encryption, were dismissed due to their inefficient designs.  Note that a client  <ins> always has the chance to fall back to a full handshake or more precisely to a handshake that uses session resumption. </ins> Because each party sends in the extension_data the value that it will receive as a connection identifier in encrypted records, it is time constant.  Note that such implementations must still be able to send other length connection identifiers to other parties.  <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.  <ins> This extension is applicable for use with DTLS and dtls-record12 illustrates the record format. </ins>  <ins> Note that for both record formats, it is not possible to parse the records without knowing how long the Connection ID is. </ins>  <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.  <ins> The CID value, when present, is included in the MAC calculation for the DTLS record.  It is created as follows: </ins> 6.  <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. contain arbitrary values; implementations concerned about this SHOULD refuse to use connection ids.  <ins> An on-path adversary, who is able to observe the DTLS protocol </ins> exchanges between the DTLS client and the DTLS server, is able to link the observed payloads to all subsequent payloads carrying the  <ins> same connection id pair (for bi-directional communication).  Without multi-homing or mobility, the use of the connection id is not different to the use of the 5-tuple. </ins> With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further privacy concerns.  In order to prevent this, implementations SHOULD attempt to use fresh connection IDs whenever they change local addresses or ports (though this is not always possible to detect).  <ins> This document does not change the security properties of DTLS RFC6347.  It merely provides a more robust mechanism for associating an incoming packet with a stored security context. </ins> [[OPEN ISSUE: Sequence numbers leak connection IDs.  We need to update the document to address this.  One possibility would be the "ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD) defined in this document.  <ins> IANA is requested to allocate the following new values in the "TLS ContentType Registry": alert_with_cid(25) handshake_with_cid(26) application_data_with_cid(27) heartbeat_with_cid(28) </ins>


"ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD) defined in this document. <del> IANA is requested to allocate the following new values in the "TLS ContentType Registry": alert_with_cid(25) handshake_with_cid(26) application_data_with_cid(27) heartbeat_with_cid(28) </del>

URL Still contains the content types removed in PR . alertwithcid(25) handshakewithcid(26) applicationdatawithcid(27) heartbeatwithcid(28) I guess, it should be updated towards PR ? tls12cid(25)
The PR can be found here: URL
The PR will fix it.

"ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD) defined in this document.  <ins> IANA is requested to allocate tls12_cid(25) in the "TLS ContentType Registry". </ins>


such implementations must still be able to send connection identifiers of different length to other parties.  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, 4. <del> This extension is applicable for use with DTLS 1.2 and below. dtls- record12 illustrates the record format.  I-D.ietf-tls-dtls13 specifies how to carry the CID in a DTLS 1.3 record. Note that for both record formats, it is not possible to parse the records without knowing how long the Connection ID is. </del>  In order to allow a receiver to determine whether a record has CID or not, connections which have negotiated this extension use a The true content type is inside the encryption envelope, as described below. <del> 5. </del>  <del> When CID is being used, the DTLSCompressed value is first wrapped along with the true content type and padding into a DTLSWrappedCompressed value prior to encryption.  The DTLSWrappedCompressed value is then encrypted. </del>  <del> The value of DTLSCompressed.fragment </del>  <del> The true content type. </del>  <del> Padding, as defined in RFC8446. </del>  In addition, the CID value is included in the MAC calculation for the DTLS record, as shown below.  The MAC algorithm described in The "cid_length" field is a single octet containing the length of the connection ID. <del> 6. </del>  dtls-example2 shows an example exchange where a connection id is used uni-directionally from the client to the server.  To indicate that a contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. <del> 7. </del>  The connection id replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime RFC6347.  It merely provides a more robust mechanism for associating an incoming packet with a stored security context. <del> 8. </del>  IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for

Trying to address URL but also trying to expand the description a bit for clarity.
According URL all records seems to use a . Does this include the ?
Does this PR provide an improvement help? URL
Yes, it clarifies it for me.

such implementations must still be able to send connection identifiers of different length to other parties. <ins> Note that it is not possible to parse the records without knowing how long the Connection ID is. </ins> 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, 4.  <ins> 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. </ins> In order to allow a receiver to determine whether a record has CID or not, connections which have negotiated this extension use a The true content type is inside the encryption envelope, as described below.  <ins> When CID is being used, the content to be sent is first wrapped along with the true content type and padding into a DTLSInnerPlaintext value prior to encryption.  The DTLSInnerPlaintext value is then encrypted. dtls-record12 illustrates the record format. This field contains the byte encoding of a handshake, an alert message, or the raw bytes of the application's data to send. The DTLSInnerPlaintext.type value contains the content type of the record.  This is the non-obfuscated (true) content type. 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 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.) </ins>  <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 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. </ins>  <ins> The DTLSCiphertext.version field describes the protocol being employed.  This document describes an extension to DTLS version 1.2. </ins>  <ins> 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. </ins>  <ins> 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. </ins> In addition, the CID value is included in the MAC calculation for the DTLS record, as shown below.  The MAC algorithm described in The "cid_length" field is a single octet containing the length of the connection ID.  <ins> 5. </ins> dtls-example2 shows an example exchange where a connection id is used uni-directionally from the client to the server.  To indicate that a contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well.  <ins> 6. </ins> The connection id replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime RFC6347.  It merely provides a more robust mechanism for associating an incoming packet with a stored security context.  <ins> 7. </ins> IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for


Abstract <del> This document specifies the Connection ID construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. </del>  <del> A Connection ID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association.  In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple.  If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. </del>  1. rebinding leads to connection failure, with the resulting cost of a new handshake. <del> This document defines an extension to DTLS to add a connection ID (CID) to the DTLS record layer.  The presence of the connection ID is negotiated via a DTLS extension. </del>  2. 3. <del> This document defines a new extension type (connection_id(TBD)), which is used in ClientHello and ServerHello messages. </del>  The extension type is specified as follows. ClientHello, MUST contain the ConnectionId structure, which carries the CID which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client <del> 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). A server which is willing to use CIDs will respond with its own "connection_id" extension, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value indicates that the server will send with the client's CID but does not wish the client to use 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 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 <del> parsing and connection lookup, 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 length can be determined on reception.  Note that such implementations must still be able to send connection identifiers of different length to other parties. </del>  Note that it is not possible to parse the records without knowing how <del> long the Connection ID is. </del>  <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 TLS 1.3-style post- handshake messages that do not themselves begin other handshakes. </del>  DTLS peers switch to the new record layer format, i.e., the record layer format containing the CID, when encryption is enabled. The true content type is inside the encryption envelope, as described below. <del> When CID is being used, the content to be sent is first wrapped along with the true content type and padding into a DTLSInnerPlaintext value prior to encryption.  The DTLSInnerPlaintext value is then encrypted. dtls-record12 illustrates the record format. </del>  This field contains the byte encoding of a handshake, an alert message, or the raw bytes of the application's data to send. the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. <del> The cid value of length indicated with cid_length, as agreed </del>  during the exchange. The AEAD-encrypted form of the serialized DTLSInnerPlaintext This value contains the length information in the outer-header. <del> Value of the negotiated cid.  This field is empty in case a zero- length cid has been negotiated. </del>  <del> 1 byte field indicating the length of the negotiated cid.  If a zero-length cid has been negotiated, and therefore no cid appears </del>  on the wire, a cid_length of zero (0) MUST be added. 5. <del> dtls-example2 shows an example exchange where a connection id is used uni-directionally from the client to the server.  To indicate that a connection_id has zero length we use the term 'connection_id=empty'. </del>  Note: In the example exchange the CID is included in the record layer once encryption is enabled.  In DTLS 1.2 only one handshake message 6. <del> The connection id replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime of a DTLS connection.  Every identifier introduces the risk of linkability, as explained in RFC6973. </del>  <del> In addition, endpoints can use the connection ID to attach arbitrary metadata to each record they receive.  This may be used as a mechanism to communicate per-connection information to on-path observers.  There is no straightforward way to address this with connection IDs that contain arbitrary values; implementations concerned about this SHOULD refuse to use connection ids. </del>  An on-path adversary, who is able to observe the DTLS protocol exchanges between the DTLS client and the DTLS server, is able to link the observed payloads to all subsequent payloads carrying the same connection id pair (for bi-directional communication).  Without <del> multi-homing or mobility, the use of the connection id is not different to the use of the 5-tuple. </del>  With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further

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
I don't think that you need to change the grammar.

Abstract  <ins> This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. </ins>  <ins> A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association.  In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple.  If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. </ins> 1. rebinding leads to connection failure, with the resulting cost of a new handshake.  <ins> This document defines an extension to DTLS 1.2 to add a CID to the DTLS record layer.  The presence of the CID is negotiated via a DTLS extension. </ins> 2. 3.  <ins> This document defines the "connection_id" extension, which is used in ClientHello and ServerHello messages. </ins> The extension type is specified as follows. ClientHello, MUST contain the ConnectionId structure, which carries the CID which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client  <ins> is prepared to send with a CID 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). A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID (or again, alternately, to use a zero-length CID). </ins> When a session is resumed, the "connection_id" extension is negotiated afresh, not retained from previous connections in the 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  <ins> parsing and connection lookup, 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 length can be determined on reception.  Note that such implementations must still be able to send connection identifiers of different length to other parties. </ins> Note that it is not possible to parse the records without knowing how  <ins> long the CID is. </ins>  <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 themselves begin other handshakes. </ins> DTLS peers switch to the new record layer format, i.e., the record layer format containing the CID, when encryption is enabled. The true content type is inside the encryption envelope, as described below.  <ins> When CIDs are being used, the content to be sent is first wrapped along with the true content type and padding into a DTLSInnerPlaintext value prior to encryption.  The DTLSInnerPlaintext value is then encrypted. dtls-record12 illustrates the record format. </ins> This field contains the byte encoding of a handshake, an alert message, or the raw bytes of the application's data to send. the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm.  <ins> The CID value of length indicated with cid_length, as agreed </ins> during the exchange. The AEAD-encrypted form of the serialized DTLSInnerPlaintext This value contains the length information in the outer-header.  <ins> Value of the negotiated CID.  This field is empty in case a zero- length CID has been negotiated. </ins>  <ins> 1 byte field indicating the length of the negotiated CID.  If a zero-length CID has been negotiated, and therefore no CID appears </ins> on the wire, a cid_length of zero (0) MUST be added. 5.  <ins> dtls-example2 shows an example exchange where a CID is used uni- directionally from the client to the server.  To indicate that a zero-length CID we use the term 'connection_id=empty'. </ins> Note: In the example exchange the CID is included in the record layer once encryption is enabled.  In DTLS 1.2 only one handshake message 6.  <ins> The CID replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime of a DTLS connection.  Every identifier introduces the risk of linkability, as explained in RFC6973. </ins>  <ins> In addition, endpoints can use the CID to attach arbitrary metadata to each record they receive.  This may be used as a mechanism to communicate per-connection information to on-path observers.  There is no straightforward way to address this with CIDs that contain arbitrary values; implementations concerned about this SHOULD refuse to use connection ids. </ins> An on-path adversary, who is able to observe the DTLS protocol exchanges between the DTLS client and the DTLS server, is able to link the observed payloads to all subsequent payloads carrying the same connection id pair (for bi-directional communication).  Without  <ins> multi-homing or mobility, the use of the CID is not different to the use of the 5-tuple. </ins> With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further


"OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. <del> The reader is assumed to be familiar with DTLS RFC6347. </del>  3. The extension type is specified as follows. The extension_data field of this extension, when included in the <del> ClientHello, MUST contain the ConnectionId structure, which carries the CID which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client is prepared to send with a CID 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). </del>  A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client 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>  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>  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>  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>  <del> The CID field is present </del>  The true content type is inside the encryption envelope, as described below. 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>  The outer opaque_type field of a DTLSCiphertext record is always set to the value 25 (tls12_cid).  The actual content type of the Other fields are defined in RFC 6347.  Note that this specification does not make use of the DTLSCompressed structure. <del> In addition, the CID value is included in the MAC calculation for the DTLS record layer.  At the time of writing ciphers using </del>  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 This value contains the length information in the outer-header. <del> Value of the negotiated CID.  This field is empty in case a zero- length CID has been negotiated. </del>  <del> 1 byte field indicating the length of the negotiated CID.  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. </del>  <del> 5. </del>  dtls-example2 shows an example exchange where a CID is used uni- directionally from the client to the server.  To indicate that a contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. <del> 6. </del>  The CID replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime of a DTLS client/server pair do a rehandshake to change CID, that does not provide much privacy benefit. <del> This document does not change the security properties of DTLS RFC6347.  It merely provides a more robust mechanism for associating an incoming packet with a stored security context. </del>  <del> 7. </del>  IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for

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

"OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119.  <ins> This document assumes familiarity with DTLS 1.2 RFC6347. </ins> 3. The extension type is specified as follows. The extension_data field of this extension, when included in the  <ins> ClientHello, MUST contain the ConnectionId structure.  This structure contains the CID value the client wishes the server to use when sending messages to the client.  A zero-length CID value indicates that the client is prepared to send with a CID but does not wish the server to use one when sending.  Alternatively, this can be interpreted as the client wishes the server to use a zero-length CID; the result is the same. </ins> A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client not wish the client to include a CID (or again, alternately, to use a zero-length CID).  Because each party sends the value in the "connection_id" extension  <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  <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  <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.  <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>  <ins> The MAC calculation follows the process described in mac. </ins> The true content type is inside the encryption envelope, as described below. 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  <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 Other fields are defined in RFC 6347.  Note that this specification does not make use of the DTLSCompressed structure.  <ins> 5. This specification changes the MAC calculation defined in Section 4.1.2 of RFC 6347.  At the time of writing ciphers using </ins> 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 This value contains the length information in the outer-header.  <ins> Value of the negotiated CID. </ins>  <ins> 1 byte field indicating the length of the negotiated CID. </ins>  <ins> 6. </ins> dtls-example2 shows an example exchange where a CID is used uni- directionally from the client to the server.  To indicate that a contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well.  <ins> 7. </ins> The CID replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime of a DTLS client/server pair do a rehandshake to change CID, that does not provide much privacy benefit.  <ins> The CID-enhanced record layer introduces record padding; a privacy feature not available with the original DTLS 1.2 RFC.  Padding allows to inflate the size of the ciphertext making traffic analysis more difficult.  More details about the padding can be found in Section 5.4 and Appendix E.3 of RFC 8446. </ins>  <ins> 8. </ins> IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for