jiebi/CodeConvo huggingface dataset:
Code change:
algorithm. An endpoint might have a preference for algorithms, such as <del> preferring "standard" algorithms over "deprecated" ones.  Transition </del> <ins> preferring "standard" algorithms over "insecure" ones.  Transition </ins> from weak algorithms is supported by negotiation of digest-algorithm using "Want-Digest" or "Want-Content-Digest" (see want-fields) or by sending multiple representation-data-digest values from which the

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:
algorithm. An endpoint might have a preference for algorithms, such as <del> preferring "standard" algorithms over "deprecated" ones.  Transition </del> <ins> preferring "standard" algorithms over "insecure" ones.  Transition </ins> from weak algorithms is supported by negotiation of digest-algorithm using "Want-Digest" or "Want-Content-Digest" (see want-fields) or by sending multiple representation-data-digest values from which the

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:
algorithm. An endpoint might have a preference for algorithms, such as <del> preferring "standard" algorithms over "deprecated" ones.  Transition </del> <ins> preferring "standard" algorithms over "insecure" ones.  Transition </ins> from weak algorithms is supported by negotiation of digest-algorithm using "Want-Digest" or "Want-Content-Digest" (see want-fields) or by sending multiple representation-data-digest values from which the

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:
algorithm. An endpoint might have a preference for algorithms, such as <del> preferring "standard" algorithms over "deprecated" ones.  Transition </del> <ins> preferring "standard" algorithms over "insecure" ones.  Transition </ins> from weak algorithms is supported by negotiation of digest-algorithm using "Want-Digest" or "Want-Content-Digest" (see want-fields) or by sending multiple representation-data-digest values from which the

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:
protocol suite and therefore does not directly impact Internet security.  The implementation of various facets of the Internet's current congestion control algorithms do have security implications <del> (e.g., as outlined in RFC2581).  Alternate congestion control schemes </del> <ins> (e.g., as outlined in RFC5681).  Alternate congestion control schemes </ins> should be mindful of such pitfalls, as well, and should examine any potential security issues that may arise.

Related discussion:
text: at the time 5033 was written, only TCP, DCCP and SCTP were around, using CC; nowadays, many more protocols use CC - with QUIC standing out as a here, probably warranting it's explicit mentioning.
Yes. Note that there is a bit of sadness here, because QUIC was forced to describe use of Reno in RFC 9002, while most deployments use Cubic or BBR. But the WG could not go beyond Reno... because of RFC 5033!
This one seems simple, but is not. The introduction text says: This formulation, "Impact on standard TCP", assumes that the congestion control algorithm is an integral part of the TCP specification. The situation has changed, and I think this part should be rewritten as: The reference here should be RFC9000, the specification of the transport protocol, rather than RFC9002, the specification of default loss recovery and congestion control algorithms. And the text should then be modified to mention that our goal is to not wantonly disrupt existing deployments -- whether they use Reno, Cubic or BBR. The point is "don't disrupt the Internet", not "don't offend the pride of the IETF".
Looks good.
Code change:
7.7. <del> Issuers that chose to blind claim names MUST ensure not to inadvertently leak information about the blinded claim names to verifiers.  In particular, issuers MUST choose placeholder claim names accordingly. </del> <ins> It is RECOMMENDED to use cryptographically random numbers with at least 128 bits of entropy as placeholder claim names. With the approach chosen in this specification, claim names of objects that are not themselves selectively disclosable are not blinded.  This can be seen in Example 6 in the Appendix, where even in the blinded SD-JWT, </ins> <del> It is RECOMMENDED to use cryptographically salts with at least 128 bits of entropy as placeholder claim names. </del> <ins> and are visible.  This limitation needs to be taken into account by issuers when creating the structure of the SD-JWT. The issuer MUST ensure that a new random placeholder name is chosen for each claim, including when the same claim name occurs at different places in the structure of the SD-JWT.  This can be seen in Example 6 in the Appendix, where multiple claims with same name appear below and , but each of them has a different blinded claim name.  For each credential issued, new random placeholder names MUST be chosen by the issuer. </ins> The order of elements in JSON-encoded objects is not relevant to applications, but the order may reveal information about the blinded

Related discussion:
text: PR and PR
I agree with these changes, but it really made me think that we need to clarify various options we have introduced how claims in SD-JWT can be represented as it is becoming a bit hard to follow.. issue filed
Code change:
Abstract <del> This specification describes an optimized expression of the syntax of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more </del> <ins> This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more </ins> efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent messages on the same connection.  It also introduces

Related discussion:
text: Editorial suggestions for WGLC. I don't think there's anything controversial or semantically significant here, but please have a look over it before accepting.
Code change:
When a cache receives a <del> response and already has one or more stored </del> <ins> response, it needs to identify stored responses that are suitable for updating with the new information provided, and then do so. </ins> <del> responses for the applicable request URI, the cache needs to identify which (if any) are to be updated by the new information provided, and then do so. </del> <ins> The initial set of stored responses to update are those that could have been selected for that request -- i.e., those that meet the requirements in constructing.responses.from.caches, except the last requirement to be fresh, able to be served stale or just validated. </ins> <del> The stored response(s) to update are identified by using the first match (if any) of: </del> <ins> Then, that initial set of stored response(s) is further filtered by the first match of: </ins> For each stored response identified, the cache MUST update its header fields with the header fields provided in the

Related discussion:
text: says: [...] says about : [...] Because we're saying that validation occurs against all responses for a given URI (see ), this has the effect of allowing a response with a header to update all of the responses sent for that URI in that second (provided the requirement about is met) -- which would lead to e.g., response with updating other languages. That probably isn't desirable. The obvious way to fix this is to avoid promoting to a strong validator when it's being used by a cache. However, see -- it's necessary for it to be strong for . It might also be worth refining caching 3.4.3 to differentiate between entity-tag updates and last-modified updates.
In 4.3.5, updating is done like this: Note that it's specified in terms of responses that could have been selected for that request, rather than "stored... responses for the applicable request URI." If we modified 4.3.4 to specify that responses that could have been selected for the request sent are updated (still subject to further filtering down by any validators in the 304 response), I think it should work.
Code change:
Many use cases have various middleboxes inserted between pairs of services, resulting in a transport layer that is not end-to-end encrypted.  We propose to address these use cases by protecting <del> the REST messages at the application level (app-level). </del> <ins> the HTTP messages at the application level (app-level). </ins> The other commonly deployed architecture has a mutual-TLS connection between each pair of services.  This setup can be

Related discussion:
text: There's nothing necessarily RESTful about this nor should it be limited to REST. Let's just not use the term. URL is a fun semi-related read, if you have or can find the time.
Quoting the article: I am not as young but I agree with this sentiment. Having said that, I guess a standard needs to be reasonably precise in its usage of terminology, and so I accept the PR.
Code change:
2. <del> The "aesgcm128" HTTP content-coding indicates that a payload has been </del> <ins> The "aesgcm" HTTP content-coding indicates that a payload has been </ins> encrypted using Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as identified as AEAD_AES_128_GCM in RFC5116, Section 5.1. The AEAD_AES_128_GCM algorithm uses a 128 bit content encryption key.

Related discussion:
text: In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .
Code change:
6.2. <del> The "SETUP" message is the first message that is exchanged by the client and the server; it allows the peers to establish the mutually supported version and agree on the initial configuration before any objects are exchanged.  It is a sequence of key-value pairs called SETUP parameters; the semantics and format of which can vary based on whether the client or server is sending.  To ensure future extensibility of MOQT, the peers MUST ignore unknown setup parameters.  TODO: describe GREASE for those. </del> <ins> The "CLIENT_SETUP" and "SERVER_SETUP" messages are the first messages exchanged by the client and the server; they allows the peers to establish the mutually supported version and agree on the initial configuration before any objects are exchanged.  It is a sequence of key-value pairs called SETUP parameters; the semantics and format of which can vary based on whether the client or server is sending.  To ensure future extensibility of MOQT, the peers MUST ignore unknown setup parameters.  TODO: describe GREASE for those. </ins> <del> The wire format of the SETUP message is as follows: </del> <ins> The wire format of the SETUP messages is as follows: </ins> The available versions and SETUP parameters are detailed in the next sections.

Related discussion:
text: Feel free to change the numbers to any ones you prefer.
There's a single SETUP message, but the contents change based on if the endpoint is a server or a client. . This is difficult to implement in type safe languages. I would implement and , sharing the same ID. However, it's then difficult to implement a generic method as it needs to know the expected role to distinguish between the two. I propose a separate and message akin to how TLS has a separate and . Alternatively, implement to reclassify SETUP and OBJECT as control and data stream headers respectively.
Hmm, so this isn't a problem in my code any longer since made SETUP a special message type. We should still figure out if both the client and server SETUP use the same ID, or separate IDs like TLS.
I still like the idea of, if these message are different, they should have different names as it will just be confusing if they do not.
Agreement these should be different message types, just like TLS.
Conveniently, message id=2 is currently not used. I propose ClientSetup = 1 and ServerSetup = 2.
Thinking about this a bit more, do we want to bake in the assumption that the client always speaks first into the protocol? For raw QUIC, typically, the server would have 1-RTT keys first.
I would love to see something like HTTP/3 SETTINGS where both endpoints can send the message in parallel. That requires version negotiation at a lower level in something like ALPN though. The SERVER SETUP would be sent first in native QUIC while the CLIENT SETUP could be sent first with WebTransport (in parallel with CONNECT).
LGTM
Code change:
recognized Key Binding data is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification. <del> 10.7. </del> <ins> 10.6. </ins> SD-JWT ensures that names of claims that are selectively disclosable are always blinded.  This prevents an attacker from learning the

Related discussion:
text: Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text
Code change:
As an alternative to using GET, many implementations make use of the HTTP POST method to perform queries, as illustrated in the example below.  In this case, the input parameters to the search operation <del> are passed along within the request payload as opposed to using the </del> <ins> are passed along within the request content as opposed to using the </ins> request URI. A typical use of HTTP POST for requesting a search

Related discussion:
text: This spec uses 'body' and 'payload' a lot; I think most should be 'content'.