jiebi/CodeConvo huggingface dataset:
There were basically 2 paths discussed: (implemented in this PR) treealg (TBD1): RFC9162 (1) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): BitcoinMerkleTree (2) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): Merkle^2 Tree (3) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg search proof (TBD4): bytes based on treealg non inclusion proof (TBD5): bytes based on treealg (previously discussed at IETF 115) treealg (TBD1) : "RFC9162SHA256INCLUSIONPROOF" (TBDA) proof (TBDB): bytes based on alg treealg (TBD1) : "RFC9162SHA256CONSISTENCYPROOF" (TBDC) proof (TBDB): bytes based on alg Other things to consider... Can an unprotected header contain multiple proofs for a single type? Can an unprotected header contain multiple proofs of multiple types?
NAME NAME thank you for the reviews. All the CDDL examples will need some help, and certainly there is a lot more editorial work that needs to be done to fully align to this approach. I tried to do the minimum in this PR to host the discussion, but if we merge this, there will need to be further cleanup.
I should point out that the deletion of the consistency proof CDDL, means that it shows up before you define it below. If you think that is ok, I am fine with it.Approved, acknowledging the need for further editorial work & CDDL examplesI agree with Orie's choices; "verifiable data structure" and "proof type" are good generalizations, and I prefer the 2-layer algorithm as e.g. some verifiers may care about a commitment to a VDS even if they don't use a particular proof type.
From this conversation URL this PR tries to somewhat better explain that explicit typing, per JWT BCP before it, is about distinguishing different types of SD-JWTs. And also be a little more open to other ways of typing, such as cty.
Thanks, looks COMPLETELY REASONABLE to me. inline this time... On Mon, Sep 30, 2024 at 6:30 AM Dick Hardt wrote: While the use of "typ" is unnecessary. So this first choice issue didn't need to be an issue at all. That's the issue. Elevating an unnecessary and arguable flawed construct to a MUST would only further engrain the issue. that we are still talking past one another and there remains some misunderstanding as distinguishing between an sd-jwt and other tokens isn't what explicit typing is about. I'll take another look at the language in the draft around typing and see if there's anything that can reasonably be done to make it less confusing or potentially problematic. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
I resisted the urge to resolve other issues with this, so there are a bunch of TODOs in the text. Most of the big blocks of text are moved from elsewhere in the document.
The guidelines overlap in odd ways. The first one is essentially TCP-friendliness, and I guess it's implied to be talking about "normal" wired networks. Then different guidelines say the algorithm should be evaluated with all sorts of environments and/or link parameters, presumably for friendliness. Then, in "Minimum Requirements" some of these are listed as mandatory to satisfy, and the rest as something the submitter has to report on, but the community may decide to accept even if it's bad. There are several different concepts that are being muddled here. Alternatively, we can structure it as follows: (A) Metrics to evaluate Does the new algorithm match its share of the existing bottleneck bandwith better than existing algorithms? (not underutilizing, not bufferbloating or congestion collapsing) in isolation or with multiple flows? Are flows using widely deployed algorithms not severely degraded by the introduction of the new algorithm? Is there a plausible incremental deployment plan? Something about short flows? (B) Mandatory Domains: must answer positively to (A) Wired networks, "normal" range of BDPs Wireless networks, "normal" range of BDPs (loss & jitter) Internet-scale deployment is sufficient for this? (C) Optional Domains: must evaluate (A) & report IoT Satellite Misbehaving nodes Response to sudden & transient events Tunnels for explicit-signal protocols Extreme packet reordering
I agree we need to restructure, I like the idea of A. I think defining heterogeneity in B is likely helpful - although we really ought to stop using "bandwidth" when we mean "capacity" - because it really confuses SDOs that actually do cap[acity v bandwidth tradeoffs:-) I'll fight that Internet-Scale deployment is sufficient;-). That plays to the big operators, and I do not like that. It worries me quite a lot that we target "normal BDPs" - that's not something I would welcome. It places all satellite outside normal, which again, I don't like - some satellite is definitely odd, but I'd really like to see broadband services as "normal", if nothing else, to include those people who can only use this technology.
So, main question first: can we factor the last section as different in a particular perspective, rather than "labelling" networks as optional to support? i.e. XXXX is a property, and IoT is an example, transients and abrupt capacity variation is an example of radio networks; etc.?
I agree that we need a better structure. Including having actual subsections per issue, rather than the current list format. Two points: short flows, and transient events. Short flows are pretty much the norm, with reports of 90% of connections never going out of slow start. There is an associated problem: capacity discovery algorithm like slow start will rapidly increase the amount of data sent on a path, with a high potential for disrupting current users of that path. That's not good. There are potentials solutions such as quickly evaluating the capacity (e.g., packet pair, squirting, variants), remembering past connections (careful resume), or potentially getting input from the network (maybe something like Prague/ECN). These solutions have been explored for "special" links (satellite, deep space), but the problem is not just special links. I would like to see that discussed in the "main" section (A). Transients are also the norm. Congestion control is a form of control algorithm, and control algorithms must absolutely deal with transients. For example, if we deal with wireless, we need to deal with "entering a tunnel" -- and exiting. We may want to deal with . That should belong to the core (A), not the "weird configuration" (C).
Wait to land PRs, then do this with no substantive change, then do other PRs -- this change will be editorially disruptive.
I like the flow after this refactoring!Good to merge, the text here looks good to me. There are still things to think about, but these are probably best down on the basis of the entire document.
In response to Updated section on: Mutual Authentication Security Considerations for Client Authentication Added security considerations for protecting the workload configuration NAME NAME
I wonder if we can clarify the guidance in Section 7.4 a bit: From: It SHOULD rely on mechanisms, such as Spiffe or some other means of performing MTLS [RFC8446], to securely authenticate the requester. To: It SHOULD rely on JWT or X.509 credentials, which may be provisioned using SPIFFE or other mechanisms, to securely authenticate the requester. The final sentence in section 7 probably also needs a bit of clarification: It SHOULD rely on mechanisms, such as [Spiffe], to securely authenticate the Transaction Token Service before making a Txn-Token Request. I think the requirement here should be that the Transaction Server should be authenticated to the workload using a JWT or X.509 certificate, which may be provisioned using SPIFFE or another mechanism and used with a secure protocol like MTLS or using the WIMSE service-to-service authentication mechanisms.
I think clarifying this would be good (Section 7.6:) For me the key is that any workload invoking the TTS must use some form of strong client authentication. That could be SPIFFE, privatesecretjwt, mTLS, ??? The normative requirement should be "strong client authentication" and the others can be examples of such. I'm not sure how the workload can "pre-authenticate" the TTS. I like the pre-defined endpoint (or maybe "pre-configured" endpoint) concept. Basically, the TTS should be at a well known location. I guess there is a security issue if the workload sends an accesstoken to the wrong server especially if the external accesstoken is a bearer token. Is this something we should just cover in the Security Considerations section?
I think you touch on a few things here: We don't address discoverability of transaction token servers. Should we add something (e.g. define a well known endpoint, include discovery metadata in the authorization server metadata etc?) Can you say more about "pre-authenticate"? Do you mean some mechanism whereby the workload can trust the TTS or the location of the TTS?
Agreed on the security considerations for ensuring that the access token is not sent to an incorrect endpoint (I can imagine an adversary getting into a build server, modifying the TTS location for a workload, and then have the TTS send tokens to it. I can also imagine this happening by accident, especially if there are multiple TTS's in a deployment.
Regarding the second point: Yes, should there be a way for the workload to determine it can trust the TTS before sending it an external token? This isn't something that is common in OAuth specs. It is assumed that the client knows whether to send the request or not.
Regarding 1: I think we wanted to talk about it at the last IETF and ran out of time. I seem to remember a few conversations around "discovery" but nothing concrete was decided.
I found the issue it's
The old text stated padding things were identical to DATA frames. That might not be entirely true. So just spell out the requirements expicitly.
I just realised RFC 7540 was always this way, but it doesn't seem right to me. The DATA frame definition includes normative requirements on sender and receiver using the field. I presume the HEADERS frame is supposed the treat padding the same but it isn't written down. edit: plus PUSH_PROMISE
Ah, it's stated in a separate paragraph at the end of each frame definition section. That's annoying but I guess its fine.
Yeah, so the short answer there is that they behave differently in some ways (at least with respect to flow control). If you think there’s a better way to structure the section I think you’re welcome to take a crack at it.
I didn't actually make the leap to flow control, that makes me more inclined to avoid the cross reference to DATA frames. I made to just make everything explicit at the cost of a few more lines of text.
Added "Request Initiation Verification" as an additional mitigation based on issue
Follows . (CC NAME OTP Verification In the User-Transferred Session Data Pattern and Backchannel-Transferred Session Pattern, before authorizing the attempt, the Authorizing Device could display an OTP to be inserted back in the Initiating Device. In case the QR code or the push notification was generated without the users' consent, they would not have performed any action on the Initiating Device, and therefore they would not know where to insert the OTP they received. Limitations: Attackers could deceive users into revealing the OTP through other means (e.g., via email) and use it to finalize the authorization process; the additional step could reduce the usability level of the protocol. Effect on attacks (Table 1): .
Discussed with Daniel and proposal is to include as an additional mitigation and position this as part of the user authentication (i.e. not a protocol extension). It makes it harder to scale attacks, as the attacker has to find a way to recover the PIN as well.
Fix typo on "Authorization Device"
The PR introduces a new SETTINGS parameter that can be used by a server to notify if (and how) it makes use of the CACHEDIGEST frames. You might find the discussion about how to use the parameter interesting. The text of the PR, under the assumption that the underlying transport will be TLS 1.3, suggests the client: to wait for SETTINGS parameter when doing a full handshake retain the value of the parameter in the TLS session cache and reuse the cached settings parameter value when doing 0-RTT resumption
Looks good to me, delta the one comment I made.
Note outstanding question on the issue regarding PUT.
NAME any thoughts about whether we should mention PUT?
I don't think we need to.
I think PUT is already covered in PUT.
Hypothetically, you could be uploading a partial representation of an object, so I'm not sure it's worth prohibiting. However, I've not dealt with any systems that allow partial PUTs. Mostly you PUT (or POST) the blocks as individual resources, then make a final call with the blocklist to assemble the object from the existing blocks. Unless anyone has seen it in action, it's worth indicating it's not common practice. Perhaps a note saying that the behavior is dependent on the method and isn't defined for any known methods?
The essential problem is that it is not interoperable in general for PUT without private agreement between client and server. Furthermore, there is a risk of bypassing content filtering for security, etc. I could see it being usable with a new method.
My understanding has always been that you couldn't have a partial request. We've discussed this extensively before; would need to dig up the references.
(it may have been in discussion of PATCH, which is the proper way to do this)
Proposal: ... to align with the language used in Range.
maybe since this case doesn't matter if the method is unrecognized.
Should we mention PUT's requirement to generate a 400 if C-R is present?
Sorry... I just overlooked this, which is related to the ongoing work with digest NAME My understanding is that with a new method, this could be possible.
Fwiw my minor survey showed that most storage oriented services actually seem to offer some variant of request with Content-Range, see URL
But most of these use PUT, for which this is explicitly called out as "MUST NOT".
I'll propose a RESUME method + Content-Range for that.
I think the simplest possible approach would be PATCH with a payload format that just describes offset, length and payload. No need for a new method.
Which brings us back to the discussion about whether we're defining restrictions or describing usage, doesn't it? Lucas's survey demonstrates that PUT with Content-Range is widely used, even if currently prohibited.
The existing restriction is that PUT means make this payload the current representation. There is no way to remove that restriction without breaking interop for PUT, which pre-existed Content-Range by several years.
We are talking about a dozen private implementations of partial PUT versus a billion deployed servers that will gleefully ignore the Content-Range or store it with the new representation (because it starts with Content-*). The only reason this isn't obvious is because almost all Internet-facing HTTP servers disable PUT, so we are left with a few private servers that don't care about Internet standards.
But if we look inside the firewall at internal servers that support WebDAV and other variants of HTTP PUT, they do not support the use of Content-Range to perform a partial PUT. They would be able to support a PATCH method.
I just checked the code and it seems mod_dav has supported partial PUT on flat files since RFC2616.
This is a very big change at the last minute. At a minimum, it needs to be discussed on list. I'm also not very happy documenting a new feature that admits it's not interoperable or backwards-compatible, based upon one implementation in the wild (so far). IMO a much better way of doing this would be to slightly loosen the requirement to generate a 400 when PUT contains a content-range, saying that it can be allowed by an extension or an out-of-band arrangement. Then, if someone wants to, they can create a separate spec for partial PUT.
Well, sure, but that's what the PR says. I don't see how removing the current requirement to generate 400 (which exists to preserve interop) is possible without documenting what should be done instead to preserve interop, even if that happens to be a "Hail Mary" pass more likely to be dropped than caught. I have no idea if this matches any specific implementation. I'd give it around a 50% chance, as opposed to the 10% that I previously assumed. It definitely needs to be discussed on list, but it seems to match the general intent if we allow Content-Range to be used at all. This doesn't prevent anyone from publishing an update in the future. In any case, I decided to propose it now since I did most of the arguing against this feature in the past.
I'm proposing that we just say something like:
In the interest of getting the spec out, I slightly prefer Mark's proposal. That said, if we can get the description of partial PUT in (and that might be possible), I'm ok with that as well.
I think the current implementation landscape suggests us to be open about partial representation in requests (and that's what is relevant WRT ). Which were the compelling reasons for forbidding ?
NAME - see URL
BTW, the Google API also uses a status code to indicate a not-ready-yet error.
They promised to get rid of the 308 years ago; maybe it's just the documentation.
NAME do you still aim for this spec to go to full Internet Standard?
Is this a trick question? Yes, I think we should try. But then, we did add other new things, and also did a lot of re-org.
Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?
Signed-off-by: Henk Birkholz
Henk, The Distributor isn’t always the signing authority. It’s true in some app stores, but beyond that the model breaks, down. Walmart doesn’t digitally sign software it sells/distributes. Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788
Then this is going on the agenda for Monday, too. Thanks Dick
Thanks, Henk. Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788
From discussion with Henk I believe the use-case here is an app store-like promotion scenario. If that's true, I recommend we refer to this as the relationship between a supplier/producer and the distributor. While signing is a property of the relationship between an app creator and an app store we can increase the clarity of the use-case by describing the roles in the relationship (producer/distributor/consumer). I've made some suggestions on the PR to replace "Signing Authority" with "Distributor".
And an update to the section reference. For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams.
Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.