jiebi/CodeConvo huggingface dataset:
Code change:
some other appropriate value e.g. according to the type and status of the primary document <del> in which the algorithm is defined; "deprecated" when the algorithm is insecure or otherwise undesirable; "reserved" when Digest algorithm references a reserved token value </del> <ins> in which the algorithm is defined; "insecure" when the algorithm is insecure; "reserved" when Digest algorithm references a reserved token value </ins> Description: the description of the digest-algorithm and its encoding

Related discussion:
text: Thanks, nice solution.
The latest draft of the Digest Fields RFC [0] deprecates all non-cryptographically secure algorithms (notably, MD5 and CRC32c). Given that the RFC is "not intended to be a general protection against malicious tampering with HTTP messages," I'd like to propose not deprecating at least these two algorithms, or changing "deprecated digest algorithms MUST NOT be used" to "should be used with caution" or similar. CRC32c is a very useful algorithm because it is composable (crc(A+B) == combine(crc(A), crc(B))). See [1] for an explainer and [2] for an implementation of combine() in zlib. MD5 is ubiquitous. AWS S3 and Google Cloud Storage both use it (see [3], which has similar syntax to this RFC except that the crc32c is base64 instead of hex). [0] URL [1] URL [2] URL [3] URL Sorry if this is the wrong forum. I saw some links from the w3c mailing list archive that looked like more discussions were happening here than there.
Hi NAME this is the right place, thanks for opening the issue. Do you have a use case where you'd like to use these algorithms with the Digest or Content-Digest header? They are pretty old and pretty bad at their intended purpose - what caution can we offer? The statement comes from URL, which is really about making it clear that applications do care about protecting messages also need to apply signatures that protect HTTP header or trailer sections. Otherwise, an attacker could just change the header at the same time as changing the representation.
Thanks for the fast reply. My use case is for detecting file corruption in internal HTTP communication, where we trust the network/server/client. Since it's internal, we don't have to obey a standard, but I was hoping to provide the CRC32C and MD5 that we already store to our end users -- provide something instead of nothing. Those algorithms provide an adequate level of error detection by our rough calculation (considering that TCP and other layers also checksum). Intel's implementation of CRC32C [0] runs at >19 GB/s, whereas SHA256 runs at only ~360 MB/s.
Code change:
some other appropriate value e.g. according to the type and status of the primary document <del> in which the algorithm is defined; "deprecated" when the algorithm is insecure or otherwise undesirable; "reserved" when Digest algorithm references a reserved token value </del> <ins> in which the algorithm is defined; "insecure" when the algorithm is insecure; "reserved" when Digest algorithm references a reserved token value </ins> Description: the description of the digest-algorithm and its encoding

Related discussion:
text: We also take advantage of the ability of CRC32C to be combined, so we can concatenate files in O(1) time and get their CRC32C without calculating a SHA256/512 or MD5 over the whole content. We serve some millions of files. Google Cloud Storage and AWS S3 probably store many trillions of files and provide CRC32C+MD5 and MD5, respectively.1 It would be pretty impactful for servers to be able to pass along these digests and might make it worthwhile for browsers to start verifying digests for downloads (e.g. revive [1]). I might be under-appreciating the security intents of this RFC, but there is clear mention of the other benefits of the RFC (below), which are ones that non-cryptographically secure hashes are often good enough for. [0] URL [1] URL Edit: 1 Clarification: The S3 object is an MD5 in many scenarios, and S3 uses for integrity checks during uploads. They do not explicitly store the MD5 for all objects though.
Corruption in the network does happen, but HTTPS is a far better way of managing that risk. I know that you say that you trust them, but I would be worried about the network/server/client being - or becoming - untrustworthy. Obviously, if you are into high-volume transfers of bulk data, you are going to do what you need to do; specialized applications have specialized constraints. But that doesn't make unsecured transfers any less inadvisable; I'd stand by the deprecation here as a general statement.
Hi NAME Thanks for joining the discussion! Let me clarify one point: This just means that the part protected by Digest (the representation) is only a subset of an HTTP message. For the rest, while I agree on some of your considerations, eg. we had a very long discussion on that URL Maybe, since crc32 & co - while deprecated - are still defined in the digest algorithm table, I think that you wouldn't have particular interoperability issues if you need to use them in a specific environment.
Thanks NAME for the pointers to the earlier discussions. I'd thought I'd searched but somehow missed those.
Code change:
some other appropriate value e.g. according to the type and status of the primary document <del> in which the algorithm is defined; "deprecated" when the algorithm is insecure or otherwise undesirable; "reserved" when Digest algorithm references a reserved token value </del> <ins> in which the algorithm is defined; "insecure" when the algorithm is insecure; "reserved" when Digest algorithm references a reserved token value </ins> Description: the description of the digest-algorithm and its encoding

Related discussion:
text: I'll yield, although I remain in favor of saying these "SHOULD NOT" instead of "MUST NOT" be used at least because of their ubiquity, performance and the composability of CRCs. One last question: does the Digest header provide better security than, or any additional beyond, what TLS provides? My reading of the RFC is that TLS is the typical primary protection layer (since doesn't protect headers; indeed, itself could be altered) and is primarily useful for finding ~bugs. (PS: I really like the digests, nice idea.)
NAME you've made some good points. Adding accommodation for these algorithms, given the proliferation of e.g. MD5 for this kind of integrity checking could be better than nothing, or hoping that everyone would run a SHA-algo over all of their existing assets. The thorny part is how to square the circle on relaxing the rule and providing clear, meaningful guidance to implementers. The MUSTNOT helps set a clear bar, this means its unambiguous what the spec thinks about the relationship of Digest to secure usage scenarios. Anything else needs careful wording and is hard to get right. The current MUSTNOT is slightly odd in so far as we don't state the ramifications if it is used. Part of that is a product of how Digest has been defined and how apps use it
NAME The actual work on digest was driven by its usage in signing http messages (eg URL and URL ) This is at a different layer wrt TLS. So you can see Digest as a building block for creating non-repudiable HTTP exchanges without altering the payload (since signatures are conveyed via http headers). Hth, R.
Personally -- I think there's something here worth considering. AIUI the primary use case for headers is not adversarial -- it's end-to-end (i.e., through various intermediaries, toolkits, perhaps a data store) integrity. If someone has lots of content they've calculated CRC or MD5 for, it seems reasonable to allow them to use it in ; not only is it more efficient, but it saves them recalculating a value for all of that content (and possibly getting it wrong -- that's effectively "end-to-end over time"). OTOH, there are adversarial use cases for too -- mostly, signing the digest as a proxy for signing the content.
Code change:
some other appropriate value e.g. according to the type and status of the primary document <del> in which the algorithm is defined; "deprecated" when the algorithm is insecure or otherwise undesirable; "reserved" when Digest algorithm references a reserved token value </del> <ins> in which the algorithm is defined; "insecure" when the algorithm is insecure; "reserved" when Digest algorithm references a reserved token value </ins> Description: the description of the digest-algorithm and its encoding

Related discussion:
text: Here, using CRC or MD5 can be bad, and shouldn't be encouraged (or perhaps allowed) by the spec. This leads me to think that deprecating them isn't the right thing to do; instead, what about marking them as insecure in the registry, and putting language into the spec to explain how to use that? If folks think that's a good idea, I can do a PR.
Thanks for the background NAME . NAME NAME I think that sounds reasonable to state something like "insecure digests {MUST NOT be used|are not suitable} for protection against malicious actors." The final part of this I think would be allowing for the insecure digests.
I like NAME idea of introducing "insecure". It's not trivial how to state that insecure algorithms must not be used in signatures/adversarial use cases. I'm waiting for Mark's proposal :)
Maybe "Checksum Only" to imply a more narrow purpose. "Insecure" is not the opposite of "secure".
LGTMA pragmatic approach.
Code change:
3.1. <del> The Accept-CH response header field or the equivalent HTML meta element with http-equiv attribute (Section 4.2.5.3 of HTML) indicate server support for particular hints indicated in its value. </del> <ins> The Accept-CH response header field indicates server support for the hints indicated in its value. </ins> Accept-CH is a Structured Header I-D.ietf-httpbis-header-structure. Its value MUST be an sh-list (Section 3.1 of I-D.ietf-httpbis-header-

Related discussion:
text: LGTM! thx
Some of this is very nit-picky; feel free to do what you like with it... ^ There's something weird going on with tense in this sentence. "Such techniques are expensive... are not portable... and make it hard..." The third doesn't fit with the first two. "Client Hints mitigate the performance concerns..." probably just "Client Hints mitigate performance concerns..." Likewise for "the privacy concerns" below. "This document defines the Client Hints infrastructure, a framework that enables servers to opt-in to specific proactive content negotiation features, which will enable them to adapt their content accordingly." --> "This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly." as a normative reference probably isn't going to fly, given its status. Why is it normative? maybe instead: Be aware that HTTP doesn't require presence of when proactive conneg is in use; if the response is truly uncacheable, it isn't necessary. maybe instead: instead: BTW, nothing is said about precedence between the two different mechanisms; separate issue? The reference to 6454 is spurious, and it's pretty indirect. Perhaps: It's kind of weird to have this list just appear. Perhaps turn these into prose? Put "For example" above the example to introduce it. Limits CH to just "optimisation." Probably should just be:
Thanks for reviewing! :) PR underway The here is conditional on cacheability. Is that OK? We're now considering removing http-equiv support for this: URL Maybe it's best to simply remove that reference here?
Ah, I missed that, sorry. WRT http-equiv; that might be best, then.
Code change:
If the cookie-name or the cookie-value contains a %x00-1F / %x7F (CTL) character, abort these steps and ignore the cookie entirely. <ins> If the sum of the lengths of cookie-name and cookie-value is more than 4096 octets, abort these steps and ignore the cookie entirely. </ins> Create a new cookie with name cookie-name, value cookie-value. Set the creation-time and the last-access-time to the current date and time.

Related discussion:
text: Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.
Code change:
deployed in a tightly coupled environment since it is only applicable to first-party applications. <ins> 1.3. It is important to consider the user experience implications of different authentication challenges as well as the device with which the user is attempting to authorize.  For example, requesting a user to enter a password on a limited input device (e.g.  TV) creates a lot of user friction while also exposing the user's password to anyone else in the room.  On the other hand, using a challenge method that involves say a fingerprint reader on the TV remote allowing for a FIDO2 passkey authentication would be a good experience.  The Authorization Server should consider the user's device when presenting authentication challenges and developers should consider whether the device implementing this specification can provide a good experience for the user.  If the combination of user device and authentiation challenge methods creates a lot of friction or security risk, consider using a specification like OAuth 2.0 Device Authorization Grant RFC8628.  If selecting OAuth 2.0 Device Authorization Grant RFC8628 which uses a cross-device authorization mechanism, please incorporate the security best practices identified in Cross-Device Flows: Security Best Current Practice I-D.ietf-oauth- cross-device-security. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Related discussion:
text: Addressing Issue I did not add anything explicit to the Security Considerations section and instead mentioned the potential security exposure in the text on User Experience
First item to add is guidance on limited input devices.
NAME I recall we discussed this, but unable to recall the details of the concern on what guidance we had in mind.
Notes from editor's call: "Not recommended to use this with challenges that require significant user experience challenges, for example entering a password on a TV screen with an on-screen keyboard." Security consideration around the differences between exposure of credentials on a TV screen in a room vs the risk of a cross-device flow We don't want to discourage the possibility of using this flow with a passkey on a TV remote control "If you're on a limited input device, and the authentication method the user must pass requires significant user interaction, e.g. entering a password, then you shouldn't use this method; use the device flow instead."
Completed in
Code change:
The Receipt contents structure is a CBOR array.  The items of the array in order are: <del> "signature": the signature over the Merkle tree root as bstr. </del> <ins> "signature": the ECDSA signature over the Merkle tree root as bstr.  Note that the Merkle tree root hash is the prehashed input to ECDSA and is not hashed twice. </ins> "node_certificate": a DER-encoded X.509 certificate for the public key for signature verification.  This certificate MUST be a valid

Related discussion:
text: Changes: Remove initial version from CCF tree alg identifier. The idea is to not be linked directly to major CCF software releases but rather version independently here. For now, there is no need to include a version number in the tree alg identifier. Remove CCF hash alg parameter as that is always implied by the signature alg. CCF signs pre-hashed data (the Merkle tree root) and doesn't hash twice.
Code change:
origin that isn't HTTPS. For example, based on the Accept-CH and Accept-CH-Lifetime example <del> above, which is received from "https://bar.example.com" in response to a resource request initiated by "https://foo.example.com", both delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to "https://foo.example.com", for requests initiated to "https://bar.example.com" from "https://foo.example.com", for up to 86400 seconds (1 day).  This preference SHOULD NOT extend to requests initiated to "https://bar.example.com" from other origins. </del> <ins> above, which is received in response to a user agent navigating to "https://example.com", and delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to "https://example.com" for up to 86400 seconds (1 day), and use it for user agent navigations to "https://example.com" and any same-origin resource requests initiated by the page constructed from the navigation's response.  This preference SHOULD NOT extend to resource requests initiated to "https://example.com" from other origins. </ins> If Accept-CH-Lifetime occurs in a message more than once, the last value overrides all previous occurrences.

Related discussion:
text: Per discussions in fetch [1], update the opt-in example to apply to same-origin resources only, with Accept-CH-Lifetime being processed on navigation requests. [1] URL /cc NAME NAME
Code change:
it conveys statuses for.  The value MUST be computed using the algorithm described in jwt-status-list-claim-encoding. <del> 4.2.2. </del> <ins> 4.1.2. </ins> Each status of a Referenced Token MUST be represented with a bit size of 1,2,4, or 8.  Therefore up to 2,4,16, or 256 statuses for a

Related discussion:
text: reorder section on Referenced Token and Status List Token URL
I did a first review of this draft. As a newbie to the topic, I found the following issues: I miss a description of the fundamental concept, i.e. the status list itself is a JWT (issued by the same issuer issuing the JWTs), the status list JWT is obtained from a URL hosted by that issuer or another party, the link between the JWT and its status list is provided through data in the JWT. I suggest to add this in the Introduction (or an Overview) section. When reading Section 3.1. for the first time I was confused whether it describes the status list JWT or the JWT referring to the status list. I think it is the latter and it should be clear to the reader on first sight. I think the order of definition should be changed. Right now, I'm supposed to understand how a status list JWT is used in a JWT without even knowing what that status list JWT is. I suggest to change order: 1) Overview of the concepts, 2) specify status list JWT (structure and where/how to obtain), 3) embedding in a JWT (syntax, processing rules, ...).
Agree on 1+2. As mentioned in we need a better word describing the "Token" that is being described by the status List. I will make a PR using "Subject Token" as this comprises both JSON and CBOR formats. Agree on 3 as well.
For reordering it would make sense to get forward with the existing PRs first and do it afterwards..
Addressing some of these issues in
What's left to do: reorder Status List Token first and Referenced Token afterwards
Code change:
identifying the protocol capabilities of senders along the request/ response chain. <del> Multiple Via field values represent each proxy or gateway that has forwarded the message.  Each intermediary appends its own information about how the message was received, such that the end result is ordered according to the sequence of forwarding recipients. </del> <ins> Each member of the Via field value represents a proxy or gateway that has forwarded the message.  Each intermediary appends its own information about how the message was received, such that the end result is ordered according to the sequence of forwarding recipients. </ins> A proxy MUST send an appropriate Via header field, as described below, in each message that it forwards.  An HTTP-to-HTTP gateway

Related discussion:
text: Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:
Code change:
3. <del> This draft currently has no requirements for IANA.  If the specification is standardised, the CACHE_DIGEST frame will need to be assigned a frame type and the Cache-Digest header will need to be registered. </del> <ins> This document registers the following entry in the Permanent Message Headers Registry, as per RFC3864: Header field name: Cache-Digest Applicable protocol: http Status: experimental Author/Change controller: IESG Specification document(s): [this document] This document registers the following entry in the HTTP/2 Frame Type Registry, as per RFC7540: Frame Type: CACHE_DIGEST Code: 0xd Specification: [this document] </ins> 4.

Related discussion:
text: The header needs to be registered if it's going to appear in an RFC. Looking at 7540, I think the frame type needs to be registered as well, since "Experimental Use" is private / local only.
Thank you very much!
Code change:
pragma and cache-control directives, unless Cache-Control: no-cache is purposefully omitted to target other <del> response directives at HTTP/1.1 caches.  For example: </del> <ins> request directives at HTTP/1.1 caches.  For example: </ins> will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not understand

Related discussion:
text: …Control (
See URL
I think we might re-visit this advice, since CC is so widely implemented, but the errata is correct, so yes.
Code change:
specific mechanism, the details of which are out of scope for this document. <del> 6. </del> <ins> 5.3. </ins> SNAC networks rely on IPv6 to enable routing between links, which would not be possible with IPv4 due to the lack of a standard

Related discussion:
text: … AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.
Code change:
caused a sustained rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer size was less than roughly one and a half times the Bandwidth Delay Product (BDP).  This was <del> unsatisfactory, and indeed further versions have fixed this aspect of BBR BBR-draft. </del> <ins> unsatisfactory, and indeed further versions provided a fix for this aspect of BBR BBR-draft. </ins> This requirement does not imply that the algorithm should react to packet losses in exactly the same way as current standards-track

Related discussion:
text: Suggested final edits. do not infer that BBR is "fixed", but rather say that it contains a "fix" for this. don't overstate the importance:-) fix to start by saying what the para is about (i.e. the section title).