jiebi/CodeConvo huggingface dataset:
Code change:
Data Unit: Datagram The Transport Services API mappings for UDP-Lite are identical to <del> UDP.  Properties that require checksum coverage are not supported by UDP-Lite, such as "msgChecksumLen", "fullChecksumSend", "recvChecksumLen", and "fullChecksumRecv". </del> <ins> UDP.  In addition, UDP-Lite supports the "msgChecksumLen" and "recvChecksumLen" Properties that allow an application to specify the minimum number of bytes in a message that need to be covered by a checksum. </ins> 10.5.

Related discussion:
text: Initially I thought the description for UDP-Lite was incomplete, but mapping back to the details of the API draft I realized it was incorrect. UDP-Lite supports the msgChecksumLen and recvChecksumLen properties. The API for theses primitives is a bit messy. As specified I think it means the following: UDP can use them to set full coverage or no checksum using the special value of 0. UDP-Lite can use them to set full coverage or a partial coverage. Setting the checksum to only cover the header, although supported by UDP-Lite, will not be possible as 0 is a special value. The special value of 0 can not be used by UDP-Lite, but I left this detail out of the pull request as I thought it got very detailed. It can be added if you think it is needed.
Code change:
the current window; "RateLimit-Reset": containing the time remaining in the current <del> window, specified in seconds. </del> <ins> window, specified in seconds; "RateLimit-Policy": containing the quota policy information. </ins> The behavior of "RateLimit-Reset" is compatible with the "delay- seconds" notation of "Retry-After".

Related discussion:
text: moves quota-policies from RateLimit-Limit -> RateLimit-Policyrequires WG discussion -
Given this hint from Mark URL I think it's fine to merge this PR (separate Policy from Limit) since there seems to be agreement to use different fields at least in this case.
Perhaps best to continue discussion in that issue before merging this? While the change will happen in a similar vein, we might want to wait to flesh out further details.
This seems quite arbitrary for a MUST; what is "too far in the future" and "too high"?
Agree, this is an tricky point. I think an implementation: MUST define internal threeshold of allowed values; MUST validate ratelimit fields according to those thresholds. I think we could borrow some text from Signature. See
OK, but RFC2119 language is for interoperability, and this doesn't provide any; different implementations (or deployments) are going to have different values, and that may cause issues. It'd be better to defines precise limits if you think this is important enough to merit a MUST. Personally, I'd remove the 2119 language and just give guidelines about what implementations should consider when they're looking for abuse.
Ok, great!
Addressed in
The draft today suggests putting quota policies, a list, into the header. But that's a sort of breaking change, because that header's equivalent is strictly a number (not a list) in most existing implementations. Could be kept as a plain number (like and ), and instead a new header like or some such can contain supplementary information? That way, the story for upgrading to this draft is simpler. Sorry if this is asked and answered.
iirc we considered this but we initially had some requests of conflating as much as possible in fewer fields. Probably it's a more interoperable choice. I am open in re-considering the idea, provided we get in touch with the current implementers including 3scale, kong and envoy cc: 3scale: NAME , kong: NAME , envoyproxy: NAME
There's no inherent problem in using a specific header for policies, and no issue in moving to use them from the 3scale side. The only downside is we're adding yet another header for rate limiting, currently 4 of them, which might raise a few eyebrows.
Code change:
the current window; "RateLimit-Reset": containing the time remaining in the current <del> window, specified in seconds. </del> <ins> window, specified in seconds; "RateLimit-Policy": containing the quota policy information. </ins> The behavior of "RateLimit-Reset" is compatible with the "delay- seconds" notation of "Retry-After".

Related discussion:
text: NAME thanks :) do you think that splitting is a more interoperable choice wrt to the parsing implementation / usability? Do you see other practical drawbacks? if we don't get feedback on this issue, can you ping the other implementers you know?
Yes, it's easier for people to pick up a new header for this to apply a policy, since as it stands they might break when seeing extra stuff in the limit one by expecting a single value rather than multiple, as NAME mentions above. No, just dealing with people (maybe) opposing too-many-headers - I don't know if this is something that we can predictably foresee happening in the HTTPAPI WG or in the HTTP WG, but my intuition says "likely" given how we were asked to "condense" this information, so I think we might want to spend some time making a good case out of it. NAME other than potential breakages in pre-existing implementations, is there any additional point we could make to justify the additional header? I think they are all currently listed - that being said I think porting to a new header should be an easy task, so hopefully not a problem.
if almost everyone is implementing just the minimal specification, probably this could even simplify the addition of ...
The primary motivation is breakage, as you suggest, NAME The secondary motivation is ease of "upgrading" to adoption of quota policies, as NAME suggests. The flipside of "easy to adopt, easy to upgrade" is that the spec would also make it easy to never upgrade at all. This is a good thing, supposing that most services can operate perfectly fine without quota policies. A third, much weaker argument, is that the current approach of putting the "limit" and "quota policy" in the same header is that it's confusing. I would need more time to really state this argument more clearly, but what rubs me the wrong way here is that the current design basically puts two different kinds of data in the same list. As it stands, is a list of a numbers, but the first number (the "limit") is not like the rest of the numbers (the policy). The first number cannot have SFV parameters, but the others can (and typically will). It's an accident of SFV's syntax that this is even conceivable as an approach.
Code change:
the current window; "RateLimit-Reset": containing the time remaining in the current <del> window, specified in seconds. </del> <ins> window, specified in seconds; "RateLimit-Policy": containing the quota policy information. </ins> The behavior of "RateLimit-Reset" is compatible with the "delay- seconds" notation of "Retry-After".

Related discussion:
text: For implementors, this means that does not simply deserialize as some sort of . It deserializes into a list, where the first element is an and the tail is a . I fear this will at minimum confuse folks, and perhaps even lead to incorrect implementations, such as people not realizing the first element of the list is not a quota policy at all.
Given URL it seems there's some consensus in providing quota policy in a separate field.
Code change:
by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. <del> In the special case of a maximum resolution of [0, 0], as described above, the sender MUST NOT transmit the encoding. </del> 3.7. JSEP supports simulcast transmission of a MediaStreamTrack, where

Related discussion:
text: This seems like a normative change. I'm not saying I'm against this, but what's the rationale?
Adam's argument in , which I found to be convincing.
Code change:
fields only when a given quota is going to expire. Implementers concerned with response fields' size, might take into <del> account their ratio with respect to the payload data, or use header- compression http features such as HPACK. </del> <ins> account their ratio with respect to the content length, or use header-compression HTTP features such as HPACK. </ins> 4.

Related discussion:
text: moves quota-policies from RateLimit-Limit -> RateLimit-Policyrequires WG discussion -
Given this hint from Mark URL I think it's fine to merge this PR (separate Policy from Limit) since there seems to be agreement to use different fields at least in this case.
Perhaps best to continue discussion in that issue before merging this? While the change will happen in a similar vein, we might want to wait to flesh out further details.
This seems quite arbitrary for a MUST; what is "too far in the future" and "too high"?
Agree, this is an tricky point. I think an implementation: MUST define internal threeshold of allowed values; MUST validate ratelimit fields according to those thresholds. I think we could borrow some text from Signature. See
OK, but RFC2119 language is for interoperability, and this doesn't provide any; different implementations (or deployments) are going to have different values, and that may cause issues. It'd be better to defines precise limits if you think this is important enough to merit a MUST. Personally, I'd remove the 2119 language and just give guidelines about what implementations should consider when they're looking for abuse.
Ok, great!
Addressed in
The draft today suggests putting quota policies, a list, into the header. But that's a sort of breaking change, because that header's equivalent is strictly a number (not a list) in most existing implementations. Could be kept as a plain number (like and ), and instead a new header like or some such can contain supplementary information? That way, the story for upgrading to this draft is simpler. Sorry if this is asked and answered.
iirc we considered this but we initially had some requests of conflating as much as possible in fewer fields. Probably it's a more interoperable choice. I am open in re-considering the idea, provided we get in touch with the current implementers including 3scale, kong and envoy cc: 3scale: NAME , kong: NAME , envoyproxy: NAME
There's no inherent problem in using a specific header for policies, and no issue in moving to use them from the 3scale side. The only downside is we're adding yet another header for rate limiting, currently 4 of them, which might raise a few eyebrows.
Code change:
fields only when a given quota is going to expire. Implementers concerned with response fields' size, might take into <del> account their ratio with respect to the payload data, or use header- compression http features such as HPACK. </del> <ins> account their ratio with respect to the content length, or use header-compression HTTP features such as HPACK. </ins> 4.

Related discussion:
text: NAME thanks :) do you think that splitting is a more interoperable choice wrt to the parsing implementation / usability? Do you see other practical drawbacks? if we don't get feedback on this issue, can you ping the other implementers you know?
Yes, it's easier for people to pick up a new header for this to apply a policy, since as it stands they might break when seeing extra stuff in the limit one by expecting a single value rather than multiple, as NAME mentions above. No, just dealing with people (maybe) opposing too-many-headers - I don't know if this is something that we can predictably foresee happening in the HTTPAPI WG or in the HTTP WG, but my intuition says "likely" given how we were asked to "condense" this information, so I think we might want to spend some time making a good case out of it. NAME other than potential breakages in pre-existing implementations, is there any additional point we could make to justify the additional header? I think they are all currently listed - that being said I think porting to a new header should be an easy task, so hopefully not a problem.
if almost everyone is implementing just the minimal specification, probably this could even simplify the addition of ...
The primary motivation is breakage, as you suggest, NAME The secondary motivation is ease of "upgrading" to adoption of quota policies, as NAME suggests. The flipside of "easy to adopt, easy to upgrade" is that the spec would also make it easy to never upgrade at all. This is a good thing, supposing that most services can operate perfectly fine without quota policies. A third, much weaker argument, is that the current approach of putting the "limit" and "quota policy" in the same header is that it's confusing. I would need more time to really state this argument more clearly, but what rubs me the wrong way here is that the current design basically puts two different kinds of data in the same list. As it stands, is a list of a numbers, but the first number (the "limit") is not like the rest of the numbers (the policy). The first number cannot have SFV parameters, but the others can (and typically will). It's an accident of SFV's syntax that this is even conceivable as an approach.
Code change:
fields only when a given quota is going to expire. Implementers concerned with response fields' size, might take into <del> account their ratio with respect to the payload data, or use header- compression http features such as HPACK. </del> <ins> account their ratio with respect to the content length, or use header-compression HTTP features such as HPACK. </ins> 4.

Related discussion:
text: For implementors, this means that does not simply deserialize as some sort of . It deserializes into a list, where the first element is an and the tail is a . I fear this will at minimum confuse folks, and perhaps even lead to incorrect implementations, such as people not realizing the first element of the list is not a quota policy at all.
Given URL it seems there's some consensus in providing quota policy in a separate field.
Code change:
successful ACK processing updates the keys of the KeyUpdate message sender, which is reflected in the change of epoch values. <ins> With a 128-bit key as in AES-256, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch to exceed 2^48-1.  In order to allow this value to be changed later, receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits. </ins> 9. If the client and server have negotiated the "connection_id"

Related discussion:
text: Yet another attempt to This builds on Chris's PR but just omits the epoch entirely from the AEAD nonce calculation. This is more consistent with TLS and doesn't require special case reasoning about why we only need to build in the bottom 16 bits. This relies entirely on the keys being different. Needs analysis.
This seems promising.
NAME this LGTM, but there's a conflict. Can you resolve prior to merging? NAME are you OK with the new rationale, and text that allows it to be relaxed in the future?
If I have understood and calculated correctly DTLS 1.3 limits the number of packets in a AES-GCM connection to 2^40.5 compared to 2^64 in DTLS 1.2. This is quite a severe limitation that is not mentioned explicitly. The AEAD limits in themselves are not a problem, but the combination of AEAD limits (2^24.5) and a small epoch (2^16) is a problem. I think this is major problem in some use cases of DTLS. E.g. most 3GPP 5G use cases where DTLS or DTLS/SCTP is used for semi-permanent connections (lasting years) and where the terminating the connection cause severe disturbances. I did not find any discussion about this problem (but I could easily have missed it) It is known that the limit of 2^48 packets in SRTP can be reached and 2^40.5 is significantly smaller than this... If the document was not in such a late stage, I would have suggested to increase the size of the epoch to 32 bits..... I think this and the other problems DTLS 1.3 has with semi-permanent connections has to be solved sooner than later.
NAME thanks for filing this. I hear you about the late stage, but IIRC we never represent the entire epoch on the wire in any case, so it seems like just changing it to 32 bits would be pretty easy, so why not do it now?
How do the chacha20 numbers compare to the AES-GCM ones?
Code change:
successful ACK processing updates the keys of the KeyUpdate message sender, which is reflected in the change of epoch values. <ins> With a 128-bit key as in AES-256, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch to exceed 2^48-1.  In order to allow this value to be changed later, receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits. </ins> 9. If the client and server have negotiated the "connection_id"

Related discussion:
text: NAME I don't think (D)TLS 1.3 puts any limits on ChaCha20 so my understanding is understanding is that the total number of packets can be protected in the current drafts is ChaCha20 2^64 (2^48 2^16) AES-GCM 2^40.5 (2^24.5 2^16) AES-GCM 2^39 (2^23 * 2^16)
NAME I am all for changing this now. I made a PR that change epoch from uint16 to uint32. As you say, it seems like a pretty easy change to do. Is uint32 the right size?
Unless you think we should do uint64. NAME NAME what would we have to do to make this change?
URL Magnus Westerlund thinks uint64 would be a safer bet.Michael Tüxen suggest to wrap the uint16 epoch instead. That might be an easier solution. I don't see a direct problem in DTLSPlaintext, ACK message, or recordsequencenumber with a uint16 epoch that is allowed to wrap like: 4, 5, ... 2^16-1, 4, 5, ... 2^16-1, 4, 5, ...
NAME NAME NAME since it's through the IESG we would need to at least raise that this change was made after they had approved it. I suspect that doing some kind of 2-week heads up to the WG/IESG that we want to make the change before landing it. But, if we do that or something more drastic that's really up to NAME
I want to point out that allowing wrapping per may not be the best solution if one considers to use the DTLS epoch as part of the input to the TLS exporter as suggested in . Then one want an input that doesn't wrap, and then to ensure that one doesn't practically run into any limits, then an uint64 would be better. An unit32 appears to be sufficient for a quite extreme use case with minimal messages size (which is one DTLS record with 4 byte user message) and high bandwidth (10 Gbps) sustained over a period of more than 5 years before the epoch would wrap.
Code change:
successful ACK processing updates the keys of the KeyUpdate message sender, which is reflected in the change of epoch values. <ins> With a 128-bit key as in AES-256, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch to exceed 2^48-1.  In order to allow this value to be changed later, receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits. </ins> 9. If the client and server have negotiated the "connection_id"

Related discussion:
text: However, to my understanding the full epoch value are so rarely included in transmitted DTLS messages that its size have minimal implication on the overhead that it is not worth saving 4-bytes to be certain to have eliminated any practical limitation.
I think a 2-week WGLC and notifying the IESG will suffice.
FYI. We have now run into quite many problems with the interworking of semi-permanent DTLS/SCTP connections (lasting years) and DTLS 1.3: No Diffie-Hellman rekeying No post-handshake server authentication No rekeying of the exporter_secret 2^40.5 packets limit 2 minute MSL requirement 2^38.5 byte SCTP user message size limit Our initial plan was to just replace DTLS 1.2 with DTLS 1.3, leave DTLS/SCTP as is, but as the problems keep adding up we are now startnig to consider quite big changes to DTLS/SCTP 1.3 to make this work: URL Using new DTLS connections instead of KeyUpdate could potentially address the first five, but is a significant change.
Hi, Based on the problems long-lived DTLS/SCTP had with DTLS 1.3 (as well as DTLS 1.2 without renegotiation and respecting AEAD limits) we restructured DTLS/SCTP (RFC6083bis) to use parallel connections instead of relying on renegotiation and post-handshake messages. We think this quite easily solves all the problems we had without requiring any updates of DTLS 1.3. It also makes DTLS/SCTP less dependant on version specific DTLS mechanisms. It will hopefully work without changes with any future DTLS 1.4. URL We can now firmly RECOMMEND DTLS 1.3 which I think is very important. 5G is to a large degree replacing or complementing IPsec with TLS, DTLS, and DTLS/SCTP. I will do my best to transition 3GPP to DTLS 1.3 asap. FYI, 3GPP DTLS/SCTP associations have very long lifetimes (can be years), strive for five nines (99.999%) availability and cannot be teared down without causing major disruptions.
Code change:
successful ACK processing updates the keys of the KeyUpdate message sender, which is reflected in the change of epoch values. <ins> With a 128-bit key as in AES-256, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch to exceed 2^48-1.  In order to allow this value to be changed later, receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits. </ins> 9. If the client and server have negotiated the "connection_id"

Related discussion:
text: With such long lifetimes we think mutual reauthentication, rekeying of the SCTP-AUTH key, and forcing attackers to dynamic key exfiltration [RFC7624] are required features. I still think should be done. 2^40.5 packets is quite limiting.
Seems OK.Thanks -- this LGTM. We'll need to do a brief consensus call given the type of change.
Code change:
entities that handle the data, but do not modify it (such as TURN relays). <del> It includes necessary functions for congestion control: When not to send data. </del> <ins> It includes necessary functions for congestion control, retransmission, and in-order delivery. </ins> WebRTC endpoints MUST implement the transport protocols described in I-D.ietf-rtcweb-transports.

Related discussion:
text: Spencer had the following comment: I'm not sure how tutorial you want section 4 to be, but I'd at least mention appropriate retransmission and in-order delivery, in addition to congestion control, since you get that with SCTP on the data channel.