jiebi/CodeConvo huggingface dataset:
Code change:
checksum comparison and, based on the intersection of those results, conditionally pass or fail digest validation. <ins> 12.10. "Digest" validation consumes computational resources.  In order to avoid resource exhaustion, implementations can restrict validation of the algorithm types, number of validations, or the size of content. </ins> 13. 13.1.

Related discussion:
text: includes security considerations from
NAME probably those considerations are redundant: implementers know that computing digest has a cost. Do you think it's worth spending more time to land this PR or we can close it?
I'd go with a simpler statement such as or say nothing.
NAME this PR contains your proposal.
A threat model for . is this useful/required? should this go into Security Considerations or in another document?
User User-Agent: see RFC7230 Intermediaries that do not do TLS termination Intermediaries that do TLS termination.Application: the application actually running the service Intermediaries can alter HTTP messages Intermediaries that do transport-layer termination can alter HTTP messages The application can erroneously or purposedly alter the message User can forge messages with the same checksum values An intermediary can alter an HTTP header by chance or purpose. [x] Use an end-to-end transport-layer security mechanism. A TLS-terminator intermediary can alter representation-metadata by chance or purpose. [x] Use a signature mechanism that covers both and the representation-metadata. A TLS-terminator intermediary can replace the representation-data with another one having the same digest-algorithm. A malicious User can forge two messages with: different representation-data same Digest header values send an HTTP message with the first representation-data then pretend he sent the one with the second representation-data. A malicious Server could implement a similar behavior. [x] Use a digest-algorithm that is not subject to collision (eg. sha-256), or refuse to use digest-algorithms subject to collision. A User could exhaust server resources by chance or purpose via: 1- sending a huge representation 2- digest calculation of the complete representation 3- forcing the server to evaluate the digest of the included representation [x] To consume huge representation-data, you may consider mechanisms sending progressive integrity checksums in the payload body and just use to provide the last checksum value. A malicious User could exhaust server resources via: 1- reconstruction of the complete representation 2- digest calculation of the complete representation 3- forcing the server to evaluate many different digest-algorithms for a given representation If you are exposed to this kind of attack because reconstructing complete representations of your objects is computationally intensive, avoid using [ ] Digest with mechanisms like Range-Requests and PATCH.
Code change:
checksum comparison and, based on the intersection of those results, conditionally pass or fail digest validation. <ins> 12.10. "Digest" validation consumes computational resources.  In order to avoid resource exhaustion, implementations can restrict validation of the algorithm types, number of validations, or the size of content. </ins> 13. 13.1.

Related discussion:
text: If you support multiple digest-algorithms: [ ] limit the supported digest-algorithms to the ones you really care for; [ ] establish a policy for validating only the digest using the stronger digest-algorithm. The recipient may skip Digest header validation by chance or purpose and still be compliant to the specification: as explained in {#digest-header} the recipient MAY ignore any or all the received representation-data-digests. This is because Digest was originally conceived in RFC3230 as a tool for the recipient to validate the received representation, but not for the sender to receive an integrity proof of the communication. [ ] You should not rely on the recipient having correctly verified the Digest value of the selected representation. If you want the recipient to validate the : [ ] agree on processing with your peer, like it is done in
Let's see if we can incorporate some of this into the security considerations.
all considerations should be inside the I-D once is merged
Thank, this works for me. Let's merge and we can iterate later if anyone thinks of something to add.
Code change:
introduce bursty traffic where many nodes complete a task at the same time). <del> In evaluating a new proposal for use in a controlled environment, the IETF needs to understand the usage, e.g., how the usage is scoped to the controlled environment, whether the algorithm will share resources with Internet traffic and consider what could happen if used in a protocol that is bridged across an Internet path. Algorithms that are designed for special environments and are forbidden from use in the general Internet, might instead seek real- world data for those environments.  In such cases, the evaluation criteria in the remainder of this document might not apply. </del> <ins> In evaluating a new proposal for use in a controlled environment RFC8799, the IETF needs to understand the usage, e.g., how the usage is scoped to the controlled environment, whether the algorithm will share resources with Internet traffic and consider what could happen if used in a protocol that is bridged across an Internet path. Algorithms that are designed to be confined to a controlled environment and are not intended for use in the general Internet, might instead seek real-world data for those environments.  In such cases, the evaluation criteria in the remainder of this document might not apply. </ins> 4.

Related discussion:
text: To address review comments and closing Issue
From NAME review: I reacted to the use of “forbidden” in this sentence. Would not “not intended at all for use in the Internet” be a better formulation? Because forbidden want me to invoke the Protocol Police if someone ever attempted to use it.
For me, this was meant to be stronger than "not intended", more like "confined to a limited to a controlled environment". RFC 8799 describes some of these cases, and could be a useful reference?
So I think a stronger wording is fine. But, an alternative formulation would be good that doesn't imply that you might get the protocol police after you.
Code change:
in which case we should work with the relevant working groups and present our use-cases. <del> 6.3. </del> <ins> 7.3. </ins> Even if multicast and other network broadcasting capabilities are often used in delivering media in our use cases, QUIC doesn't yet

Related discussion:
text: This is just a starting point, but brings the document closer to alignment with our spreadsheet. I've also added some additional details which should cover themes raised in the current BoF agenda.
Code change:
provides additional context for the stream.  PushResources contains a thorough description of the use of PUSH_PROMISE frames. <del> The PUSH_PROMISE frame payload has the following fields: </del> <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The PUSH_PROMISE frame payload has the following additional fields: </ins> The PUSH_PROMISE frame defines the following flags:

Related discussion:
text: I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.
Code change:
3. <del> This section describes representations of merkle tree structures in </del> <ins> This section describes representations of merkle proof structures in </ins> CBOR. Some of the structures such as the construction of a merkle tree

Related discussion:
text: Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.
Code change:
obey this directive, and communications networks might be vulnerable to eavesdropping. <ins> Note that the "must-understand" cache directive overrides "no-store" in certain circumstances; see cache-response-directive.must- understand. </ins> 5.2.2.5. The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) MUST NOT transform the <del> payload, as defined in message.transformations. </del> <ins> content, as defined in message.transformations. </ins> 5.2.2.6.

Related discussion:
text: ... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.
Code change:
14.3. <del> The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource. </del> <ins> The "Accept-Ranges" field in a response indicates whether an upstream server supports range requests for the target resource. </ins> <del> An origin server that supports byte-range requests for a given target resource MAY send </del> <ins> For example, a server that supports byte.ranges can send the field </ins> <del> to indicate what range units are supported.  A client MAY generate range requests without having received this header field for the resource involved.  Range units are defined in range.units. </del> <ins> to indicate that it supports byte range requests for that target resource, thereby encouraging its use by the client for future partial requests on the same request path.  Range units are defined in range.units. A client MAY generate range requests regardless of having received an Accept-Ranges field.  The information only provides advice for the sake of improving performance and reducing unnecessary network transfers. Conversely, a client MUST NOT assume that receiving an Accept-Ranges field means that future range requests will return partial responses. The content might change, the server might only support range requests at certain times or under certain conditions, or a different intermediary might process the next request. </ins> A server that does not support any kind of range request for the target resource MAY send <del> to advise the client not to attempt a range request. </del> <ins> to advise the client not to attempt a range request on the same request path.  The range unit "none" is reserved for this purpose. The Accept-Ranges field MAY be sent in a trailer section, but is preferred to be sent as a header field because the information is particularly useful for restarting large information transfers that have failed in mid-content (before the trailer section is received). </ins> 14.4.

Related discussion:
text: The theory that this may cause a problem with multiple paths just doesn't hold for proxies (they are client chosen) and wouldn't matter anyway for range requests because the worst case is a 200 response. This was explained in 1996 and the definition was fixed in the next draft. It just wasn't fixed enough. This doesn't change the fact that the header field isn't very useful, simply because it is advisory only and most clients will ignore that advice when it doesn't matter to them if 200 is the response. That's okay.
Code change:
3. <del> 3.1. </del> <ins> Status List A bit array that lists the statuses of many Referenced Tokens. Status List Token A token in JWT or CWT representation that contains a Status List. Referenced Token A token in JWT or CWT representation which contains a reference to a Status List Token.  The information from the contained Status List may give a verifier additional information about up-to-date status of the Referenced Token. 4. 4.1. </ins> <del> The following rules apply to validating a JWT which references a status list.  Application of additional restrictions and policy are at the discretion of the verifying party. </del> <ins> The following rules apply to validating a Referenced Token in JWT representation which references a Status List Token.  Application of additional restrictions and policy are at the discretion of the verifying party. </ins> The JWT MUST contain an "iss" (issuer) claim that contains a unique string based identifier for the entity that issued the JWT.

Related discussion:
text: Micha proposed to change REVOKED to INVALID, as it gives less intention whether this is a permanent state and the issuers could reflect a suspension also with a 1bit size status list as well
I'm in agreement with Kristina, the more I look at this the more I think we should have one possible enumeration of statuses rather than allowing every issuer to define their own, the question then becomes how big that set needs to be as it controls how many bits are allocated to each credential in the status list.
I'm fine with defining the first bit as valid/invalid. I think providing the option for additional bits offers benefits with acceptable tradeoffs
I've made some changes, please recheck NAME NAME
umm I thought we agreed to remove the concept of the "typ" attribute.. so no and no .
Yeah that was captured here NAME URL
But I assume the Status List Token will have a JOSE header to properly distinguish it from other JWTs, right?
I approve, but moved to separate issue
NAME typo on my end. yes, JWT should be typed ( claim present), the current spec also introduces a body claim as far as I can see, which is what I am not in agreement with.
NAME I am confused. so the idea is to merge this PR and then remove the "type" JWT claim in PR ?
comment edited, I got confused here as well. There is an issue open already as a task and I would like to not blow up the PRs too much
NAME ready for merge
I am a little confused with calling "VALID", "INVALID" Status List , but agreed this should be mergedOne minor typo
Code change:
3. <del> 3.1. </del> <ins> Status List A bit array that lists the statuses of many Referenced Tokens. Status List Token A token in JWT or CWT representation that contains a Status List. Referenced Token A token in JWT or CWT representation which contains a reference to a Status List Token.  The information from the contained Status List may give a verifier additional information about up-to-date status of the Referenced Token. 4. 4.1. </ins> <del> The following rules apply to validating a JWT which references a status list.  Application of additional restrictions and policy are at the discretion of the verifying party. </del> <ins> The following rules apply to validating a Referenced Token in JWT representation which references a Status List Token.  Application of additional restrictions and policy are at the discretion of the verifying party. </ins> The JWT MUST contain an "iss" (issuer) claim that contains a unique string based identifier for the entity that issued the JWT.

Related discussion:
text: We can also call it something else like credential if we do a proper introduction of the term in the beginning?
Why call "status list token" and not "status list JWT/CWT"?
agreed on call: rename Status List to Status List Token introduce Status List for the actual bitarray rename Subject Token to Referenced Token remove Status List Provider for now and introduce it later if neccessary
btw sd-jwt vc spec mentions status provider :)
NAME NAME can you approve this PR?
Hi, thinking more about this, status list Token is being referenced in the token-whose-name-we-are-trying-to-find, so it's the status list token that is actually a "referenced token". Can we call token-whose-name-we-are-trying-to-find "a Token with reference"?
Yes, I agree and had the same thoughts when I changed the PR. I assume Referencing Token could be better. But let's accept this PR and move discussion to an issue instead...
Multiple approvals and discussions on editors calls, merging
opened issue to continue the terminology discussionok. Then please migrate the TODOs afterwards.
Code change:
A subscriber cannot make overlapping namespace subscriptions on a single session.  Within a session, if a publisher receives a <del> SUBSCRIBE_NAMESPACE with a Track Namespace Prefix that is a prefix of an earlier SUBSCRIBE_NAMESPACE or vice versa, it MUST respond with SUBSCRIBE_NAMESPACE_ERROR, with error code SUBSCRIBE_NAMESPACE_OVERLAP. </del> <ins> SUBSCRIBE_ANNOUNCES with a Track Namespace Prefix that is a prefix of an earlier SUBSCRIBE_ANNOUNCES or vice versa, it MUST respond with SUBSCRIBE_ANNOUNCES_ERROR, with error code SUBSCRIBE_ANNOUNCES_OVERLAP. </ins> The publisher MUST ensure the subscriber is authorized to perform this namespace subscription. <del> SUBSCRIBE_NAMESPACE is not required for a publisher to send ANNOUNCE </del> <ins> SUBSCRIBE_ANNOUNCES is not required for a publisher to send ANNOUNCE </ins> and UNANNOUNCE messages to a subscriber.  It is useful in applications or relays where subscribers are only interested in or authorized to access a subset of available announcements. 6.12. <del> A subscriber issues a "UNSUBSCRIBE_NAMESPACE" message to a publisher </del> <ins> A subscriber issues a "UNSUBSCRIBE_ANNOUNCES" message to a publisher </ins> indicating it is no longer interested in ANNOUNCE and UNANNOUNCE messages for the specified track namespace prefix. <del> The format of "UNSUBSCRIBE_NAMESPACE" is as follows: </del> <ins> The format of "UNSUBSCRIBE_ANNOUNCES" is as follows: </ins> Track Namespace Prefix: As defined in message-subscribe-ns.

Related discussion:
text: On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.
Code change:
model-group An object is uniquely identified by its track namespace, track name, group ID, and object ID, and must be an identical sequence of bytes regardless of how or where it is retrieved.  An <del> Object can become unavailable, but it's contents MUST NOT change over </del> <ins> Object can become unavailable, but its contents MUST NOT change over </ins> time. Objects are comprised of two parts: metadata and a payload.  The

Related discussion:
text: Many thanks on review and any help of fixing all the small stuff (point me too it, or PR on the PR, anything) much appreciated.
NAME - thanks for review. I think I fixed all the stuff you raised. Can you take another look NAME - handing the baton to you on this one. Thanks you
At interim, to support make before break use-cases, we need to clarify relay behavior when a new announce arrives for existing published.
This came up during discussion of . The current draft is ambiguous whether multiple distinct publishers (not reconnect) can announce the same namespace to a relay. If that is allowed, should SUBSCRIBE messages be sent to all publishers that have announced that namespace? What happens if multiple SUBSCRIBE_OKs come back? Do we need normative text describing how a relay handles all these situations, or is it implementation specific? Some possible error conditions: Two publishers publisher the same track/group/object with different content One publisher skips an object (perhaps due to a delivery timeout) but another publisher sends it ?
I initially added a recommended session migration algorithm in . However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol. This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:
I think it'd be useful to have a PR to look at if you're willing to write one up?
Code change:
issued with those keys. The Issuer's DID is required and appears in the "1 iss" claim of the <del> "13 CWT_Claims" protected header of the Signed Statements' Envelope. </del> <ins> "15 CWT_Claims" protected header of the Signed Statements' Envelope. </ins> The version of the key from the DID Document used to sign the Signed Statement is written in the "4 kid" protected header.

Related discussion:
text: Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences