jiebi/CodeConvo huggingface dataset:
Change:
explicit in both cases. Retry (Section 17.2.5 of QUIC-TRANSPORT) and Version Negotiation <del> (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted or protected in any way.  For other kinds of packets, version 1 of QUIC cryptographically obfuscates other information in the packet headers: </del> <ins> (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted.  Retry packets are (forgibly) integrity protected.  Transport parameters are used authenticate the contents of Retry packets later in the handshake.  For other kinds of packets, version 1 of QUIC cryptographically protects other information in the packet headers: </ins> packet number: All packets except Version Negotiation and Retry packets have an associated packet number; however, this packet

Discussion:
From NAME review.
This PR now as well.
cryptographically obfuscates An odd term. I see obfuscation to be non-cryptographic and cryptographic transformation to not be as weak as to be seen as obfuscation (but as encryption or secure hashing)
I replied by mail to Paul and explained that the header protection is kind of weak, so cryptographically protected might be too strong and this was his reply: Maybe the only thing is finding a better term for “cryptographically obfuscates”? I understand your reasoning but I still feel a little that this is doing a disservice to “cryptography”. But it was a comment, so I will leave it up to the authors. But maybe we can find a better term...?
Also a related comment on the same section from Eric Vyncke:
Note that PR is also editing this same part of the text.
I would say "protects" instead of "obfuscates". We have an analysis to support this claim (now cited in RFC 9001), we don't need to hedge. We used to be less certain (we did basically just invent this off the cuff at an interim meeting), but we're far more confident in stronger claims now.
Section 1 states: No information in the protocol header, even that which can be inspected, is mutable by the network. This is enforced through integrity protection of the wire image [WIRE-IMAGE]. Section 2.1 states: Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or protected in any way. Do these two statements conflict: re protection?
retry packets are actually protected by the Retry Integrity Tag. However not sure about version negotiations...?
The text in section 2.1. is already covered by issue and fixed by PR respectively. However, the text in section 1 needs fixing as well as VN packets are not really protected...
Retry and VN packets “are not encrypted or protected in any way.” While this is made clear later in the document, it would be good to way that Retry packets are (forgibly) integrity-protected and that QUIC TPs later authenticate most of the contents of these packets.
Change:
used to carry this value in the message However, the nonce value could be determined by the application and the value determined from elsewhere. <del> This item is optional and can be absent. </del> <ins> This option does not need to be specified and is set to nil in that case </ins> This contains other information that is defined by the protocol. <del> This item is optional and can be absent. </del> <ins> This option does not need to be specified and is set to nil in that case </ins> This field holds information about party V.  The content of the structure are the same as for the PartyUInfo but for partyV.

Discussion:
We change the title of the document Implement the suggested change from Carsten that we put nils in to unused elements in the ParytInfo structure. I was a bit more complete than the original suggestion but it is probably simpler to get right that way.
It may be better to use the CBOR tag 24 rather than a bstr wrapper for the protected attributes field. The major question that needs to be addressed is how this is treated by existing parsers - will they try and decode it anyway or will the wait to decode them later. It is going to be required that they are both decode later and immutable to changes if they run through an intermediary which will decode, modify and re-encode any of the top level information. I don't believe that there is any benefits to using this rather than bstr for the payload field on signatures and macs since they could be any data type inside rather than a fixed one.
Did not correctly read the spec.
Change:
and MAY be more powerful.  The means for the RS to determine the resource reference are out of scope of this specification, but some dynamic methods are discussed in I-D.draft-ietf-gnap-resource- <del> servers.  The content of the resource handle is opaque to the client instance. </del> <ins> servers.  The content of the resource reference is opaque to the client instance. </ins> The client instance then makes a request to the "as_uri" as described in request, with the value of "access" as one of the members of the

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: b88d66c00c5d10b7eacc0beb4dd928bbb94470a9 Inspect the deploy log: Browse the preview:
Good catch, thanks!
Change:
monotonically increasing integers. Like the nonce approach, this allows associating a "rough" epoch <del> without requiring a reliable clock or time synchronization in order to generate or appraise the freshness of Evidence or Attestation Results.  Only the Handle Distributor requires access to a clock so it can periodically send new epoch handles. </del> <ins> without requiring a trustworthy clock or time synchronization in order to generate or appraise the freshness of Evidence or Attestation Results.  Only the Handle Distributor requires access to a clock so it can periodically send new epoch handles. </ins> The most recent handle is included in the produced Evidence or Attestation Results, and the appraising entity can compare the handle

Discussion:
Signed-off-by: Dave Thaler
At the IETF 110 meeting, Brendan Moran asked why local clocks are a problem since even MCUs have them. Currently we have text in the doc like... in the nonce section: in the handles section: I answered this by saying in the TEE use case for example, attesting the TEE needs a trusted clock, and having a trusted clock is not common. Brendan suggested clarifying the clock text.
Isn't it synchronized clocks that are the requirement? When you say "trusted clocks", do you mean, I can trust that they are securely synchronized? (Or that I can trust that Cesium still has that frequency, and that the laws of physics haven't been altered?)
I mean a clock for which code outside the TEE cannot tamper with. Whether it's synchronized or not is not about whether the clock itself is trusted. If a TEE wants to know how much time has passed since a previous event, and it has to ask the REE, and the REE can lie, then that clock is not trusted by the TEE.
Add text to TEE section about how it needs a local clock, and then add to the example involving nonces.
Change:
5.3. <ins> At several points in the protocol, it is necessary for the server to determine whether two JWK objects represent the same key.  In performing these checks, the server MUST consider two JWKs to match if and only if they have the identical values in all fields included in the computation of a JWK thumbprint for that key.  That is, the keys must have the same "kty" value and contain identical values in the fields used in the computation of a JWK thumbprint for that key type: "RSA": "n", "e" "EC": "crv", "x", "y" Note that this comparison is equivalent to computing the JWK thumbprints of the two keys and comparing thumbprints.  The only difference is that there is no requirement for a hash computation (and thus it is independent of the choice of hash function) and no risk of hash collision. 5.4. </ins> It is common in deployment for the entity terminating TLS for HTTPS to be different from the entity operating the logical HTTPS server, with a "request routing" layer in the middle.  For example, an ACME

Discussion:
As discussed (too ambiguously) at IETF 96, this refactor uses two nested JWS objects instead of one parallel JWS object. This preserves the pattern that every ACME message sent by the client is signed by exactly one account key, and saves clients from having to search through multiple signatures in the verification process.
Looking at the current mechanism in a little more detail, I have a few concerns with the parallel-signature approach that's there now: It's not clear which signature is by the old key and which is by the new key, and the new key doesn't sign over the old key. Both signatures have to include the parameter, so this request burns two nonces unnecessarily The server's JWS checking code now has to switch between validating one signature and two Lots of JWS implementations don't support multiple signatures If not for this, we could require the flattened JSON serialization You need a lot of duplication to deal with the copy/paste attacks (cf. ). (On the other hand, I like that both signatures cover the parameter; reduces replayability.) I would propose that we change the signatures from parallel back to serial, as illustrated below. It would cost a little bit of payload bloat (due to another layer of base64url encoding), but I think the benefits in terms of conceptual simplicity would be worth it.
Just noticed that if we keep to one signature per object, you can do nice stuff like this on the server:
Change:
JWS objects sent in ACME requests MUST meet the following additional criteria: <ins> The JWS MUST be in the Flattened JSON Serialization </ins> The JWS MUST NOT have the value "none" in its "alg" field <del> The JWS MUST NOT have multiple signatures. </del> <ins> The JWS MUST NOT have multiple signatures The JWS Unencoded Payload Option RFC7797 MUST NOT be used The JWS Unprotected Header RFC7515 MUST NOT be used </ins> The JWS MUST NOT have a Message Authentication Code (MAC)-based algorithm in its "alg" field <ins> The JWS The JWS Payload MUST NOT be detached </ins> The JWS Protected Header MUST include the following fields: "alg" (Algorithm)

Discussion:
This is my attempt to find a quick way out of this content-type mess. Replaces and
This also looks good to me, thanks for drafting it!
+1 - This looks like a low complexity path forward that resolves ambiguity.
Change:
handles act as shared secrets, though they can be combined with a requirement to provide proof of a key as well. <del> 7. </del> <ins> 8. </ins> [[ TBD: There are a lot of privacy considerations to add. ]]

Discussion:
Deploy Preview for gnap-resource-servers-editors-draft ready! Explore the source changes: 94d11a4362aaea79f357583969d87ec4955655a9 Inspect the deploy log: Browse the preview:
Change:
for equality and changes behavior based on the result can be used as an oracle to learn the client's SNI. <del> 10.10.3. </del> <ins> 10.11.3. </ins> This attack aims to leak information about secret parts of the encrypted ClientHello by adding attacker-controlled parameters and

Discussion:
One of the motivations for encrypting HRR in was the leaks from cookie values. If we don't go with such a construction (which seems likely) and instead do or , cookies will be in the clear. That means it is instead on the backend servers to construct cookie values without leaking information. This PR provides security considerations to that effect. Unfortunately the requirements on backend servers within a Split Mode deployment are a bit onerous. I suspect, in practice, the answer is that Split Mode deployments cannot even use cookies on the backend server. Between HRRs being rare and stateless HRR being unnecessary over TCP or QUIC, that's hopefully fine. (Note this is different from , which was about the client-facing server being stateless. This applies if the backend server is stateless.)
Change:
accessible for inspection, it becomes quite difficult for the infrastructure to suspect anything. <del> 6. </del> <ins> 3.5.2. It is frequently the case that Do53 resolvers announced by home networks are difficult to upgrade to support encrypted operation.  In such cases it is possible that the only option for encrypted operation is to refer to a separate globally-addressed encrypted DNS resolver, somewhere upstream.  Other networks may choose deploy their encrypted DNS resolver away from the local network, for other reasons. The use of an upstream resolver can mean the loss of local knowledge, such as the ability to respond to queries for locally-relevant names. Solutions should consider how to guide clients when to direct their queries to the local Do53.  For example this could be through pre- emptive communication ("if you ever need to query *.example.com, use your local Do53"), or reactively ("I don't know the answer to that, but your local Do53 should know"). 3.5.3. In cases where the local network has designated a Do53 resolver on the public Internet, this resolver may designate its own or another public encrypted DNS service.  Since public IP addresses may appear in TLS certificates, solutions may use this as one way to validate that the designated encrypted resolver is legitimately associated with the original Do53. 3.6. In cases where the designation is delivered over an authenticated and encrypted channel, such as when one encrypted DNS resolver designates another, one form of attack is removed.  Specifically, clients may be more confident that the received designation was actually sent by the designator.  Clients may take this into account when deciding whether to follow the designation. 4. </ins> Encrypted (and authenticated) DNS improves the privacy and security of DNS queries and answers in the presence of malicious attackers.

Discussion:
This PR simplifies further by removing any mention of properties of the encrypted resolvers, or properties of the relationship between the Do53 and the encrypted resolver. It now purely focusses on the ability of an untrusted network or resolver to designate other encrypted resolvers. This is an assertion that the encrypted resolver is safe and appropriate to use, but little else. Clients will of course make their own decisions about whether to use designated resolvers or not. Other drafts will look at trusted networks, and communicating information that can be useful to clients as part of the untrusted decision-making.
comments
comments on the draft02
It was pointed out that this should be limited to IETF-standardised encrypted DNS protocols rather than potentially including DNSCrypt and being very open-ended.
Change:
it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. <del> 4.5.1. </del> <ins> 4.4.1. </ins> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently

Discussion:
Although more complex, the three-pass algorithm seems strictly better.
I like it, but there is some imprecision in the text. I would like to see something about detecting corruption, probably in the load balancer actions.
Change:
specific to be generally useful. A configuration for a DNS server that allows it to provide <del> different answers depending on attributes of the query, such as </del> <ins> different responses depending on attributes of the query, such as </ins> for "split DNS".  Typically, views differ by the source IP address of a query, but can also be based on the destination IP address, the type of query (such as AXFR), whether it is recursive, and so

Discussion:
Thanks the authors for their work in making this draft. I'm going through and I noticed that the term "answer" (45 occurrences) and "response" (47 occurrences) are used interchangeably in the text. I am OK with that, but they should be explicitly defined IMHO, to avoid confusion. E.g.: if I: ` Is the response the entire DNS-layer packet(s), with all the RRs in it? (including flags,etc) Is an answer each line in both ANSWER and AUTHORITY section? Maybe this is clear to many ppl, but it would be nice to write it down. thanks
I do not believe that we have used these terms "interchangeably", since they're not. Some responses are answers and all answers are responses. Some answers contain an Answer Section and some (negative answers, for instance) do not. If that isn't clear, we perhaps ought to add text similar to that, though I thought we had some discussion of this. I didn't see it while looking on my phone just now, however. A
I have opened PR to fix the places where I think we are really talking about responses, not answers.
I think given how late this is in the draft, I'd like to suggest just adding a new bit of text rather than changing the terms, because the WG has been over this ground some. I think it'll be easier to get WG agreement on some text describing the differences without trying to pick each case. Dunno where to put it -- probably intro or something like that -- but here's a suggestion: This document is sometimes unclear on the terms "response" and "answer". The lack of clarity is partly because the DNS specifications themselves use the terms ambiguously. In general, a response is any DNS message with the QR bit set (see [forward reference here]). An answer is any response that attempts actually to answer the question posed in the corresponding query message. Not all answers are authoritative (see [forward reference here]). Some answers contain an Answer Section (see [xref?]), but not all do (such as a negative answer, [forward reference]). Some other responses are not an answer at all, such as an error response. Sorry not to submit this in the usual and proper githubby way, but I'm on vacation and jamming this in.
Closed with , but might be reopened during IESG review if needed.
Change:
is a JWS object whose JSON payload contains the certificate to be revoked: <del> The certificate to be revoked, in the Base64url-encoded version of </del> <ins> The certificate to be revoked, in the base64url-encoded version of </ins> the DER format.  (Note: This field uses the same modified Base64 encoding rules used elsewhere in this document, so it is different from PEM.)

Discussion:
The current draft stipulates Base64 encoding without padding in relation to JSON data. It is unclear whether omitting the padding characters also applies to the Base64url encoding of key authorization resources (which are not JSON objects). To avoid ambiguity with regards to the encoding of the key authorization string (with padding / without padding) either specify "Base64url Encoding" in the terminology section or change the wording of the aforementioned provision so it is clear that the RFC7515 variant applies to any Base64 encoding throughout the spec. Reference: URL
Data for the discussion: boulder uses Base64url without padding (a.k.a. ) everywhere. (The DNS challenge deployed to boulder's staging instance was buggy, has been fixed in master, and is going to be deployed to again Real Soon Now)
Change:
the RPI down to three bytes or less removes much of the pressure to optimize this any further I-D.ietf-anima-autonomic-control-plane. <del> The earlier examples are more extensive to make sure that the process is clear, while later examples are more concise. </del> <ins> Throughout the following subsections, the examples are described in more details in the first subsections, and more concisely in the later ones. </ins> <del> The uses cases are delineated based on the following requirements: </del> <ins> The uses cases are delineated based on the following IPV6 and RPL mandates: </ins> The RPI has to be in every packet that traverses the LLN.

Discussion:
This covers the text from the beginning up to Section 7.2.1. These were reviewed with Pascal on March 26th. I will continue my review from Section 7.2.2 forward. More trivial editorial suggestions to follow, as well.
Many thanks for these fixs.
Change:
to the clients within a group and can only be used if the "external_senders" extension is present in the group's GroupContext. <ins> The other case, indicated by a "new_member_proposal" SenderType is useful when existing members of the group can independently authorize the addition of an MLS client proposing it be added to the group. External proposals which are not authorized are considered invalid. </ins> An external proposal MUST be sent as an MLSPlaintext object, since the sender will not have the keys necessary to construct an MLSCiphertext object.

Discussion:
Add new newproposalmember SenderType and rename newmember to newcommit_member. This restores the External Proposal Add functionality which was present in the protocol for some years but clarifies how the authorization and signing takes place in this case.
Interim 2022-06-02: Could punt to extensions, but this is partly just because we moved a little too fast on the removal No objections to reverting Once conflicts and comments resolved, good to merge
LGTM, though would still prefer etc. One minor suggestion to lock down the content.
Change:
handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just closing the connection by sending a "close_notify" is more <del> appropriate.  This alert SHOULD be followed by a "close_notify". This alert generally has AlertLevel=warning. </del> <ins> appropriate.  This alert MUST be followed by a "close_notify". This alert generally has AlertLevel=warning.  Receiving implementations should continue to read data from the peer until a "close_notify" is received, though they MAY log or otherwise record them. </ins> Either party MAY initiate a close of its write side of the connection <del> by sending a "close_notify" alert.  Any data received after a closure alert has been received MUST be ignored.  If a transport-level close is received prior to a "close_notify", the receiver cannot know that all the data that was sent has been received. </del> <ins> by sending a "close_notify" alert.  Any data received after a "close_notify" alert has been received MUST be ignored.  If a transport-level close is received prior to a "close_notify", the receiver cannot know that all the data that was sent has been received. </ins> Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert.

Discussion:
The new CFRG curves will probably have different point formats.
This was decided and will be handled as part of import