jiebi/CodeConvo huggingface dataset:
Code change:
This document <del> 8.2. This document will request IANA to register IP_PACKET in the "HTTP Datagram Format Types" registry established by HTTP-DGRAM. 8.3. </del> <ins> 9.2. </ins> This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM:

Related discussion:
text: Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric
Code change:
among parallel groups.  For example, suppose a common member M of two groups A and B has performed a key update in group A but not in group B.  The key update provides PCS with regard to M in group A.  If a <del> PSK exported from group A and injected into group B, then some of </del> <ins> PSK is exported from group A and injected into group B, then some of </ins> these PCS properties carry over to group B, since the PSK and secrets derived from it are only known to the new, updated version of M, not to the old, possibly compromised version of M.

Related discussion:
text: Thanks both, I'll have a look today.
Looks good ! Thanks Richard!
The architecture document mentions PSKs in several places, but does not discuss the security of them. Nor does it discuss the security of External Proposals and External Commits. Notably, the third paragraph of 5.1 Membership Changes says "…the set of devices controlled by the user can only be altered by an authorized member of the group." The set of devices could be altered via an External Commit by a non-member. At the end of 5.2 Parallel Groups there is a vague mention of "using the PSK mechanism to link healing properties among parallel groups.", but no discussion of the security. Likewise Section 5.5 Recovery After State Loss talks about PSKs as the solution to a problem but the risks are not discussed. External Proposals and External Commits should be discussed in section 5.4 Access Control.
NAME I fixed the specific problems you note in
Code change:
violated, then the security properties of TLS are severely weakened. As discussed in use-cases, there are use cases where it is desirable <del> for multiple clients or multiple servers share a PSK.  If this is </del> <ins> for multiple clients or multiple servers to share a PSK.  If this is </ins> done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall system is inherently rather brittle.  There are a number of obvious

Related discussion:
text: FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME
Code change:
5.1. Configuration interfaces are used to configure the security protocols <del> before a handshake begins or the keys are negotiated. </del> <ins> before a handshake begins or keys are negotiated. </ins> Identities and Private Keys (IPK): The application can provide its identity, credentials (e.g., certificates), and private keys, or

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:
5.1. Configuration interfaces are used to configure the security protocols <del> before a handshake begins or the keys are negotiated. </del> <ins> before a handshake begins or keys are negotiated. </ins> Identities and Private Keys (IPK): The application can provide its identity, credentials (e.g., certificates), and private keys, or

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:
the first transport encryption supported in some classes of constrained devices. <ins> An ACP node announces its ability to support DTLS as the ACP secure channel protocol in GRASP as the "DTLS" method for the "AN_ACP" objective. </ins> To run ACP via UDP and DTLS v1.2 RFC6347 a locally assigned UDP port is used that is announced as a parameter in the GRASP AN_ACP objective to candidate neighbors.

Related discussion:
text: During IETF 106 I solicited some feedback on the ACP IPsec/IKEv2 usage from Valery Smyslov; I've tried to digest that feedback into new text here. Some aspects are still subject to change. I also made a minor tweak to the DTLS section to bring it into parity with the IPsec one.
Merging first, then fixing.
Code change:
format payload to register. The registrant-ep includes the same registration parameters in the <del> POST request as it would per registration.  The registration base URI of the registration is taken from the registrant-ep's network address (as is default with regular registrations). </del> <ins> POST request as it would with a regular registration per registration.  The registration base URI of the registration is taken from the registrant-ep's network address (as is default with regular registrations). </ins> Example request from registrant-EP to RD (unanswered until the next step):

Related discussion:
text: Some small mainly editorial fixes from Ben's review, to be merged soon.
From Ben's updated ballot: Good point, queued up.
From Ben's updated ballot:: → "The RD (always, but especially here) then needs to verify any lookup client's authorization before reveling this information directly (in resource lookup) or indirectly (when using it to satisfy a resource lookup search criterion)"
From follow-up on Ben's initial DISCUSS: → "regular registrations (i.e., per {{registration}})"
From follow-up on Ben's initial DISCUSS: It'd sound like abuse of semicolons to me; keeping it open to ask RFC editor for their technical writing expertise.
Code change:
If present, a single "a=dtls-id" line is parsed as specified in I- D.ietf-mmusic-dtls-sdp Section 5, and the dtls-id value is stored. <ins> Any "a=identity" lines are parsed and the identity values stored for subsequent verification, as specified I-D.ietf-rtcweb- security-arch, Section 5. </ins> Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored.

Related discussion:
text: I fixed the grammar and added some text about "subsequent verification"
Also see URL
What's the issue?
Someone thought we should talk about how to parse SDP with more than one identity line and handle that. I did not look, we may already have whatever we need in the draft but I just opened this so we would at least go check.
JSEP practice is just to put in placeholders and link to the defining draft, so we should punt the actual semantics in security-arch.
See email to rtcweb from Stefan Håkansson subject "Identity in the SDP"
Sayeth Stefan: >[2] URL