jiebi/CodeConvo huggingface dataset:
Change:
represented in TLS "Handshake" messages, as in DTLS 1.3 (RFC9147, Section 5.2), regardless of "template.handshake_framing". <del> To ensure that all parties agree about what protocol is in use, the Cryptographic Label Prefix used for the handshake SHALL be "Sctls " for Stream cTLS and "Dctls " for Datagram cTLS.  (This is similar to the prefix substitution in Section 5.9 of RFC9147). </del> <ins> To ensure that all parties agree about what protocol is in use, and whether records are subject to loss, the Cryptographic Label Prefix used for the handshake SHALL be "Sctls " (for "Stream cTLS") if "Handshake" or "CTLSHandshake" transport was used, and "Dctls " (for "Datagram cTLS") otherwise.  (This is similar to the prefix substitution in Section 5.9 of RFC9147). </ins> 2.3.3.

Discussion:
NAME Ping. This is the last thing blocking a refreshed cTLS draft.
Just missed this. LGTM
Change:
freshness of a request.  This mechanism is not only important in the case of actuators, or other use cases where the CoAP operations require freshness of requests, but also in general for synchronizing <del> state between CoAP client and server. </del> <ins> state between CoAP client and server and to verify aliveness of the client. </ins> 1.2.

Discussion:
I did quite a lot of changes to the Echo parts as discussed earlier. The Echo parts are now clearer updated in requirements and general processing, and example implementations for Token Option Values. I wrote a reasonably long security consideration chapter and added the missing IANA section. I added updated Token handling which requires some changes to abstract and introduction. Removed some definitions that were not used. I have not touched the Request-Tag parts except for maybe some editorials.
I think you should already have write access to the repository; if you can't just push your changes, I'm afraid you'll have to ask Carsten to add you to the team at URL I'm merging this now to get things on, and am trying to add some fixes today still to upload this evening's state before the cut-off. A suggestion w/rt the pull request branches: could you just add commits rather than appending them (unless you're changing around in the same place)? That'd make it much easier to update one's mental model of the document.
The terms "blockwise request operation" and "blockwise response operation" are used (the former frequently, the latter only once), so I've reverted the line that drops them to their previous state in 382c308f3.
Change:
Clients interested in combating firewall ossification can initiate a connection using version 2 if they are either reasonably certain the server supports it, or are willing to suffer a round-trip penalty if <del> they are incorrect. </del> <ins> they are incorrect.  In particular, a server that issues a session ticket for version 2 indicates an intent to maintain version 2 support while the ticket remains valid, even if support cannot be guaranteed. </ins> 7.

Discussion:
Though no guarantee can be made, a client with a v2 ticket (which cannot be used with v1) might be in a good position to attempt v2 outright. Avoiding saying this creates something of a weird contradiction between sections.
Hmm. Your changes draws attention to the server expressing intent with a session ticket (but maybe not actual support), but that now seems oddly contrasting against the prior sentence that the client acts on reasonable confidence of support. So is the session ticket intent something a client can have reasonable confidence in, or not?
I thought that this was an appropriate amount of hedging on that point. The previous sentence is the "without other information, probably choose v1" side, the added sentence is the "maybe if you get a ticket you could bet the other way". Nothing firm either way, as tickets don't represent a commitment, they only signal intent in a way that alters probabilities.
Got it. On balance that seems right, we can't proscribe too much behaviour here. Looking forward to the research papers that analyse the effects of choice in the wild during 2023+
Change:
Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by the browser, so nothing stops a Web attacker from creating their own <del> IFRAME, loading the IdP proxy HTML/JS, and requesting a signature. In order to prevent this attack, we require that all signatures be tied to a specific origin ("rtcweb://...") which cannot be produced by content JavaScript.  Thus, while an attacker can instantiate the IdP proxy, they cannot send messages from an appropriate origin and so cannot create acceptable assertions.  I.e., the assertion request must have come from the browser.  This origin check is enforced on the relying party side, not on the authenticating party side.  The reason for this is to take the burden of knowing which origins are valid off of the IdP, thus making this mechanism extensible to other applications besides WebRTC.  The IdP simply needs to gather the origin information (from the posted message) and attach it to the assertion. Note that although this origin check is enforced on the RP side and not at the IdP, it is absolutely imperative that it be done.  The mechanisms in this document rely on the browser enforcing access restrictions on the DTLS keys and assertion requests which do not come with the right origin may be from content JS rather than from browsers, and therefore those access restrictions cannot be assumed. </del> <ins> IFRAME, loading the IdP proxy HTML/JS, and requesting a signature over his own keys rather than those generated in the browser. However, that proxy would be in the attacker's origin, not the IdP's origin.  Only the browser itself can instantiate a context that (a) is in the IdP's origin and (b) exposes the correct API surface. Thus, the IdP proxy on the sender's side MUST ensure that it is running in the IdP's origin prior to issuing assertions. </ins> Note that this check only asserts that the browser (or some other entity with access to the user's authentication data) attests to the request and hence to the fingerprint.  It does not demonstrate that <del> the browser has access to the associated private key.  However, attaching one's identity to a key that the user does not control does not appear to provide substantial leverage to an attacker, so a proof of possession is omitted for simplicity. </del> <ins> the browser has access to the associated private key, and therefore an attacker can attach their own identity to another party's keying material, thus making a call which comes from Alice appear to come from the attacker.  See I-D.ietf-mmusic-sdp-uks for defenses against this form of attack. </ins> 6.4.2.

Discussion:
…
That's an artifact of an older design.
NAME PTAL
Note that "ensure that it is running in the IdP's origin" is a non-trivial thing. But I guess we can rely on stackoverflow for that ultimately :)
Change:
reset its congestion state (see migration-cc), so the port SHOULD only be changed infrequently. <del> Endpoints that use connection IDs with length greater than zero could have their activity correlated if their peers keep using the same destination connection ID after migration.  The goal is to ensure that packets sent on different paths cannot be correlated.  To </del> <ins> Endpoints that supply connection IDs with length greater than zero could have their activity correlated if their peers keep using the same destination connection ID after migration.  To ensure that packets sent on different paths cannot be correlated, endpoints SHOULD provide with new connection IDs before peers migrate.  To </ins> fulfill this privacy requirement, endpoints that initiate migration and use connection IDs with length greater than zero SHOULD provide their peers with new connection IDs before migration.

Discussion:
As discussed in Tokyo, forcing your peer to change a connection ID is still possible, but we would require a change in port in order to effect that. .
I don't remember this being what we agreed, and it's not necessary. You only need to change when you see a new path, not after a new CID. That's how we got rid of counting to infinity.
I'm not sure it is always well-defined when you are on a new path and you risk accidental linkage. I believe this was the thinking behind this.
IIRC, NAME is correct; we agreed to do this on peer address change. If you don't know you've been rebound and you reuse a CID, you've already linked yourself; the peer changing CID in response is pointless. If you either anticipate a rebinding or proactively change ports, and change both CID and address simultaneously, then it doesn't matter which of those triggers the peer to switch. If you switch CID without changing address, the address links you with fairly high probability anyway, so it doesn't really matter if the peer switches.
The recommendation exists to avoid linkability across a non-migrating change in connection ID.
I don't think that that's particularly useful, and it seems to create a bunch of new problems.
My recollection is what NAME says. I remember discussing that changing CID on both sides allows a flow to be broken up into flowlets, but if the address is the same on both sides, that's a pretty clear signal anyways. I am fine with requiring a change only if the peer's CID and address change.
That is not sufficient because the client could be migrating from domestic wifi to mobile, to train wifi, while the server always sees the IP address of the load balancer.
In this case the LB and the server should be regarded as the same thing, and it's the LB's job to convey that somehow.
FWIW, it helps when you have multiple connections coalesced onto a 5-tuple. An endpoints rotates the sending CIDs of all the connections at once, and that triggers the peer to rotate all of it's sending CIDs at once. Then, it becomes very hard for an observer to track the individual connections.
Tokyo:
That being (I'm closing ).
This was
Change:
The request the sends to the only requires minimal information; see http-usage.  The request that carries the and is sent to the MUST NOT <del> include identifying information unless the ensures that this </del> <ins> include identifying information unless the can trust that this </ins> information is removed by the relay.  A MAY include information only for the in header fields identified by the Connection header field if it trusts the relay to remove these as required by Section 7.6.1 of

Discussion:
The client relies on a very specific form of trust here, though maybe they have other means to ensure compliance, it's trust that operates here.
Comment by NAME How could a client "ensure" that? Couldn't this at best be "unless the Client can trust that [...]"
(OK, edited this so that it only includes one comment, not two mangled together.) The answer here is down to trust, so this comment is right. Will fix.
looks good.
Change:
control, and (b) identifiable for the purposes of blocking the affected subscribers. <ins> 7.1. Best practice privacy today is to mandate client identity protection as is done in EAP-TLS 1.3, EAP-TTLS 1.3, etc.  A client supporting EAP-AKA' FS MUST NOT send its username (or any other permanent identifiers) in cleartext in the Identity Response (or any message used instead of the Identity Response) </ins> 8. This extension of EAP-AKA' shares its attribute space and subtypes

Discussion:
Not sure the attacks actually attacked the smart cards. Changed to "smart card supply chain" in the abstract and intro. This is very much related to zero trust principles. added a sentence about this. Any modern standard track EAP method should provide mandatory client identity protection. Copied the text from EAP-TLS 1.3 Motivation for the chosen curves is missing. Added link to the definition of SUCI encryption in appendix C.3.4. of TS 33.501 Added more text in security consideration on the attacks an attacker can do. Added more text in security consideration on frequent use of ECDHE.
Great! There's one typo but I'll fix it.
Change:
Reference: TBD <del> 7. </del> <ins> 8. </ins>

Discussion:
NAME wdyt?
he usability of the ICE server configuration seem to go far beyond WHIP. Also, in my opinion the way you configure your STUN/TURN servers is slightly outside the scope of core WHIP. But, assuming you want to keep the text: First, you should add references to where the STUN- and TURN server URIs are defined. Second, I believe Link URIs have to be enclosed by . Third, I think the "ice-server" value is misleading. An ICE server is not the same thing as a STUN/TURN server. You don't even have to use ICE in order to support STUN/TURN. Fourth, related to the third issue, perhaps you should use the "urn:ietf:params:whip:" appendix also for the STUN/TURN servers? Fifth, you say that not all webrtc implementations may allow STUN/TURN server re-configuring after the offer has been created. But, does WebRTC even define a mechanism to programmatically configure the servers? If so, please add a reference. If not, please indicate that.
Using WHIP without a valid TURN/STUN server configuration will fail in many cases, so In practice any WHIP service provider will also be providing STUN/TURN services to be used with. WHIP allows sending the STUN/TURN server configuration in the HTTP request in order to not have to manualy configure the configuration manually o the client. Moreover, some WHIP providers may want to restrict the usage of their TURN/STUN server and only provide short lived credentials that are only valid in the context of the WHIP session. The term is taken from the W3C webrtc spec that uses the configuration property when creating the PC. Regarding the and , yes, it is a typo and should be corrected. Regarding the it was originally propossed like that but i was agreed that this could be used to configure other webrtc services and not only WHIP and it could be better to not have the urn be whip-specific WebRTC w3c spec supports reconfiguration of the stun/turn server connection via URL
Won't the WHIP servers have a publicly available IP address in most cases? And, as the WHIP client is the one always establishing the media path, there should be no need for a STUN/TURN server in such cases.

Or? Ok. I suggest adding a note to indicate that. I suggest adding some text and point that out. Thanks! I suggest adding a reference,
Clients may be behind restricted firewalls which block UDP. It is easier to just deploy a TURN server to do TURN over TCP/TLS than implement ICE TCP on the media server (and ICE TLS is not standard anyway). Also, you typically have less TURN servers than media servers, so it is easier to have them allowed by IP on the firewalls. In our case for example, our IPs of the media server pool are dinamic, so we must use TURN server IPs instead. I will add notes for the other comments as suggested
Change:
The list of available paths should be constrained by any requirements or prohibitions the application sets, as well as system policy. <del> 4.1.2.3. </del> <ins> 4.1.3.3. </ins> Differences in possible protocol compositions and options can also provide a branching point in connection establishment.  This allows

Discussion:
Restructure to address Rearrange to include Rendezvous and Environment Discovery text in connection establishment. Remove that previous section. was intended to check the ordering of sections against the other drafts and to merge . I have merged the Rendezvous text into Connection Establishment, but I haven't changed any of the text yet. I am a little concerned about creating an interdependancy in the text between derriving endpoints (name lookup) and the ICE/TURN stuff. More generally, I am not sure what to say about name resolution and proxies (ala ). TOR opens a can of privacy worms for name lookup and racing paths that I am not sure how to address.
Looks good apart from typo!
Having proxies to go through on a system (SOCKS, HTTP Connect, etc) or a set of TOR endpoints requires the implementation to do some nested/recursive work, and pass down endpoints correctly to protocol instances. The implementation document should describe this.
+1
There is already text in 4.1.3.3. Protocol Options. Is that sufficient or do we need more?
Review structure. What fits in pre-establishment. Relation system policy - cached state. Generalizes
Discussed in Singapore, we'll have more structure comments later, but we've done a lot of changes since then.
I like the change, as it makes the process much clearer and reduces the awkwardness of ICE/STUN. To model TOR, SOCKS, or other tunnelling protocols, I would refrain from seeing them as protocol stacks, but treat them as derived paths that only support these stacks. This removes the need for cupeling name resolution to the protocol stack, and looks quite natural to me as these derived paths may be available in the connection cache or need to be established for name resolution anyway before starting the real candidate racing. If we want to do so, it might be easier to talk about paths (that have one or more corresponding local endpoints), derived paths, derived remote endpoints (as result of name resolution on each path) and protocol stacks.
Change:
a physical resource location with any acceptable URI scheme (e.g., file:// http:// https:// ftp://) <del> a URI with "swid:" as the scheme refers to another SWID or CoSWID by the referenced tag's tag-id.  This URI needs to be resolved in the context of the endpoint by software that can lookup other SWID or CoSWID tags.  For example, "swid:2df9de35- 0aff-4a86-ace6-f7dddd1ade4c" references the tag with the tag-id value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c". a URI with "swidpath:" as the scheme, which refers to another software tag via an XPATH query W3C.REC-xpath20-20101214 that matches items in that tag (uri-scheme-swidpath).  This scheme is provided for compatibility with SWID.  This specification does not define how to resolve an XPATH query in the context of CBOR, see uri-scheme-swidpath. </del> <ins> a URI-like expression with "swid:" as the scheme refers to another SWID or CoSWID by the referenced tag's tag-id.  This expression needs to be resolved in the context of the endpoint by software that can lookup other SWID or CoSWID tags.  For example, "swid:2df9de35-0aff-4a86-ace6-f7dddd1ade4c" references the tag with the tag-id value "2df9de35-0aff- 4a86-ace6-f7dddd1ade4c". a URI-like expression with "swidpath:" as the scheme, which refers to another software tag via an XPATH query W3C.REC- xpath20-20101214 that matches items in that tag (uri-scheme- swidpath).  This scheme is provided for compatibility with SWID.  This specification does not define how to resolve an XPATH query in the context of CBOR, see uri-scheme-swidpath. </ins> media (index 10): A hint to the consumer of the link to what target platform the link is applicable to.  This item represents a

Discussion:
Removed IANA registrations for swid and swidpath and updated text to note these are not technically URIs but just expressions using URI syntax.
Change:
is conveyed in the plaintext, represented as described in bstr-repr. <del> PAD = 1* "true" (see CBOR) is padding that may be used to </del> <ins> PAD_2 = 1* "true" (see CBOR) is padding that may be used to </ins> hide the length of the unpadded plaintext Compute KEYSTREAM_2 as in expand, where plaintext_length is the

Discussion:
This is an editorial change.
If there is a risk someone thinks that padding in the messages must be the same we could use PAD2, PAD3, PAD_4.
If I understand correctly, the PAD is to hide the length of the messages. If the three messages share the same PAD length, it is enough for one of the message to have a length known by the attacker, e.g. if EAD_4 is of constant length across all sessions, to leak the length of the PAD, and thus the length of the other messages contents. As such, 3 distinct padding lengths would be strictly better. Otherwise, as the encryptions are distinct (different key streams), I on my side don't see any weird cryptographic interactions that would be possible. (a side question is does the padding in message 2 leads to potential for padding oracles attacks, where the attacker could try to flip a few bytes of the cyphertext and learn some information based on which step of the processing fail. However, that is covered by I guess)
This is an editorial change. I merged the PR and will close this issue. No and yes. SIGMA and EDHOC and TLS 1.3 does not provide confidentiality of the second flight to active attackers (except maybe the signature). In SIGMA and EDHOC and attacker can modify the second flight and gain information. But this attack seems very uninteresting compared to attacks where the attacker modifies message_1.
Change:
The client uses these values to decrypt "ct" using the Open function provided by the AEAD.  Decrypting might produce an error, as follows: <del> 5.3. Plaintext Messages support arbitrary length padding.  Clients and servers MAY pad HTTP messages as needed to hide metadata leakage through ciphertext length. </del> 6. A client interacts with the oblivious proxy resource by constructing

Discussion:
One question we might want to ask (even though I think we have the right answer already) is: should be included in AAD? I also removed the padding text, since we moved that to the bhttp spec.
It's a reasonable question, but I think we can safely assume that a single key can't be used with multiple KEMs.
In principle it might be possible, but I think we should prohibit it.
Change:
This alert was used in some earlier versions of TLS.  It MUST NOT <del> be sent by compliant implementations. </del> <ins> be sent by compliant implementations.  This message is always fatal. </ins> The protocol version the peer has attempted to negotiate is

Discussion:
Expands on NAME improvements. The obsolete alerts were previously fatal and still are. Mark them as such. Also fix one of their names which is missing the "_RESERVED" in the descriptions list.
Change:
transport service across a network, as required by the abstract interface. <del> Connection Group: A set of Connections that share properties and caches.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together.  An application can explicitly define Connection Groups to control caching boundaries, as discussed in groups. </del> Path: Represents an available set of properties that a local system can use to communicate with a remote system, such as routes, addresses, and physical and virtual network interfaces.

Discussion:
This is fully editorial: I'm not sure if the term "Connection Group" is introduced in the right section. There might be no perfect fit but maybe section 2.2 is a bit better? Also I note that the terms "Connection Group" and "Path" do not not show up in any of the figures...
Make this a new subsection, i.e. 4.1.7.
Works - Thank you!