jiebi/CodeConvo huggingface dataset:
Code change:
available in that moment.  Nonetheless servers MAY decide to send the "RateLimit" fields in a trailer section. <del> To ease the migration from existing rate limit headers, a server SHOULD be able to provide the "RateLimit-Limit" field even without the optional "quota-policy" section. </del> 3.1. Servers are not required to return "RateLimit" fields in every

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:
available in that moment.  Nonetheless servers MAY decide to send the "RateLimit" fields in a trailer section. <del> To ease the migration from existing rate limit headers, a server SHOULD be able to provide the "RateLimit-Limit" field even without the optional "quota-policy" section. </del> 3.1. Servers are not required to return "RateLimit" fields in every

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:
available in that moment.  Nonetheless servers MAY decide to send the "RateLimit" fields in a trailer section. <del> To ease the migration from existing rate limit headers, a server SHOULD be able to provide the "RateLimit-Limit" field even without the optional "quota-policy" section. </del> 3.1. Servers are not required to return "RateLimit" fields in every

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:
the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious ones.  This is particularly relevant when we consider the SDP that is <del> passed to setLocalDescription().  While correct API usage requires that the application pass in SDP that was derived from createOffer() or createAnswer(), there is no guarantee that applications do so. The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. </del> <ins> passed to setLocalDescription.  While correct API usage requires that the application pass in SDP that was derived from createOffer or createAnswer, there is no guarantee that applications do so.  The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. </ins> Conversely, the application programmer needs to be aware that the JavaScript does not have complete control of endpoint behavior.  One

Related discussion:
text: Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).
Code change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP <del> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> Definitions of terms that are used in this document:

Related discussion:
text: I've had to make some changes in the template to deal with some odd regressions in CircleCI (see URL for details). This is the updated configuration.
Yeah, given how this breaks in Circle; that's probably wise.
NAME NAME do you think that you could stop following this project in CircleCI? Then we can merge this one.
Is there a reason not to simply move this repo over to GitHub Actions as well?
Code change:
If the RS needs to, it can post a set of resources as described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol to <del> the AS's resource registration endpoint. </del> <ins> the AS's resource registration endpoint along with information about what the RS will need to validate the request. REQUIRED.  The list of access rights associated with the request in the format described in the "Resource Access Rights" section of I-D.ietf-gnap-core-protocol. REQUIRED.  The identification used to authenticate the resource server making this call, either by value or by reference as described in authentication. OPTIONAL.  The token format required to access the identified resource.  If the field is omitted, the token format is at the discretion of the AS.  If the AS does not support the requested token format, the AS MUST return an error to the RS. OPTIONAL.  If present and set to "true", the RS expects to make a token introspection request as described in introspection.  If absent or set to "false", the RS does not anticipate needing to make an introspection request for tokens relating to this resource set. </ins> The RS MUST identify itself with its own key and sign the request. <del> The AS responds with a handle appropriate to represent the resources list that the RS presented. </del> <ins> The AS responds with a reference appropriate to represent the resources list that the RS presented in its request as well as any additional information the RS might need in future requests. REQUIRED.  A single string representing the list of resources registered in the request.  The RS MAY make this handle available to a client instance as part of a discovery response as described in I-D.ietf-gnap-core-protocol or as documentation to client software developers. </ins> <del> The RS MAY make this handle available as part of a discovery response as described in I-D.ietf-gnap-core-protocol or as documentation to developers. </del> <ins> OPTIONAL.  An instance identifier that the RS can use to refer to itself in future calls to the AS, in lieu of sending its key by value. </ins> <del> [[ See issue #117 [2] ]] </del> <ins> OPTIONAL.  The introspection endpoint of this AS, used to allow the RS to perform token introspection. </ins> 4.

Related discussion:
text: Expands the definition of the resource set registration protocol, used by an RS to declare a resource set to an AS at runtime and receive a reference identifier for that resource set to hand to a client.
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: f9aac0b2af163c0f9a58ba17e93db7e8956140bf :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Registering a Resource Handle: Editor's note: It's not an exact match here because the "resource_handle" returned now represents a collection of objects instead of a single one. Perhaps we should let this return a list of strings instead? Or use a different syntax than the resource request? Also, this borrows heavily from UMA 2's "distributed authorization" model and, like UMA, might be better suited to an extension than the core protocol
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: URL The example shows in flight 5 Certificate --------> ClientKeyExchange CertificateVerify [ChangeCipherSpec] Finished (cid=100) Does this imply that the flight 5 is send with cid = 100 or only the Finished? I would prefer to be able to send also the other handshake messages of the flight with a cid, that would make it harder to disturb handshakes by spoofed handshake messages.
In DTLS 1.2 only the Finished message is encrypted. In the current design we make use of the CIDs only once encryption is enabled. I should explain that only the Finished message contains a CID here.
See additional explanation in PR : URL
I would enjoy it, if the cid could be extended into the not encrypted handshake messages also. Is there any reason, not to do so? My consideration is to make the handshake "slightly more" protected against spoofing. The current protection in RFC6347 is limited to URL and URL . The first applies only to the CLIENTHELLO ("cookie" protection again spoofed CLIENTHELLOs). The second (MAC and Anti-Replay) is only usable after a successful handshake. If an attacker spoofs other handshake messages, the attacker may block a handshake from being successful (even if the time window for that is very small and so it would be a rather expensive attack). Using a CID would enable a implementation either to handshake even when addresses are changing during the handshake or to protect the handshake slightly more (not supporting address changes but) use the CID to validate the handshake message belonging to this handshake. I would leave the chosen strategy to the implementation, enabling implementations to flexible chose the strategy depending on the current handshake load (means: supporting address changes in handshakes as normal operation, but switch dynamically to the more protective one, if a certain relative number of handshake fails.) My current work in progress: URL contains already this feature as experimental extension. It's easy to be added to a cid implementation.
Section 4.1.2 describes an attack where an attacker injects traffic that cannot be correctly processed due to a MAC failure. The reason why MAC failures in DTLS do not lead to a connection termination (unlike in TLS) is that they are much easier to mount: an attacker only needs to know the source and destination IP and port.
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: Section 4.2.1 talks about the cookie exchange, which has been added to prevent amplification attacks against third parties. I would argue that these two attacks are very different from what you are trying to tackle. You would like to add resiliency against on-path (?) attacks sending spoofed handshake messages. I cannot see how the CID provides that extra protection. I understand the use case of address changes during the handshake. The question is whether this is actually something real. If the IP address & port changes during the handshake then this is indeed annoying but how often does this happen?
I mentioned 4.1.2 and 4.2.1 just to sum up the current protection mechanisms. The attack, I consider, is a off-path. e.g. using PSK, someone spoofs a CLIENTKEYEXCHANGE with the identity "ghost". Now it's hard for the server to differentiate the wrong from the right CLIENTKEYEXCHANGE with identity "me". With the CID in the handshake, spoofing into the handshake will be much harder. I don't assume, that such attacks will be easy or happen frequently. But assuming something as a "theft detection" for something valuable, it may be used to block the reporting message.
I don't understand why we'd need to enable CID during handshake, and in particular on Finished? Any sane handshake will complete well before any NAT rebinding has a chance to mess with the path (note that in-flight handshake messages refresh the port bindings...). What kind of use case would that address? Is it connection migrations while handshaking? I'm not sure the "increased robustness against spoofing" argument is a very strong one: the handshake is either robust as-is or we are in trouble :-) Also, would that imply reconsidering the security analysis of the handshake? My preference instead would be to send tls12cid records only after the handshake has completed successfully, i.e. on the first application_data.
FMPOV: protects in the long period before the handshake. With the cookie you could not only spoof CLIENTHELLOs an trigger heavy functions. protects in the long period after the handshake. With the MAC filter it's also not possible to spoof messages at that period (or even repeat them).
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: But in the short period (few seconds) of the handshake itself, I couldn't find a straight forward method, to distinguish between the right inner handshake messages and spoofed ones. Using the CID would offer a similar protection for those inner handshake messages as the cookie for the CLIENTHELLO. I don't assume, that such attack will happen too frequently. But I could assume, if someone has a high interest, such an attack may be used to "deny" a handshake of a certain peer for a certain time period, e.g. "theft detection" for one device may be blocked for a couple of minutes. Only because the CID would offer protection against this "for free", if used during the handshake, I started to try to introduce that.
Let me admit, that the attack in the inner handshake is not likely. Some implementations seems to use the 4.1.2 mechanism even in epoch 0, that may help, but introduces other risks (attack possibilities for the inner handshake). FMPOV, currently you would need too much implementation knowledge to execute such an attack. But, though in my opinion, using the CID within the handshake, offers a protection "for free", I think it's worth to be considered.
Sorry, I'm not sure I understand which kind of extra protection we'd get: when handshaking the CID is spoofable as much as the source address in the UDP packet.
Another argument for not changing the wire image of the record layer during the handshake phase is possible middleboxes interference.
The cookie of 4.2.1 is also spoofable, but for successful spoofing it must be the right cookie for that time period and address. The same applies for the CID. If combined with the address, then it protects, because a spoofer must know the CID. (And sure, it's visible and .. but the cookie is also visible. The point is also the time period, when this CID could be used for spoofing. And that's very short, comparable with the short valid time-period of the cookie.)
I'm still confused, could you characterise precisely your attacker in terms of its goal and position in the network? Thanks!
I don't want to change the wire image more, than this draft already does!