jiebi/CodeConvo huggingface dataset:
Code change:
Source Address Validation (SAV): The handshake protocol may interact with the transport protocol or application to validate the address of the remote peer that has sent data.  This involves <del> sending a cookie exchange to avoid DoS attacks. </del> <ins> sending a cookie exchange to avoid DoS attacks.  (This list omits protocols which depend on TCP and therefore implicitly perform SAV.) </ins> DTLS

Related discussion:
text: We got another Secdir review: Reviewer: Paul Wouters Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Has Nits Compared to my last review (-09) a lot of text has been removed, reducing the technical details and giving a briefer (but arguably cleaner) overview. I do still have a personal preference of dropping CurveCP and MinimalT as I don't really think these are anything but abandoned research items. I have never seen or heard of these being deployed. I would be more tempted to list openconnect (draft-mavrogiannopoulos-openconnect) which actually does see quite some deployment. If the intent is really to show different kind of API's, than there are other esoteric examples that could be included, such as Off-The-Record(OTR) or Signal, which are mostly encrypted chat programs, but with the ability to generate session keys for encrypted bulk transport (eg for video/audio or file transfer) Section 5.1 "Session Cache Management (CM):" which does not include IKEv2/IPsec, even though it does have session resumption (RFC 5723). I guess this is because the section limits itself to "the application" that can restart the session. But for IKEv2/IPsec the same could be said. An application that after a long idle period sends a packet, triggers a kernel ACQUIRE, which triggers an IKEv2 session resumption. WireGuard does not have this capability as there are no API/hooks for packet trigger tunnel events (AFAIK) "Pre-Shared Key Import (PSKI):" lists WireGuard, but AFAIK it does not support PSK based authentication - only public key based authentication. While I understand the IKEv2 entry (PSKs are used for authentication of peers), I am not sure the ESP entry should be here.
Code change:
Source Address Validation (SAV): The handshake protocol may interact with the transport protocol or application to validate the address of the remote peer that has sent data.  This involves <del> sending a cookie exchange to avoid DoS attacks. </del> <ins> sending a cookie exchange to avoid DoS attacks.  (This list omits protocols which depend on TCP and therefore implicitly perform SAV.) </ins> DTLS

Related discussion:
text: ESP does not "authenticate peers", unless you call "being able to decrypt and authenticate packets" as an instance of "authenticating peer" Section 5.2 This states "This can call into the application to offload validation.". This "can" is only not supported by WireGuard, as all of this is happening inside the kernel. Maybe a note could be useful here? "Source Address Validation" - It is a little unclear why TCP based protocols are not listed here. They (implicitly) do source address validation. Perhaps the introduction in this paragraph can state this more explicitly. Eg "for those protocols that do not use TCP and therefor do not have builtin source address validation ......."
On which protocols to include, MinimalT and CurveCP have different feature sets and interfaces exposed, which I think warrants their inclusion. Things like Signal and OTR indeed have seen very wide deployment, though they're asynchronous, application-layer protocols akin to MLS, which I think is out of scope. I'd also not like to add draft-mavrogiannopoulos-openconnect, if for no other reason than to draw a line in the sand. (We run the risk of indefinitely delaying this while adding more protocols.) On Session Cache Management, this is an explicit interface, and the example Paul mentions, while correct, does not exercise such an explicit interface. On WireGuard and PSK import, WireGuard uses the IKpsk2 Noise pattern (see URL, and URL), in which a responder uses its PSK to additionally authenticate a connection. On ESP and PSK import, we note that importing a PSK can be used for "encrypting (and authenticating) communication with a peer," which remains true for IPsec. (Right NAME I'll address the issues in 5.2 in a PR!
Code change:
of efficiency.  This is not a strict requirement.  The default is to not have this option. <del> Notification of special errors (excessive retransmissions, ICMP error message arrival): This boolean property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold, or when an ICMP error message arrives.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. </del> <ins> Notification of excessive retransmissions: This boolean property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. Notification of ICMP error message arrival: This boolean property specifies whether an application considers it useful to be informed when an ICMP error message arrives.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. </ins> Control checksum coverage on sending or receiving: This boolean property specifies whether the application considers it useful to

Related discussion:
text: What makes these errors "special"? It seems a strange term to use, and the meaning is unclear.
I didn't write this, but I think it was an effort to lump together, from minset, two quite different types of errors: 1) notification of excessive retransmissions; 2) notification of icmp error message arrival. Any suggestions for a common term?
If it's just those two types of errors, we can probably just list them...
URL is what I did in minset :)
so the suggestion is to split these out into two protocol selection properties?
yes, I think so
all right then, see
lgtm
Code change:
Each "a=mid" line MUST stay the same. <del> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. </del> <ins> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same unless the "IceRestart" option (sec.options-handling was specified.  Note that it's not clear why you would actually want to do this, since at this point ICE has not yet started and is thus unlikely to need a restart. </ins> For MediaStreamTracks that are still present, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same.

Related discussion:
text: This is OK with me
S 5.2.2 says: If the initial offer was applied using setLocalDescription, but an answer from the remote side has not yet been applied, meaning the PeerConnection is still in the "local-offer" state, an offer is generated by following the steps in the "stable" state above, along with these exceptions: o The "s=" and "t=" lines MUST stay the same. o Each "a=mid" line MUST stay the same. o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. However, Section 5.2.3.4 says: If the "IceRestart" constraint is specified, with a value of "true", the offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in RFC5245, Section 9.1.1.1. If this constraint is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd are already generated).
Yes, if this is an ICE restart, then ufrag/pwd need to change.
Discussed in DC: restart requires a change of credentials. Might want to add text that notes the dangers in doing this (i.e., don't do this).
Code change:
transported depends on lower layers, which need to enable error messages to be sent and processed as intended. <del> All error messages in EDHOC are fatal.  After sending an error message, the sender MUST discontinue the protocol.  The receiver SHOULD treat an error message as an indication that the other party likely has discontinued the protocol.  But as the error message is not authenticated, a received error messages might also have been sent by an attacker and the receiver MAY therefore try to continue the protocol. </del> <ins> Errors in EDHOC are fatal.  After sending an error message, the sender MUST discontinue the protocol.  The receiver SHOULD treat an error message as an indication that the other party likely has discontinued the protocol.  But as the error message is not authenticated, a received error message might also have been sent by an attacker and the receiver MAY therefore try to continue the protocol. </ins> error SHALL be a CBOR Sequence (see CBOR) as defined below

Related discussion:
text: Looks good.
The current draft has the following text in several places: "If any verification step fails, the Responder MUST send an EDHOC error message back, formatted as defined in {{error}}, and the protocol MUST be discontinued." I am not sure this is a good idea. This means that the availability of EDHOC will be low. An attacker can e.g. send a single byte as message_4 and it would make EDHOC shut down imidiatly. I think we need to soften this and give the implementation some more choice here. Are there constrained radio protocols where noice could be mistaken for an actual message and forwarded to EDHOC or do all constrained radio have strong enough CRC to make sure that that more or less never happens?
I just changed the following text OLD: If the Initiator previously received from the Responder an error message with error code 1 (see Section 6.3) indicating cipher suites supported by the Responder which also are supported by the Initiator, then the Initiator SHALL select the most preferred cipher suite of those. NEW: If the Initiator previously received from the Responder an error message with error code 1 (see Section 6.3) indicating cipher suites supported by the Responder which also are supported by the Initiator, then the Initiator SHOULD select the most preferred cipher suite of those (note that error messages are not authenticated and may be forged). Made me think about that I don't think the group has discussed if some error messages should be authenticated. Some error messages to message2 could include a MAC to prove that the error was sent by the same party that sent message3. error messages to message3 and message4 could be authenticated. I am uncertain if this is worth specifying. At least not as long as there are easier ways to an attacker to end the protocol. I think what needs to be done is to specify that a processing error does not need to discontinue the protocol, the received message can have been an attack. receiveing an error does not need to discontinue the protocol, the received error can have been an attack.
Code change:
transported depends on lower layers, which need to enable error messages to be sent and processed as intended. <del> All error messages in EDHOC are fatal.  After sending an error message, the sender MUST discontinue the protocol.  The receiver SHOULD treat an error message as an indication that the other party likely has discontinued the protocol.  But as the error message is not authenticated, a received error messages might also have been sent by an attacker and the receiver MAY therefore try to continue the protocol. </del> <ins> Errors in EDHOC are fatal.  After sending an error message, the sender MUST discontinue the protocol.  The receiver SHOULD treat an error message as an indication that the other party likely has discontinued the protocol.  But as the error message is not authenticated, a received error message might also have been sent by an attacker and the receiver MAY therefore try to continue the protocol. </ins> error SHALL be a CBOR Sequence (see CBOR) as defined below

Related discussion:
text: Closing
Current specification mandates sending error messages upon certain failures. But in cases when message processing fails when no state has been allocated or when no connection identifier has been found or then a more appropriate action would be to just silently drop the message.
I think the MUST (if possible) is good. Debugging without any error messages is not nice. We now other protocols that it is good to mandate error messages. It is kind of obvious that can not send an error if you don't now where/how to send it. Don't know if that has to be pointed out....
Migth be good to not sent error if you are under a DoS attack.
This issue is addressed by pull request that also address availability
The PR has been discussed and merged. Closing
Code change:
order to allow the inclusion of an optional suffix. The extended date/time format is described by the rule "date-time- <del> ext".  "date-time" is imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234. </del> <ins> ext".  "date-time" and "time-numoffset" are imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234. </ins> Note that a "time-zone" is syntactically similar to a "suffix-tag", but does not include an equals sign.  This special case is only

Related discussion:
text: URL supports offset time zones, e.g. . For backwards compatibility, this RFC should support them too. This PR also adds clarifying text to several time-zone-related definitions.
Makes sense. Should I start one? Yep, we added these in Temporal primarily for compatibility with prior art in URL URL In Java (and currently in Temporal) a time zone ID can either be an IANA name or an offset. The ID is an index into a set of rules ( in Java, in Temporal) for converting between exact time and local time. If the ID is an offset, there's only one trivial rule because the offset is always the same. I don't have a strong opinion about the name of offset time zones.
NAME - Let me know if you have responses to the questions in my comment above, or how you'd like me to change this PR. Thanks!
I think we still need the mailing list discussion first. If we get to a certain state of clarity by March 18, we might be able to post yet another update of the draft right before IETF week.
Sounds good. I sent mail to the mailing list. Waiting for responses.
I plan to merge this within a couple of hours, so we have a merged draft to look at in Monday's WG meeting. Since the discussion hasn't concluded yet, I'll edit the merge so it is useful for those discussions; we can edit some more after Monday's meeting.
Sounds good to me. Based on your comments here and on the mailing list, I think we're in agreement on the important points.
Hi NAME - is the merged draft available? If not, I'm happy to make the edits you and NAME suggested here in this PR, but didn't want to step on changes you're making in parallel. Let me know how I can help. Thanks!
I merged the PR and made some edits in main. I included you in the contributor list; please advise if that is OK, the information is right and whether you want to include any more contact/affiliation information.
Great! Your edits look good to me. I may follow up after the meeting with minor text clarification PRs but nothing important. Info looks right. I'm a volunteer not working on behalf of my employer so no need for additional affiliation. Thanks!
Code change:
order to allow the inclusion of an optional suffix. The extended date/time format is described by the rule "date-time- <del> ext".  "date-time" is imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234. </del> <ins> ext".  "date-time" and "time-numoffset" are imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234. </ins> Note that a "time-zone" is syntactically similar to a "suffix-tag", but does not include an equals sign.  This special case is only

Related discussion:
text: The current ABNF for the time zone extension does not support offset time zones, e.g. . These zones are supported in URL, which is the prior art driving the bracketed time zone extension format. Therefore, I'm assuming that it makes sense for the standard to also allow offsets in brackets too. Current ABNF: URL Suggested ABNF for, where is imported from RFC 3339: Example of Java usage:
Please excuse my ignorance: What is the meaning of ? We'd need some text explaining the semantics.
This format asserts that derived timestamps (e.g. add one day) should also use the offset. It's mostly for backwards compatibility with URL It's not recommended for normal use. Heres the explanatory text I added in : >
I assume that conflicts between the timestamp offset and a bracketed offset (e.g. ) should be handled the same as other conflicts, per discussion in URL
Code change:
7.3.4. <del> This method is indicated by "dpop" in the "proof" field.  The signer creates a Demonstration of Proof-of-Possession signature header as described in I-D.ietf-oauth-dpop section 2.  In addition, this specification defines the following fields to be added to the DPoP payload: Digest of the request body as the value of the Digest header defined in RFC3230.  When a request contains a message body, such as a POST or PUT request, this field is REQUIRED. In this example, the request body is the following JSON object: ~~~ { "access_token": { "access": [ "dolphin-metadata" ] }, "interact": { "start": ["redirect"], "finish": { "method": "redirect", "uri": "https://client.foo/callback", "nonce": "VJLO6A4CAYLBXHTR0KRO" } }, "client": { "proof": "dpop", "key": { "jwk": { "kid": "gnap-rsa", "kty": "RSA", "e": "AQAB", "alg": "RS256", "n": "hYOJ- XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_ 3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ" } } "display": { "name": "My Client Display Name", "uri": "https://client.foo/" }, } } ~~~ The JOSE header contains the following parameters, including the public key: The JWS Payload contains the following JWT claims, including a hash of the body: This results in the following full HTTP message request: The verifier MUST parse and validate the DPoP proof header as defined in I-D.ietf-oauth-dpop.  If the HTTP message request includes a message body, the verifier MUST calculate the digest of the body and compare it to the "htd" value.  The verifier MUST ensure the key presented in the DPoP proof header is the same as the expected key of the signer. 7.3.5. </del> This method is indicated by "httpsig" in the "proof" field.  The sender creates an HTTP Message Signature as described in I-D.ietf- httpbis-message-signatures.

Related discussion:
text: remove OAuth DPoP binding. Described why on IETF mailing list: only works for asymmetric keys, requires key be presented in the header (duplicating information from GNAP messages). It was never meant to be a general purpose signing mechanism, though the FAPI group in OIDF is considering it as an option in current proposed work.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: c380eb747945a8002c19de9784e86bee713951a0 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Ok that's weird (just removed some lines...), will have a look
Ok that was due to my rust analyser in vscode, fixed it now
Code change:
seconds, between two consecutive notifications (whether or not the resource value has changed).  In the absence of this parameter, the maximum period is up to the server.  The maximum period MUST be <del> greater than zero and MUST be greater than the minimum period parameter (if present) otherwise the receiver MUST return a CoAP error code 4.00 "Bad Request" (or equivalent). </del> <ins> greater than zero and MUST be greater than, or equal to, the minimum period parameter (if present) otherwise the receiver MUST return a CoAP error code 4.00 "Bad Request" (or equivalent). </ins> 3.1.3.

Related discussion:
text: Signed-off-by: David Navarro For the reasons stated in .
Hi, OMA LwM2M is using Minimum Period (pmin) and Maximum Period (pmax) attributes. The DynLink draft has this requirement: In its version 1.0, LwM2M had a different version of this requirement in the form: Thus having pmax equal to pmin was allowed. In LwM2M 1.1 we aligned this requirement with the DynLink one, making pmin equal to pmax forbidden. However, it was that having pmin equal pmax is a valid use case if the client wants the notification to be sent exactly every N seconds. Is there a strong opinion on forbidding pmax to be equal to pmin, or are people open to changing the Dynlink requirement ? Regards
NAME After the discussion at IETF 109, I think we can agree that there are no strong opinions against allowing pmax to be greater than or equal to pmin in the draft. However in order to avoid any ambiguity in interpretation, do we want reflect the discussion so far, so that the draft has pmax == pmin, specifically for this use case, ie when this condition is met, then the CoAP server sends (is it a MUST/SHOULD/MAY?) the resource representation every N seconds? Also how does the client then cancel this request?
Closing this issue, with the draft allowing pmax to have equality to pmin
Code change:
that attest to this information. The most basic Privacy Pass protocol provides a set of cross-origin <del> authorization tokens that protect the client's anonymity during </del> <ins> authorization tokens that protect the Clients' anonymity during </ins> interactions with a server.  This allows clients to communicate an attestation of a previously authenticated server action without having to reauthenticate manually.  The tokens retain anonymity in

Related discussion:
text: Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.
Code change:
In response to a client instance's request, the AS responds with a JSON object as the HTTP entity body.  Each possible field is detailed <del> in the sections below </del> <ins> in the sections below. </ins> In this example, the AS is returning an response-interact-redirect, a response-interact-finish, and a response-continue.

Related discussion:
text: Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview: