jiebi/CodeConvo huggingface dataset:
Code change:
6. dtls-example2 shows an example exchange where a connection id is used <del> uni-directionally from the client to the server. </del> <ins> uni-directionally from the client to the server.  To indicate that a connection_id has zero length we use the term 'connection_id=empty'. 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 is encrypted, namely the Finished message.  Since the example shows how to use the CID for payloads sent from the client to the server only the record layer payload containing the Finished messagen contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. </ins> 7.

Related discussion:
text: With outer type and inner types nothing additional to the already defined additions is introduces, except that it is used already within the handshake. If you want, I update my wip URL and document, how to use a CID in the handshake. Then you see in wireshark, how it works.
With outer type tls12cid(25) and inner types changecipher_spec(20), alert(21), handshake(22) nothing additional to the already defined additions is introduced Yep That's the trouble. Most "enterprise security" middleboxes want to be able to look into the handshake to determine whether a connection is ok according to their policies. After the handshake completes and the connection is considered alright, they just act as blind packet forwarders. To do the handshake inspection they depend on the established wire image of the TLS/DTLS protocol. If we introduce the ability to change the wire format during handshake (as opposed to the post-handshake phase only) we might end up impairing clients that sit behind those boxes.
Goal: Deny successful handshake of a selected peer. Position: off-path, but know the peer's address and the interesting time period. Something missing?
Smells for me, that a "list of typed cid" (see ) may be used, to enable a peer behind such a box to inform the other, not to use the CID during the handshake. types: "plain" - cid only after handshake "plain+" - cid also during handshake
Just for my personal interest: can you name a middlebox, which supports DTLS?
Sorry, now you triggered me: Why should those middleboxes forward my tlscid record, when my address has changed, but block my tlscid record, when it contains a handshake? If the middleboxes are unaware of this draft, but forward my tlscid record even with changed address, I would assume, they forward my tlscid record also with a inner handshake message.
Deny successful handshake of a selected peer. Position: off-path, but know the peer's address and the interesting time period. OK, thanks very much. Frankly, the combination of perfect timing as well as the randomization provided by the source port makes the attack window pretty narrow.
Code change:
6. dtls-example2 shows an example exchange where a connection id is used <del> uni-directionally from the client to the server. </del> <ins> uni-directionally from the client to the server.  To indicate that a connection_id has zero length we use the term 'connection_id=empty'. 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 is encrypted, namely the Finished message.  Since the example shows how to use the CID for payloads sent from the client to the server only the record layer payload containing the Finished messagen contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. </ins> 7.

Related discussion:
text: On the other hand, allocating state too early (i.e., allocating CIDs without strong commitment from client side) opens up an interesting amount of attack surface on server side.
This is a tricky question. Boxes like typically have scripting capabilities which give their admins lots of leeway. I do not build nor operate any of these so my direct experience is ~0, but speaking with the Symantec guys exactly about how to modify the DTLS wire image to signal the presence of CID in a middlebox-tolerant way, their feedback was "to be sure, just leave the handshake alone as much as possible"... I have no reason to doubt their assessment, also given the ways TLS 1.3 was hit in this same space.
Above I wrote nothing else. ??? what's that ??? Why should the use of cid in the inner handshake messages as well allocate anything additionally? The cid is provided in the CLIENTHELLO and/or SERVERHELLO, it's currently just not send in the inner handshake messages. But there is not more or less to allocate, if they are used with other handshake message or not.
I have also no reason to doubt them, but I'm very unsure, if an address change will then work at all with such boxes. I would really prefer to test such an address change. I couldn't find any hint, that that box supports DTLS at all.
So the critical issue seems: with TLS there are bad experience changing the records with DTLS this experience seems to be missing. Some expect them to be similar bad. I unfortunately suspect them to be either a real disaster (address change not working at all), or not that hard. Without boxes to test and/or people with DTLS-boxes experience, it will be hard to find a solution. So, try to use the mailing list to get more feedback?
Sorry, I fail to understand your argument. What to do with an unknown 5-tuple vs what to do with an unknown C-T in a context where you expect to understand the semantics of the flow seem orthogonal to me.
I don't really understand the above sentence so I know a reply is quite risky :-) Anyway, what I wanted to say is that if you want to use CID during handshake in any meaningful way, it means the party requiring it (e.g., server) needs to allocate state internally to be able to check it on receive.
Code change:
6. dtls-example2 shows an example exchange where a connection id is used <del> uni-directionally from the client to the server. </del> <ins> uni-directionally from the client to the server.  To indicate that a connection_id has zero length we use the term 'connection_id=empty'. 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 is encrypted, namely the Finished message.  Since the example shows how to use the CID for payloads sent from the client to the server only the record layer payload containing the Finished messagen contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. </ins> 7.

Related discussion:
text: If this allocation is triggered only by one (or two) CH(s), it's pretty easy to mount a "CID exhaustion" attack against the server. Requiring the client to complete the handshake before promoting a "2-tuple" connection into a "CID" connection makes the attack much more demanding and therefore a lot less likely.
(some overlap in the discussion :-) so a updated my comment with the question above.) Try to explain it: Which rules should a box apply to a tls_cid record? It's only valid after a successful handshake? But, how should such a record then be assigned to that successful handshake? Either by knowing the CID (which requires to be aware of this draft), or much weaker by the address, but then it will not work with address changes.
OK, so you don't allocate something on the server side for the CID in the CLIENTHELLO until the handshake is finished? Or you send a CID in the SERVERHELLO without allocating it before the handshake is finished? May be I'm too focused on my implementation, but without an other implementation, which shows what you wrote, it's also hard for me to understand your comments.
At least, I think you target the CID the server side is using. How is it ensured, that the CID in the SERVER_HELLO is unique at least for all established connections and all ongoing handshakes, which are not terminated at that time point?
In my message above s/CID exhaustion/resource exhaustion/ sorry... And yes, you can certainly separate the act of reserving the CID when you decide to send it in the CH from creating state associated with the CID-based session lookup paraphernalia. For example you could use a big enough CID space (say 8 bytes) and reserve your CIDs by means of a monotonically increasing function. And at a later time (my proposal is after the handshake is completed successfully) you grab the memory needed for the CID based session lookup stuff...
Another point is that we'd put more bytes on the wire, increasing the risk of message fragmentation with small MTUs in a situation, the handshake, where the timing of the messaging is such that NAT timeouts are very unlikely and therefore the 5-tuple based demuxing more than adequate.
I can't see a relation of "resource exhaustion" with the usage of the CID in the handshake.
That's right.
Code change:
6. dtls-example2 shows an example exchange where a connection id is used <del> uni-directionally from the client to the server. </del> <ins> uni-directionally from the client to the server.  To indicate that a connection_id has zero length we use the term 'connection_id=empty'. 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 is encrypted, namely the Finished message.  Since the example shows how to use the CID for payloads sent from the client to the server only the record layer payload containing the Finished messagen contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. </ins> 7.

Related discussion:
text: In my experience, "small MTUs" are rarely used. The highest risk is caused by a larger CLIENTHELLO, which then gets fragmented (see "resource exhaustion"). Though CID makes the CLIENTHELLO larger, it's more an argument, that CID may not be support on such path. FMPOV, a "optimal support" for peers with a very narrow link, should be moved into a other discussion.
The part with having the choice to either "protect the handshake" or "support address changes" should just leave it to the implementation, which strategy is chosen. I would go for a configurable solution, which enables a "dynamic protection", if too many handshakes are ongoing.
I had a chat with Achim and he agreed that we can leave the feature of using CIDs for handshake messages for DTLS 1.3. This will allow us to get this work done faster. DTLS 1.3 encrypts handshake messages earlier and hence already the handshake itself utilize CIDs.
NAME Thanks for your time!
Hi Hannes, Achim, Good, thanks both for taking the time to sort this out. I think it's a very reasonable choice to not introduce scope inflation at this (late) stage. One thing we still need to do though is tighten up a bit the language around when exactly the CID is put on the wire. Something like: "Once a non-empty CID is successfully negotiated, it MUST be sent on the XYZ message and on all subsequent records of the connection" would remove all the uncertainty I guess. I personally have an inclination for XYZ to be the first application data, mainly because I'd like to commit any resources only after I have full confirmation that the client is a good one. However, I don't care whatever choice we end up with, as long as it's written down precisely in 2119 language.
I'm not sure, what "commit" includes or means exactly. To verify the FINISH you will need the "keying material from the crypto context (derived from the specific mastersecret)". According URL a good estimation will be about 128 bytes. In your wording, you use them before you "commit" them? So adding a couple of bytes for CID to that storage, should not make a difference, or?
Code change:
6. dtls-example2 shows an example exchange where a connection id is used <del> uni-directionally from the client to the server. </del> <ins> uni-directionally from the client to the server.  To indicate that a connection_id has zero length we use the term 'connection_id=empty'. 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 is encrypted, namely the Finished message.  Since the example shows how to use the CID for payloads sent from the client to the server only the record layer payload containing the Finished messagen contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. </ins> 7.

Related discussion:
text: I mean making a certain CID "used" (not just reserved) and making room for the CID in a lookup table. But, as I said, I won't be unhappy if the "first CID record" happens to be something different than the application data.
From my side the specification is also free to chose, when the peer should start to use the tls_cid records.
NAME I'm still not sure, if I really understand the requirements of your approach. My current feeling is, that you store all the keying and cid stuff in a "context" and provide a address:port-lookup-table for that stored context. One finish, you then want to store this context into a cid-lookup-table. If that's the plan, a cid usage even in the handshake doesn't matter. For epoch 0 records, just still use the address:port lookup and verify the record cid with the stored one. I personally prefer a "relaxed definition", but your case will not be wrong. It just doesn't support address changes during handshake. I guess, after a period of experience, the most user will select that option and use it to secure the handshake without supporting an address change. But that would be left to future experience. After the call with NAME I think it's better not to extend this draft with that idea and instead focus on DTLS 1.3. Therefore I removed the code for this extended usage from my wip and closed this issue. In the meantime, it's really hard to collect all statements over several issues. So, if you still interested in using the RFC6347 record for the finish and start with the tls12_cid records after that, I think, open a new issues (or PR) would make it easier to fetch up this idea.
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.
Code change:
6. dtls-example2 shows an example exchange where a connection id is used <del> uni-directionally from the client to the server. </del> <ins> uni-directionally from the client to the server.  To indicate that a connection_id has zero length we use the term 'connection_id=empty'. 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 is encrypted, namely the Finished message.  Since the example shows how to use the CID for payloads sent from the client to the server only the record layer payload containing the Finished messagen contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. </ins> 7.

Related discussion:
text: 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
In Figure 2, parentheses are used to signify both extensions (connection_id=100) and the addition to the record header (cid=100). I suggest using a different notation here.
NAME can you take a crack at fixing this
Here is an update: URL
Updated diagram merged into the draft.
Code change:
those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <ins> When using DTLS 1.3, peers SHOULD avoid using the same CID on multiple network paths, in particular when initiating connection migration or when probing a new network path, as described in path- validation, as an adversary can otherwise correlate the communication interaction across those different paths.  DTLS 1.3 provides mechanisms to ensure that a new CID can always be used.  In general, an endpoint should proactively send a RequestConnectionId message to ask for new CIDs as soon as the pool of spare CIDs is depleted (or goes below a threshold).  Also, in case a peer might have exhausted available CIDs, a migrating endpoint could include NewConnectionId in packets sent on the new path to make sure that the subsequent path validation can use fresh CIDs. Note that DTLS 1.2 does not offer the ability to request new CIDs during the session lifetime since CIDs have the same life-span of the connection.  Therefore, deployments that use DTLS in multihoming environments SHOULD refuse to use CIDs with DTLS 1.2 and switch to DTLS 1.3 if the correlation privacy threat is a concern. </ins> 10. [[to-be-removed: RFC Editor: please replace RFCthis with this RFC

Related discussion:
text: Signed-off-by: Thomas Fossati
CC NAME
We don't currently discuss any privacy implication associated with CID reuse. We should at least: document how to ensure a new CID is used during path validation in 1.3 flag that 1.2 has no way to work around linkability because CID have the same lifetime as the session
Code change:
The 50 is based on 50 packets per second, the 40 is based on an estimate of total header size, the 1000 changes the unit from kbps to bps (as required by TIAS), and the 0.95 is to allocate <del> 5% to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". </del> <ins> 5% to RTCP.  "TIAS" is used in preference to "AS" because it provides more accurate control of bandwidth. </ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.

Related discussion:
text: NAME don't love the way the bit about the pool turned out but I don't have better text. Fixed. Consensus here was this is fine. No, this seems fairly clear. URL Done. Done. Do you mean RTP here? If so, I'm feeling OK about this. Done.
Merging and will tweak post-merge
Code change:
entities that are authorized to send messages on the channel.  The push service does not require access to this public key. <ins> The Topic header field exposes information that allows more granular correlation of push messages on the same subject.  This might be used to aid traffic analysis of push messages by the push service. </ins> 9.2. Push message confidentiality does not ensure that the identity of who

Related discussion:
text: I've specified a Topic header field that we can use as a "collapse key".
Regarding max topics, I don't plan on limiting the max topics. I'm using a sharded db with a compound hash+range key for indexing, and plan on storing the topic in the range key for direct access to delete it for later messages with a topic field. There is the side-effect that the UA will get messages out-of-order as a result. ie. all messages with no topic will be delivered in order, then messages with a topic will be delivered in the order of their topic names.
We currently impose a limit of four topics (née collapse keys) +NAME I do like the change. GCM has a separate feature called Topics, i.e. subscriptions to a category, which may cause some confusion. Thinking about the name without taking this into account, I still think it makes sense in this context. URL
NAME yup, the common use case of sending "You have N messages in your mailbox", makes sense to just tell a developer to add the topic "Inbox", and the user will always get the last one sent in. I am curious about how systems having topic limits plan on communicating this to the app-server. Is there some minimum the spec should mandate just so that an app developer isn't surprised later when their app needing 5 topics doesn't work right on a browser that has topic limits?
Would 429 work for systems that run out of topics (or collapse keys)? That seems right to me.
429 seems to specific to be used for this scenario: The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting"). Could be a 500?
Is there a length limitation on the Topic? This could also be implementation-specific and signaled by: 431 Request Header Fields Too Large (RFC6585)
I think that NAME and I concluded that we could accept any size of topic. Up to the limits on header field sizes, that is, which would trigger 431. Maybe, but it is the best match I have. And I think that 4xx is better than 5xx.
If you continue with 429, how does an application server discern between 429 Rate Limiting and 429 Too Many Topics? By the presence of Retry-After?
Retry-After might be present in all cases.