jiebi/CodeConvo huggingface dataset:
Change:
the Initiator and the Responder. As required by RFC7258, IETF protocols need to mitigate pervasive <del> monitoring when possible.  One way to mitigate pervasive monitoring is to use a key exchange that provides forward secrecy.  EDHOC therefore only supports methods with forward secrecy.  To limit the effect of breaches, it is important to limit the use of symmetrical group keys for bootstrapping.  EDHOC therefore strives to make the additional cost of using raw public keys and self-signed certificates as small as possible.  Raw public keys and self-signed certificates are not a replacement for a public key infrastructure but SHOULD be used instead of symmetrical group keys for bootstrapping. </del> <ins> monitoring when possible.  EDHOC therefore only supports methods with ephemeral Diffie-Hellman and provides a KeyUpdate function for lightweight application protocol rekeying with forward secrecy.  As discussed in RFC4949 the term "forward secrecy" is a muddled area. EDHOC provides forward secrecy in the sense that compromise of the private authentication keys does not compromise past session keys, and compromise of a session key does not compromise past session keys. While the KeyUpdate method can be used to meet cryptographic limits and provide partial protection against key leakage, it provides significantly weaker security properties than re-running EDHOC with ephemeral Diffie-Hellman.  Even with frequent use of KeyUpdate, compromise of one session key compromises all future session keys, and an attacker therefore only needs to perform static key exfiltration RFC7624.  Frequently re-running EDHOC with ephemeral Diffie-Hellman forces attackers to perform dynamic key exfiltration instead of static key exfiltration RFC7624.  In the dynamic case, the attacker must have continuous interactions with the collaborator, which is more complicated and has a higher risk profile than the static case. To limit the effect of breaches, it is important to limit the use of symmetrical group keys for bootstrapping.  EDHOC therefore strives to make the additional cost of using raw public keys and self-signed certificates as small as possible.  Raw public keys and self-signed certificates are not a replacement for a public key infrastructure but SHOULD be used instead of symmetrical group keys for bootstrapping. </ins> Compromise of the long-term keys (private signature or static DH keys) does not compromise the security of completed EDHOC exchanges.

Discussion:
Comment by Robert Moskowitz
I think the forward secrecy could use some more text. Right know we are using the definition according to the IETF security dictionary, but as the security dictionary states, a lot of different definitions is used. The draft that the KeyUpdate gives much better security than using a single key, but that the KeyUpdate method gives a lower security level than frequently running ephemeral diffie-hellman
Change:
4.2. In this model, the Attester and Issuer are operated by the same <del> entity that is separate from the Origin, as shown in the figure below. </del> <ins> entity that is separate from the Origin.  The Origin trusts the joint Attester and Issuer to perform attestation and issue Tokens.  Clients interact with the joint Attester and Issuer for attestation and issuance.  This arrangement is shown in the figure below. </ins> This model is useful if an Origin wants to offload attestation and issuance to a trusted entity.  In this model, the Attester and Issuer

Discussion:
Split attesters and issuers are not required for the basic issuance protocol, but we should explain (in a sentence or so) that if you are using a split attester, the client sends the request to the attester, and the attester forwards the request to the issuer if it accepts the client.
For better clarity and consistency, I recommend adding a sequence diagram depicting this model considering the sequence diagrams that outline other models.
Agreed. This would be a good thing to include. I'll take this and add it.
In a split attester/issuer scenario, the issuer needs to authenticate the attester in some way (e.g., TLS client cert). In a combined attester/issuer scenario, the actual protocol might be something proprietary (or covered by an as-yet-unwritten spec) that extends the base issuance protocol, e.g., adding an attestation header, user login cookie, or adding extra challenge/response rounds to confirm identity. If these issues are "in scope" then they should be defined here. If they are "out of scope" then it would be helpful context to reader to describe what is expected to be handled by a proprietary extension.
NAME we discuss these things in the architecture document where deployment models are discussed. But we should mention the impact that different deployment models have on the basic issuance protocol in the -protocol spec.
Change:
zero-rtt-exchange) it also authenticates the handshake using the the Static Secret. [server-finished] <del> Upon receiving the server's messages, the client responds with his </del> <ins> Upon receiving the server's messages, the client responds with its </ins> final flight of messages:

Discussion:
The spec always uses the gender-neutral possessive pronoun "its" for "client", so I think we should definitely fix that occurrence. Also, it seems that throughout the document we try to not use gender-specific pronouns for "attacker". I'm not sure about "their" though, as it looks like we usually try to avoid that by restructuring sentences, but I may be mistaken. We could also refer to multiple attackers?
In technical writing, we should generally use "they" and "their" everywhere when (potentially) referring to a person or persons. ("it" is best for denoting clients/servers) The word "they" gives both gender & quantity neutral language; no assumptions. (this use is older than Shakespeare; it's just underused)
Change:
1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. </del> <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. </ins> 1.2. <ins> draft-05 Prohibit SSL negotiation for backwards compatibility. </ins> draft-04 Remove renegotiation.

Discussion:
A straightforward cleanup of part of the backwards compatibility section. (handles an easy part of issue ) SSL 2.0 backwards compatibility was previously deprecated in TLS 1.2 (2008) and was warned to be "phased out with all due haste". RFC 6176 (2011) prohibits it entirely. It's a section of obsolete complexity still in the draft. Remove it and replace it with a simple "MUST NOT" send or accept. Edit to correct attribution of the "phased out with all due haste" language. Whilst in the TLS 1.2 (2008) spec, it was first introduced in SSL 3 (1996). It has been around for 19 years, not 5.
Dave, can you please post about this to the list?
I have to ask, why not SSL 3 as well?
This is about SSLv2 compatibility needing a different ClientHello format.
I completely agree that similar language should be added for SSL3 as well, however its prohibition RFC is not done yet. SSL2 was just an obvious start. I'll write another PR with the SSL3 prohibition draft language added in. URL
One possible idea if SSL 2.0 ClientHello compatibility is still needed is to max it at TLS 1.2.
There is discussion on list, but just let me say for the record here that I am astonished that this wasn't considered a non-controversial cleanup. The SSL2 hello has been deprecated for 20 years...
Per Brian's suggestion, this PR is now just for the changes with large agreement. Prohibiting all SSL v2 CLIENT-HELLO entirely is now moved to issue .
Per Brian's suggestion, splitting this off of PR . SSL v2 CLIENT-HELLO support requires additional implementation complexity that is an unnecessary risk to maintain support with a 20 year old deprecated negotiation format. Implementations have had notable bugs in handling this in the past. The current status quo expects them to be acceptable for negotiating TLS 1.0-1.2, even though ALL TLS clients are capable of using the SSL v3 version ClientHello if properly configured. Support for this has been optional and deprecated for many years, with the SSL 3 spec noting in 1996 that "The ability to send version 2.0 client hello messages will be phased out with all due haste.

Implementers should make every effort to move forward as quickly as possible." Some implementers would be quite happy to have this prohibited entirely so that their code can finally be scrubbed clean of obsolete SSL 2 junk. Others want to perpetuate backwards compatibility support for EOL clients forever. I argue the former. A decision needs to be made on which path to chose. It will be depressing if it is to be the latter. :/
It is now no longer possible to use SSLv2 hellos with TLS 1.3 (because some extensions are mandatory) so we shouldn't need anythign here.
Change:
The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key. <ins> In addition, the client MAY advise the server at which IP the challenge is provisioned: An IPv4 or IPv6 address which, if given, MUST be included in the set of IP addresses to which the domain name resolves.  If given, the server will connect to that specific IP address instead of arbitrarily choosing an IP from the set of A and AAAA records to which the domain name resolves.  If the field is given but equal to ""peer"", the server MUST treat the field as if it contained the IP address from which the response was received. </ins> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then

Discussion:
This looks fine to me, and consistent with the list discussions. (I have a couple of minor issues, which I filed as .) I am merging this in preference to , which got negative feedback on the list.
The format should be specified more clearly, by reference to a couple of RFCs The "peer" provision seems kind of awkward. For server implementations where the validation is done by a separate entity than the ACME interactions (like ), this means that the challenge no longer has all the information that the validation agent needs to do the validation. I'm inclined to drop it and put the burden on the client.
Change:
Here <del> represents the AES_CM PRF KDF RFC3711 for </del> <ins> represents the AES_CM PRF KDF (see Section 4.3.3 of RFC3711) for </ins> DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM algorithm and AES_256_CM_PRF KDF RFC6188 for DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM algorithm.

Discussion:
This PR responds to IESG review comments from Magnus Westerlund, except for his comments on RED, which I haven't quite figured out how to address yet.
LGTM with nits
Change:
5. SFrame must be integrated with an E2E key management framework to <del> exchange and rotate the keys used for SFrame encryption and/or signing.  The key management framework provides the following functions: </del> <ins> exchange and rotate the keys used for SFrame encryption.  The key management framework provides the following functions: </ins> Provisioning KID/"base_key" mappings to participating clients <del> (optional) Provisioning clients with a list of trusted signing keys </del> Updating the above data as clients join or leave It is up to the application to define a rotation schedule for keys.

Discussion:
The signature mechanism was removed from SFrame some time ago. This PR removes a few remaining references to it.
Seems good but needs rebasing
NAME NAME I think we are ok to merge this PR?
Change:
When a sender receives credit after being blocked, it might be able to send a large amount of data in response, resulting in short-term <del> congestion; see Section 7.7 in QUIC-RECOVERY for a discussion of how </del> <ins> congestion; see Section 7.7 of QUIC-RECOVERY for a discussion of how </ins> a sender can avoid this congestion. 4.3.

Discussion:
to make RFC Editor diffs smaller
These are manual; if only there were a tool... Diffs in the are all very small, and in each case reflects correction of an existing error or slight adjustment to accommodate limitations in XML (in one case); happy to suppy (CI is broken because of URL).
I just uploaded this to a branch on this repository so that a diff is generated in CI (assuming that I have a little more luck in getting a build to stick). The changes should be visible at URL if CI ever passes. Which of course it has not at this point...
Seems to be working occasionally; I fixed a lint problem, and diffs are now at URL
NAME I'd strongly prefer to keep this PR focused on behind-the-scenes tidying, rather than making an editorial wording choice. Beyond keeping the PR focused, doing this piecemeal is going to miss a large number of instances of "see..." because the changes represented here are only where a specific section is called out; you'd do much better to adjust that language consistently after this PR is applied (when you can do a search for and it should consistently show all instances, whether or not there's a section being referenced). If that's sensible to everyone, I think this is ready; tell me if I missed one of the comments.
NAME Fair enough. This LGTM.
Here are the diffs, since tools is failing so badly (I plan to work around that, but that will take some time). URL I've spotted one problem there already, but it does look good so far.
NAME and NAME I have learned something new about kramdown-rfc2629. Cheers.
NAME
NAME and NAME should approveThanks for doing this, recovery LGTM
Change:
HTTP semantics (SEMANTICS) are used for a broad range of services on the Internet.  These semantics have most commonly been used with <del> HTTP/1.1, over a variety of transport and session layers, and with HTTP/2 over TLS.  HTTP/3 supports the same semantics over a new </del> <ins> HTTP/1.1 and HTTP/2.  HTTP/1.1 has been used over a variety of transport and session layers, while HTTP/2 has been used primarily with TLS over TCP.  HTTP/3 supports the same semantics over a new </ins> transport protocol, QUIC. 1.1.

Discussion:
Address multiple editorial comments.
NAME said
NAME said
The text currently says: Transport makes the following addition, in : That might be worth reiterating in HTTP/3.
NAME said
Two separate questions. I'm fine generalizing it to HTTP/1.x. The link between the first two sentences is the fact that HTTP/1.x uses human-readable whitespace-delimited fields, but those attributes make parsing inconsistent; subsequent versions of HTTP/2 went a different direction. If you're talking about the second and third, that could easily be a paragraph split; it's a change of idea under the umbrella of major changes of direction from H1 to H2+.
Change:
5.6. <del> DTLS messages are grouped into a series of message flights, according to the diagrams below. </del> <ins> DTLS handshake messages are grouped into a series of message flights. A flight starts with the handshake message transmission of one peer and ends with the expected response from the other peer.  Table tab- flights contains a complete list of message combinations that consitute flights. </ins> <del> Note: The application data sent by the client is not included in the timeout and retransmission calculation. </del> <ins> Remarks: The HelloRetryRequest shown in (1) is an optional message sent by the server. The ACK message is sent by a client in response to a NewSessionTicket message from the server (as noted in (3)) or sent by a server in response to receipt of flight (2).  In those cases it represent a flight on its own. Below are several example message exchange illustrating the flight concept. </ins> 5.7.

Discussion:
NAME I merged this. Any chance you want to send a PR or do you want me to?
I'm not in a great spot to make a PR at the moment; please go ahead.
I just fixed this in the main branch.
Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" It's 0. I think this example may have had an HRR. Will fix. Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples"
NAME can you take these?
PRs for the example updates are URL URL URL
Fixed
Thanks, this addresses the issues I had raised for this section. (It's perhaps a little janky to have just a box with "Flight" for each one, but I don't have any better ideas, so we should probably roll with it!)
Change:
3.1.2. The pledge MUST use an Implicit Trust Anchor database (see EST <del> RFC7030) to authenticate the cloud registrar service.  The Pledge can be done with pre-loaded trust-anchors that are used to validate the TLS connection.  This can be using a public Web PKI trust anchors using RFC6125 DNS-ID mechanisms, a pinned certification authority, or even a pinned raw public key.  This is a local implementation decision. </del> <ins> RFC7030) to authenticate the cloud registrar service.  In order to make use of a Cloud Registrar, the Pledge MUST be manufactured with pre-loaded trust-anchors that are used to validate the TLS connection.  The TLS connection can be validated using a public Web PKI trust anchors using RFC6125 DNS-ID mechanisms, a pinned certification authority, or even a pinned raw public key.  This is a local implementation decision. </ins> The pledge MUST NOT establish a provisional TLS connection (see BRSKI section 5.1) with the cloud registrar.

Discussion:
The two occurences of lower-case "may" might be clearer as "might". "The Pledge can be done with" ???? "may" or "MAY"? There are a few occurences of "should" and "must" in these sections, and I wondered about "SHOULD" and "MUST".
Change:
Future extensions or additions to the Return Routability Check protocol may define new message types.  Implementations MUST be able <del> to parse and ignore unknown values. </del> <ins> to parse and ignore messages with an unknown "msg_type". </ins> 5.

Discussion:
Signed-off-by: Thomas Fossati
cc NAME
Works for me.
What are the considerations about that select? For me it looks like all "cases" are the same? Do I oversee something?
Maybe the idea of that select is a "future extension". If so, "ignore unknown values" includes, to skip what ever follows, or? Then maybe
Yep, exactly: RRC is not closed (see URL) so the select anticipates extensions that might need a value different from Cookie.
Thanks. WDYT about the extended formulation:
I think the current text is already saying what you propose :-) In the context of the paragraph, there is no "rest of the RRC message" that isn't the "unknown value", so the addition seems redundant to me. NAME WDYT?
Assuming: If is unknown, what is then to be ignored? Maybe:
This is exactly what I wanted the current text to say. Apparently I failed :-) I'll do the suggested tweak.
Change:
may result in a change to media state if it results in connectivity being established. <del> 4.1.10. </del> <ins> 4.1.11. </ins> The addIceCandidate method provides a remote candidate to the ICE Agent, which, if parsed successfully, will be added to the remote

Discussion:
Update of ekr's PR . Details: Initial offers/answers have no candidates Add canTrickle property Add text regarding a=end-of-candidates Clarify dummy/null address/port stuff
lgtm
NAME can you review this before Friday?
I'll try and carefully read this tomorrow morning but I'm running out of time for today. It looked good on my quick skim of it but I want to read it carefully but don't expect to have issues with it.
On this morning's Editor's Call we discussed the topic of what trickle indicators should appear in the SDP. The trickle draft prescribes two indicators: a=ice-options:trickle a=end-of-candidates However, as agreed at the interim, JSEP agents always do trickle and just expose a canTrickle property. Accordingly, the conclusion was to interpret a=ice-options:trickle as "I can do trickle" (this is consistent with half-trickle) and thus JSEP agents always send it, even if canTrickle=false. So, we should insert a=end-of-candidates when gathering is done to mean "I am done trickling". This means that JSEP agents will generate a=ice-options:trickle in response even to offers which do not contain it. However, offerers should already ignore that. As before, it's up to the app to wait for all the candidates before sending the offer if canTrickle=false
Agreed
Sounds good!
Fixed by
Change:
hostname is a parent node, with child nodes for each IP address. Similarly, an implementation that is allowed to connect using multiple interfaces will have a parent node of the tree for the <del> decision between the paths, with a branch for each interface. </del> <ins> decision between the network paths, with a branch for each interface. </ins> The example aggregate connection attempt above can be drawn as a tree by grouping the addresses resolved on the same interface into

Discussion:
After reading , I reviewed the latest text. I'm unsure I want to make changes to Arch/API: I see path as "network path", that is the set of hops through which the packet is forwarded (the local interface being the first local hop, and PvD information/PMTU/etc relating to something non-local). This changes the examples using interface to align with this.
Impl draft, section 4.1.2: "Each node will be summarized by a tuple of three elements: Endpoint, Path, and Protocol. The above example can now be written more succinctly as: 1 [URL, Any, TCP] 1.1 [URL, Wi-Fi, TCP] 1.1.1 [192.0.2.1:80, Wi-Fi, TCP] 1.2 [URL, LTE, TCP] 1.2.1 [192.0.2.1:80, LTE, TCP] 1.2.2 [2001:DB8::1.80, LTE, TCP]" looking at the example I would not call this "Endpoint, Path, and Protocol" but "Remote Endpoint, Local Endpoint or interface, and Protocol". Not sure we have defined the term Path well but I would consider a path to consists of both the local and remote endpoint plus optionally maybe even some more information about the path characteristics that might be known for this endpoint pair.
Yeah, it is "remote endpoint", "interface/local endpoint", and "protocol".
note that the wording needs to be fix at least in a few more places, so whoever puts the PR in should probably reach for the word path and ensure it's used correctly...
especially 4.1.3.2. (Alternate Paths) wouldn't fit that well anymore and would probably need some rewriting...
Change:
sense that they cannot be linked back to the previous session where they were issued. <del> The Internet performance company Cloudflare has already implemented server-side support for an initial version of the Privacy Pass protocol PPSRV, and a client-side implementations is also available PPEXT.  More recently, a number of applications have been built upon the protocol, or upon slight variants of it; see: TRUST, OpenPrivacy, PrivateStorage.  The protocol can be instantiated using a cryptographic primitive known as a verifiable oblivious pseudorandom function (VOPRF) for implementing the authorization mechanism.  Such VOPRF protocols can be implemented over prime-order groups, and constructions are currently being drafted in separate standardization processes I-D.irtf-cfrg-voprf. </del> The Privacy Pass protocol is split into three stages.  The first stage, initialisation, produces the global server configuration that is broadcast to (and stored by) all clients.  The second stage, the

Discussion:
Rename IssuanceMessage and RedemptionMessage to IssuanceRequest and RedemptionRequest, respectively. Rename SecretKey to PrivateKey. Change to an integer value, rather than opaque vector. I also removed company-specific information, which is not really relevant for the document. (That's useful information, but not appropriate for a standards document, I think.) cc NAME NAME