jiebi/CodeConvo huggingface dataset:
Code change:
This PR tracks changes under discussion with the RFC editor. (Note that I haven't renamed the file to the RFC number, because that hasn't been done in other drafts in this repo.) When AUTH48 completes, I will add the commit moving this draft to the archive and merge it.

Related discussion:
text: 2.1. <del> The ORIGIN frame has a nearly identical layout to that used in HTTP/2, restated here for clarity.  The ORIGIN frame type is 0xc (decimal 12) as in HTTP/2.  The payload contains zero or more instances of the Origin-Entry field. </del> <ins> The ORIGIN frame has a layout that is nearly identical to the layout used in HTTP/2; the information is restated here for clarity.  The ORIGIN frame type is 0x0c (decimal 12), as in HTTP/2.  The payload contains zero or more instances of the Origin-Entry field. </ins> An Origin-Entry is a length-delimited string.  Specifically, it contains two fields:
Code change:
This PR tracks changes under discussion with the RFC editor. (Note that I haven't renamed the file to the RFC number, because that hasn't been done in other drafts in this repo.) When AUTH48 completes, I will add the commit moving this draft to the archive and merge it.

Related discussion:
text: 3. This document introduces no new security considerations beyond those <del> discussed in ORIGIN and HTTP3. </del> <ins> discussed in ORIGIN and RFC9114. </ins> 4. <del> This document registers a frame type in the "HTTP/3 Frame Type" registry (HTTP3). This allocation lists a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </del> <ins> This document registers a frame type in the "HTTP/3 Frame Types" registry defined by RFC9114, located at <https://www.iana.org/assignments/http3-parameters/>. </ins>
Code change:
think its a case of s/an/and
The abstract says is it really , is it some other phrasing a little more technically correct?
LGTM thanks

Related discussion:
text: Abstract <del> This document defines an HTTP Proxy-Status Parameter that contains a list of aliases and canonical names received over DNS when establishing a connection to the next hop. </del> <ins> This document defines the "next-hop-aliases" HTTP Proxy-Status Parameter.  This parameter carries the list of aliases and canonical names a proxy received during DNS resolution as part establishing a connection to the next hop. </ins> 1.
Code change:
think its a case of s/an/and
The abstract says is it really , is it some other phrasing a little more technically correct?
LGTM thanks

Related discussion:
text: The "next-hop-aliases" parameter's value is a String STRUCTURED- FIELDS that contains one or more DNS names in a comma-separated list. <del> The items in the list include all alias names an canonical names </del> <ins> The items in the list include all alias names and canonical names </ins> received in CNAME records DNS during the course of resolving the next hop's hostname using DNS, not including the original requested hostname itself.  The names SHOULD appear in the order in which they
Code change:
ballot position feedback
[x] §6.1 Recommend adding cautionary language about the capabilities of an adversary like those stated in Peter’s SECDIR review [x] Appendix A, typo[x] Section 6.5, e.g.

Related discussion:
text: fields, from certain kinds of corruption. Integrity fields are not intended to be a general protection against <del> malicious tampering with HTTP messages.  This can be achieved by combining it with other approaches such as transport-layer security or digital signatures (for example, HTTP Message Signatures SIGNATURES). </del> <ins> malicious tampering with HTTP messages.  In the absence of additional security mechanisms, an on-path, malicious actor can remove or recalculate and substitute a digest value.  This attack can be mitigated by combining mechanisms described in this document with other approaches such as transport-layer security or digital signatures (for example, HTTP Message Signatures SIGNATURES). </ins> 6.2.
Code change:
ballot position feedback
[x] §6.1 Recommend adding cautionary language about the capabilities of an adversary like those stated in Peter’s SECDIR review [x] Appendix A, typo[x] Section 6.5, e.g.

Related discussion:
text: content coding defined in RFC8188. Since it is possible for there to be variation within content coding, <del> the checksum conveyed by the integrity field cannot be used to provide a proof of integrity "at rest" unless the whole (e.g., encoded) content is persisted. </del> <ins> the checksum conveyed by the integrity fields cannot be used to provide a proof of integrity "at rest" unless the whole content is persisted. </ins> 6.6.
Code change:
SGTM. Feel free to merge if you are sure we won't need this. Kind regards, R
John Scudder raised during IESG review: algorithms that use a reserved token value that cannot be expressed in Structured Fields". This is a well-formed sentence but I have no idea what it means. I made a desultory attempt to suss it out by searching the document for "token" and this was the only occurrence. If people who will actually be making use of the registry can be expected to make sense of it, then feel free to disregard my comment, of course. This reminded me at some point, I'd sketched out a design for the "Hash Algorithms for HTTP Digest Fields" registry that worked differently with what we ended up with now. In that design, it would have been possible to register an algorithm in the table under some friendly name and then separately register some Structured-Fields identifier that it related to. This would have made it possible to register an algorithm but reserve it from being used, in order to (for example) try and maintain some parity with old digest. Needless to say, the original sketch design had flaws and we didn't go that way. Instead, the registry requires entries to be identified using a Structured Fields key, which makes the idea of a reserved status due to a key that can't be used rather strange. TL;DR lets remove the "reserved" status because it isn't used by anything already and doesn't have much logic behind how it would be used in future.
We need to evaluate and possibly pare down / adjust the flags in the frame, based upon real-world use cases. See Kazuho's evaluation: URL
I agree the need for evaluation. OTOH, I do not think we should pare down / adjust flags, since real-world use cases could change as time evolves. The way it is defined now represents the cache state as-is and I believe that it would be most resilient in the long term.
OK.

Related discussion:
text: "insecure" - for insecure algorithms, <del> "reserved" - for algorithms that use a reserved token value that cannot be expressed in Structured Fields </del> Description: a short description of the algorithm Reference(s): pointer(s) to the primary document(s) defining the <del> technical details of the algorithm, and optionally the key </del> <ins> Algorithm Key and technical details of the algorithm </ins> When reviewing registration requests, the designated expert(s) should pay attention to the requested status.  The status value should
Code change:
Roman Danyliw made some comments during IESG review related to receiver validation behaviour. RFC 3230 was quite relaxed about stating receiver requirements and we've followed suit by carrying over that normative langauge almost verbatim for Content-Digest and Repr-Digest. The intention has always been that applications are responsible for deciding what integrity checks are important and what validation failure means to them. Roman suggests that we make this intention more concrete by adding explicit statements. This seems like a good idea and I'll prepare a PR to this effect. Its a restatement of intent but it is new normative language, so I'll cross post to the HTTP WG list for any additional input.

Related discussion:
text: capabilities.  Such an approach could support transitions away from weaker algorithms (see sec-agility). <del> A recipient MAY ignore any or all digests.  This allows the recipient to choose which hashing algorithm(s) to use for validation instead of verifying every digest. </del> <ins> A recipient MAY ignore any or all digests.  Application-specific behavior or local policy MAY set additional constraints on the processing and validation practices of the conveyed digests.  For example, validation of a subset of received digests is one approach to protection against resource exhaustion; see resource-exhaustion. </ins> A sender MAY send a digest without knowing whether the recipient supports a given hashing algorithm, or even knowing that the
Code change:
Apologies in advance.
No apology needed. I stuttered over this same sentence yesterday when fixing an unrelated nit. I almost changed it then but didn't want to mix concerns. Given that somebody else has raised a comment and provided an alternative I agree with, leads me to believe its worth fixing. Thanks.
Much cleaner, +1

Related discussion:
text: unsupported-algorithm.  It is not a protocol error if preferences are ignored.  Applications that use Integrity fields and Integrity preferences can define expectations or constraints that operate in <del> addition to this specification.  How to deal with ignored preferences is a scenario that should be considered. </del> <ins> addition to this specification.  Ignored preferences are an application-specific concern. </ins> "Want-Content-Digest" and "Want-Repr-Digest" are of type "Dictionary" where each:
Code change:
Update example domain names to avoid "example-URL" and too-long lines
Some examples use ; IDNITS dings you for not using . Should probably use something like .
The examples in 2.1 have lines that are too long. Because it's caused by , which is a String, I think your options are: Shorten the strings Use RFC 8792 line wrapping

Related discussion:
text: This indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the names <del> "tracker.example.com" and "service1.example-cdn.com" in the DNS </del> <ins> "tracker.example.com" and "service1.example.com" in the DNS </ins> resolution chain.  Note that while this example includes both the "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".
Code change:
Update example domain names to avoid "example-URL" and too-long lines
Some examples use ; IDNITS dings you for not using . Should probably use something like .
The examples in 2.1 have lines that are too long. Because it's caused by , which is a String, I think your options are: Shorten the strings Use RFC 8792 line wrapping

Related discussion:
text: Unreserved Characters (RFC3986, Section 2.3) MUST be percent-encoded as defined in RFC3986, Section 2.1. <del> For example, consider the DNS name "name,with,commas.example.com". This name would be encoded within a "next-hop-aliases" parameter as </del> <ins> For example, consider the DNS name "comma,name.example.com".  This name would be encoded within a "next-hop-aliases" parameter as </ins> follows: It is also possible for a DNS name to include a period character
Code change:
In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this

Related discussion:
text: the context is set to the structure described in <del> the exporter output length is set to 32 bytes (see output) </del> <ins> the exporter output length is set to 48 bytes (see output) </ins> 3.1.
Code change:
In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this

Related discussion:
text: 3.2. <del> The output of the exporter is a 32-byte symmetric key.  That symmetric key is then used as nonce which can be signed using the client's chosen asymmetric private key.  The resulting signature is then transmitted to the server using the Authorization field. </del> <ins> The key exporter output is 48 bytes long.  Of those, the first 32 bytes are input to the signature and the next 16 bytes are sent alongside the signature.  This allows the recipient to confirm that the exporter produces the right values.  This is described in fig- output: The key exporter context contains the following fields: </ins> 4.
Code change:
In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this

Related discussion:
text: <<https://www.iana.org/assignments/tls-parameters/tls- parameters.xhtml#tls-signaturescheme>>. <ins> 4.4. The REQUIRED "v" (verification) parameter is a byte sequence that specifies the verification that the user agent provides to attest to possessing the key exporter output.  This avoids issues with signature schemes where certain keys can generate signatures that are valid for multiple inputs (see SEEMS-LEGIT). </ins> For example, the key ID "basement" authenticating using Ed25519 ED25519 could produce the following header field (lines are folded to fit):
Code change:
In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this

Related discussion:
text: of 401 (Unauthorized).  Such authentication failures can be caused for example by: * absence of the Authorization field * failure to parse the Authorization field * use of the Signature authentication <del> scheme with an unknown key ID * failure to validate the signature. </del> <ins> scheme with an unknown key ID * failure to validate the verification parameter * failure to validate the signature. </ins> Such servers MUST also ensure that the timing of their request handling does not leak any information.  This can be accomplished by
Code change:
In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this

Related discussion:
text: client, then inform the upstream HTTP server of the presence of valid authentication. <del> The intermediary can export the nonce (see compute-proof}), and forward it to the upstream HTTP server, then the upstream server performs the validation. </del> <ins> The intermediary can export the nonce and verification (see compute-proof}), and forward it to the upstream HTTP server, then the upstream server performs the validation. </ins> The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document.
Code change:
From Ilari Liusvaara on the :
I think that I might disagree with Ilari here for this application. Key separation is probably a better model to employ here, though as soon as someone even hints that they might want to share client certificate keys and these keys then this sort of protection probably makes sense.
Briefly mentioned this issue at IETF 116, but did not have time for questions so we asked folks who care to comment on the issue.
Thinking about this some more, prepending a fixed string to the nonce before signing it sounds like it would be pretty cheap and would remove a class of issues - I'm inclined to do that. I'll write up a PR.
OK wrote up to address this

Related discussion:
text: The key exporter context contains the following fields: <ins> 3.3. Once the nonce has been extracted from the key exporter output (see output), it is prefixed with static data before being signed to mitigate issues caused by key reuse.  The signature is computed over the concatenation of: A string that consists of octet 32 (0x20) repeated 64 times The context string "HTTP Signature Authentication" A single 0 byte which serves as a separator The nonce extracted from the key exporter output (see output) For example, if the nonce has all its 32 bytes set to 01, the content covered by the signature (in hexadecimal format) would be: This constructions mirrors that of the TLS 1.3 CertificateVerify message defined in TLS. The resulting signature is then transmitted to the server using the "p" Parameter (see parameter-p). </ins> 4. This specification defines the following authentication parameters.
Code change:
During the SEC AD review, a DISCUSS was raised about the current status values. This change modifies the values to better align with Signatures. The guidance for registration and/or usage of an algorithm based on the status is not affected.

Related discussion:
text: Each algorithm has a status field, which is intended to provide an aid to implementation selection. <del> Algorithms with a status value of "standard" are suitable for many </del> <ins> Algorithms with a status value of "Active" are suitable for many </ins> purposes and it is RECOMMENDED that applications use these algorithms.  These can be used in adversarial situations where hash functions might need to provide resistance to collision, first- preimage and second-preimage attacks.  For adversarial situations, <del> selecting which of the "standard" algorithms are acceptable will depend on the level of protection the circumstances demand.  More </del> <ins> selecting which of the "Active" algorithms are acceptable will depend on the level of protection the circumstances demand.  More </ins> considerations are presented in sec-agility. <del> Algorithms with a status value of "insecure" either provide none of </del> <ins> Algorithms with a status value of "Deprecated" either provide none of </ins> these properties, or are known to be weak (see NO-MD5 and NO-SHA). These algorithms MAY be used to preserve integrity against corruption, but MUST NOT be used in a potentially adversarial
Code change:
During the SEC AD review, a DISCUSS was raised about the current status values. This change modifies the values to better align with Signatures. The guidance for registration and/or usage of an algorithm based on the status is not affected.

Related discussion:
text: Such applications are not exempt from the requirements in this section.  Furthermore, applications without such legacy or history ought to follow the guidance for using algorithms with the status <del> value "standard". </del> <ins> value "Active". </ins> Discussion of algorithm agility is presented in sec-agility.
Code change:
During the SEC AD review, a DISCUSS was raised about the current status values. This change modifies the values to better align with Signatures. The guidance for registration and/or usage of an algorithm based on the status is not affected.

Related discussion:
text: Status: the status of the algorithm.  The options are: <del> "standard" - for standardized algorithms without known problems, </del> <ins> "Active" - for algorithms without known problems, </ins> <del> "provisional" - for non-standard or unproven algorithms, </del> <ins> "Provisional" - for unproven algorithms, </ins> <del> "insecure" - for insecure algorithms, </del> <ins> "Deprecated" - for deprecated or insecure algorithms, </ins> Description: a short description of the algorithm