jiebi/CodeConvo huggingface dataset:
But whether your cookie header field comes from H1/H2/H3, it will have to pass through the exact same validity checks. What is certain is that these HTTP syntax checks must be performed somewhere. But the messaging layer is not always exactly the best place for this. Typically an H1 implementation will not have code to check for embedded LF characters because it's a delimiter, while H2 needs to have explicit check against this. The rules on the resulting cookie header field format apply after Cookie header reassembly, not before. And this reassembly is specific to the messaging layer which defines how to serialize fields. Last, the generic rules are not sufficient to safely reassemble the pseudo-header fields. Maybe in the end we could combine our two parts, starting with yours to indicate what every HTTP implementation must do, and putting the focus on the extreme care that is required when translating to HTTP/1-like since we know that it's one of the most natural approaches (and even used in the examples in the spec). This could give roughly: With this I think it that the intent is clear, the guidance as well, it is exhaustive and doesn't leave any doubt on what needs to be done.
Oh, and of course: :-)
I think extreme care is need anytime a HTTP message is represented, not just when represented as a HTTP/1. If a H2 layer is delivering messages to a semantic layer that was developed against h1, then it will not be assuming HTTP valid charset in no matter if the message is passed as byte streams or lines or XML or JSON or Strings in classes. It seams wrong for one particular messaging layer (h2) to require changes in transport impartial HTTP semantic layers so the messaging layer can be "abused" for non HTTP purposes? As you say, the actual syntax validations needed to be done are dependent on the messaging layer. So they are best done in the messaging layer as it knows what it is and can sometimes do things efficiently like checking charsets during parsing. If the syntax is not validated by the messaging layer, then the semantic layer will have to do full validation, which will result in wasting CPU duplicating any checks that are done by the messaging layer (or are intrinsic to the transport).
I think I'm OK with this.
There's just one minor thing: It's actually "LF and COLON", but to be exhaustive I'd write "CR, LF, and COLON" since we've always kept extreme care on CR due to older H1 implementations. I think we really want to say something about the pseudo headers. They do not exist in HTTP/1 and the recent portswigger report clearly shows that many of us were relying on the tests performed on the reassembled start line, but that was too late (in my case everything was already NUL/CR/LF clean but LWS were not imagined there). I think it would be appropriate to place the small enumeration I mentioned above somewhere (probably after the "minimal validation" part). But it's possible that it doesn't have its place in the headers section and that it would be better discussed in the security considerations. And maybe then the whole "minimal validation" part can be moved there with it, since after all, it's what all this is about, covering risks that are known for having already been abused. If you're interested I can propose a whole paragraph about all this, as being an implementer makes it easy enough for me to describe the traps. I'm just still having difficulties with all the toolchain and the XML docs which is why I don't send PRs.
(I'll add LF) As for pseudo-headers, welcome back scope creep. Would a simple prohibition on SP (and maybe HTAB) for pseudo-headers work? I'm fairly confident that the substitution is performed as needed, so there are no valid uses for the character. Given that that is the real problem, would that do? I don't feel like a full enumeration is going to be effective, but just one more simple bullet might not hurt.
I've initially thought about it when fixing my bugs ("if I had filtered LWS as well..."). But that's not enough for :scheme nor :path. If :path starts with any character that is valid in a domain name, or a colon, you can change the authority when concatenating values. E.g. or Would result in `URL" or "URL". Similarly if ":scheme" contains a colon, we're lost. In haproxy we've seriously hardened this part so that we don't have to deal with a variant of it any time soon.
But I think that the absolute bare minimum is: no NUL/CR/LF/LWS in any of the currently known pseudo header fields no colon in :scheme nothing but "/" or "*" as the first char of :path I don't see how to fool a start line parser when reassembling something based on such minimum controls, but I do see how to fool them by relaxing any single one of the rules above.
Editors, it looks like this is ready to ship; anything stopping that?
Only that discussion was continuing. But it seems to have settled now.
Thanks Martin. What about adding the point I made above in URL for :scheme, :path and :method which need further protection (that's not addressed in core since purely H2) ? I could propose this text (yeah I know my formulations are not always great):
HTTP has always forbidden token delimiters in field names. It seems very odd that they are not forbidden in HTTP/2, aside from the specific restriction on colon. The token delimiters are DQUOTE and "(),/:;?NAME We really don't want those allowed in a field name because back-end gateways like CGI assume they have been blocked, and it would mean adding an impossible conversion step when forwarding h2 to h1. Also, it would be easier to read the Field Validity section if it first referenced what is valid for an HTTP field-name, then exclude uppercase because of lowercasing and permit the special-purpose colon for pseudo-fields, and finally list specific requirements on handling invalid characters because the length-delimited protocol elements might be used to carry invalid characters. Likewise, separating the error handling for field-name from that of field-value is useful because they are two different algorithms that are usually implemented separately.
This is really good other than a couple of niggles Expressing it this way makes it really clear the difference between recommended full HTTP validation and the minimal validation that must be imposed if full validation is not done.
NAME It already is, this just changes how it's done.
My seem to indicate we might want to reconsider how . Of implementations that honour (two don't): none will consider invalid none will consider on two separate field lines invalid none will consider a duplicated value on two lines to make the header invalid if there are two header lines, all will consider only the first (and one, Safari, appears to use the min of them) none considers a non-numeric value to be invalid only Fastly and Firefox consider a non-negative integer to be invalid ... where invalid currently is required to be considered stale.
pasted twice, second should have been s-maxage
The commit d4695a3e422f677d880dc64504c492bf71b6039d for added a paragraph to s-maxage that contains the directive must-revalidate. I think this was supposed to say s-maxage and worded for shared caches?
Sorry, been travelling. This was intentional (although I forgot to update the directive name). implies , which implies . That seems like a lot of indirection in the definition. I agree this wasn't a great way to do it, though. I think the options are: Leave it as is (i.e., two levels of indirection). Leave it as is, but use linking more explicitly so that the indirections can be followed more easily (at least in HTML renderings). Inline the appropriate text from into both and . I think those are ordered according to my preferences, least to most. (I strongly suspect many people don't realise has these semantics, because of it having a name similar to . Making them inline rather than referenced might help)
I agree with the conclusion, but am pretty sure that you meant to say s-maxage in that section defining s-maxage. That's all I changed, so it should be fine unless you wanted to add more text to explain why. I don't think it is necessary to explain more because adding s-maxage implies the server wants shared caches to reuse the response.
I agree with NAME that the additional semantics of are surprising. In particular due to section 4.2.1, comes disguised as the "different value for shared caches". So , and the difference is the handling of error cases like with ? Could you please try to explain why the additional semantics of make sense – that is, why did you not just make it the alternative TTL for shred caches? Thank you!
Ah, okay, so the added paragraph had the right directive before but simply doesn’t make any sense given the context.
The code for the IANA policies in Section 11.1 looks like this: This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies. That would be fine if that rendered as I would expect, as: Instead, it renders this way: That word ordering doesn't make sense. I'm not sure exactly what XML magic would be needed to produce the expected sentence order. Same thing occurs in Sections 11.2-4.
appears to fix only Section 11.1.
: We had trouble parsing this sentence. Does "The use of field section compression and flow control depend" mean "The use of (1) field section compression and (2) flow control depends", or does it mean "Flow control and the use of field section compression depend"? Original: The use of field section compression and flow control depend on a commitment of resources for storing a greater amount of state. Possibly ("Using ... depends"): Using field section compression and flow control depends on a commitment of resources for storing a greater amount of state.
The former is the correct variant, I think.
Suggesting instead:
Clarify the authorization server's role in detecting if a cross-device protocol is being used in a same-device scenario. See issue NAME
Give guidance that enforcement of same device use of the protocol is something the authorization server should do, in addition to a design time constraint. From Roy Williams: 1) At the end of section (5) there is a paragraph that talks about limiting Cross-device protocols on the same device. It does not seem to be something that a client could\would know about when let’s say YouTube TV requests auth and it ends up on Authenticator on the same device. In theory this would then be the Authenticator Service’s Job to determine this situation and respond with a well known pattern to drive the client to engage in a local oath call directly to authenticator. Full feedback here: URL I had promised at the 119 meeting that I would review this document and give feedback. I have completed that document and other than two potential clarification points, I found it to be helpful. The following two areas could be slightly improved: At the end of section (5) there is a paragraph that talks about limiting Cross-device protocols on the same device. It does not seem to be something that a client could\would know about when let's say YouTube TV requests auth and it ends up on Authenticator on the same device. In theory this would then be the Authenticator Service's Job to determine this situation and respond with a well known pattern to drive the client to engage in a local oath call directly to authenticator. In the case of 6.1.1 establishing proximity, there is a boundary (pun not intended) case where a device will shift between two different cellular providers. The IETF's Drone effort were examining the same problem as the drone flies close to an international boundary and flips back and forth to roaming and not. How to deal with this case or whether it is dependable is a question. I know that Pieter is suggesting Fido2, but the way this section is written a Consumption device may be on a weak Wifi and the authentication device has shifted to Cellular. Roy.
URL
I noticed the draft was renamed from the name it previously had at the last IETF meeting where it was adopted. The previous name was "JWT and CWT Status List" and the new name is "OAuth Status List". I understand not wanting to have "JWT" and "CWT" in the name, but the new name is somewhat confusing, since it makes it sound like there is a status of OAuth itself somehow. I suggest renaming this to "OAuth Token Status List" to avoid confusion.
See We got feedback from multiple people and hence decided to go for as this seemed a reasonable choice by many. I would not change the title now again before the cutoff, but I'm happy to discuss so in Prague.
FWIW my comments/feedback on and related conversations were only about the document identifier being For the draft title, I'd go with "Token Status List" as suggested URL Note that the document identifier (guess it's called docname in the markdown) needs to start with draft-ietf-oauth- because of IETF convention and the draft being an OAuth WG item. But the document title doesn't have to have "OAuth" in it.
After reviewing the discussion I also would support "Token Status List". And yes, it looks like the discussion in was about the draft URL, not the title.
The name of the issue is "Feedback from call of adoption: Draft title". How should it not be about the title then?
I was commenting on the fact that literally all of the comments only mentioned the draft URL.
I already stated in the ML, but I support `Token Status List"
"Token Status List" seems the most supported option, if there is no objection, we would rename next week. I would suggest removing “OAuth” from the title of the draft and make it “Token Status List”. “OAuth Token Status List” sounds like status list mechanism defined in this draft is only for the tokens used in OAuth/RFC6749, which it is not. Huge +1.
Best, Kristina From: OAuth On Behalf Of Michael Jones Sent: Monday, October 23, 2023 10:29 PM To: URL ; Aaron Parecki Cc: oauth Subject: Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List To Aaron’s naming points, I would be fine changing the title in the draft from “OAuth Status List” to “OAuth Token Status List”, if there’s working group consensus to do so. We could have that discussion in Prague. The name change was motivated by feedback from multiple sources that the old name “JWT and CWT Status List” was too specific in token types, seeming to unnecessarily tie our hands. That said, I don’t think we need to change the draft identifier “draft-ietf-oauth-status-list”. I doubt that there’s another kind of status list happening in the working group that might cause confusion. ;-) Besides, the draft identifier is actually ephemeral. Should the working group draft progress, it will be replaced by an RFC number. Cheers, -- Mike From: OAuth > On Behalf Of Rifaat Shekh-Yusef Sent: Monday, October 23, 2023 7:48 AM To: Aaron Parecki > Cc: oauth > Subject: Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List I also noticed you didn't mark it as replacing the individual draft in datatracker. You can email EMAIL and request that they mark it as replacing URL so that the history tracks better. I fixed that. Regards, Rifaat On Mon, Oct 23, 2023 at 10:35 AM Aaron Parecki > wrote: Tobias, Paul, Christian, I just noticed the new working group adopted version of this draft: URL I posted this comment on Github, but I'll repeat it here for others. I find the new name "OAuth Status List" confusing. While I understand wanting to remove "JWT" and "CWT" from the name, I was not aware of that discussion during the call for adoption. I would suggest renaming this to "OAuth Token Status List" instead. I also noticed you didn't mark it as replacing the individual draft in datatracker. You can email EMAIL and request that they mark it as replacing URL so that the history tracks better.
I also noticed that there are significant changes to the draft between the individual and working group versions. Typically it is better to post a verbatim copy of the individual draft as the adopted version, and then make changes in a -01 version. Thanks! Aaron On Sat, Oct 14, 2023 at 5:56 AM Rifaat Shekh-Yusef > wrote: All, Based on the feedback to this call for adoption, we declare this document adopted as a WG document. Authors, Please, submit this as a working group document at your earliest convenience. Regards, Rifaat & Hannes On Tue, Oct 3, 2023 at 8:51 PM John Bradley > wrote: +1 for adoption All, This is an official call for adoption for the JWT and CWT Status List draft: URL Please, reply on the mailing list and let us know if you are in favor or against adopting this draft as WG document, by Oct 13th. Regards, Rifaat & Hannes OAuth mailing list EMAIL URL OAuth mailing list EMAIL URL
I removed this sentence: Relays MUST NOT depend on OBJECT payload content for making forwarding decisions and MUST only depend on the fields, such as priority order and other metadata properties in the OBJECT message header. We already have text explaining that the object payload content can be encrypted (section 2.1). I think that makes it clear that a relay can't do anything with the object payload unless it has the encryption keys or a priori knowledge they are cleartext. The sentence itself was overly restrictive (relays could use other inputs, for example out of band information from configuration or business relationships). The preceding sentence explains how to find subscribers to this track, the subsequent one says "MUST forward", and we have an entire section explaining what to do with priority order now.
Line 572. “[Relays] MUST only depend on the fields [for making forwarding decisions]”. I am not sure to understand why we would like to restrict here the behavior of Relays to forward the Objects to subscribers. We can imagine edge processing for the implementation of forwarding decisions based on third-party validation (possibly based on payload). Furthermore, this restriction is not necessary for the norm to be implemented.
The intent of the language here was that relays should only depend on being able to access the headers and not the body of the objects, as the body may be encrypted. However someone may want to build a relay that uses 3rd party logic , or that inspects the payload, in order to make forwarding decisions. I agree that this should not be prohibited by the protocol. We should relax the language to indicate that payloads MAY be encrypted and that relays MUST implement any prioritization instructions carried in the headers. The spec should make no normative statements about how relays make forwarding decisions.
I agree that this is too restrictive and yet unenforceable. The intent is to say something like "a router MUST only forward packets based on the IP header". But what about the UDP/TCP header? What about the TLS header? What about the HTTP header? It's perfectly valid to use those iff a router supports those layers (aka a load balancer). I mentioned in the other issue, but we should treat moq-transport as just a layer. There may be other layers stacked on top and which should not be restricted. It's L3/L4/L7 all over again.
I am always confused when we use the term Relay to mean more than one thing. My thinking so far is, these are the middleboxes who have no role with payload of the MOQ objects. Yes, it cannot be enforced and a implementation can do whatever it wants. However, when we define security properties, we need to be clear on Relay's role. OTOH middleboxes like SFUs, transcoders are more flexible to access payload and may be payload headers based on the architecture and they fall into different category when defining the security of the system.
This is marked not-transport, but the issue was filed against text in moqt, so maybe that's not correct.
Currently, VarInts have two lengths: In the parameter length. In the first two bits of the parameter value. The decision in was that the two MUST match, which is a good solution without a full reform. However: Ignoring seems like the wrong play. For example, we know the role parameter (0x0) is a VarInt in the current draft. However this text says I MUST ignore any errors when parsing this varint and pretend like the parameter was never sent, which is both unenforceable and a major foot-gun (silently ignoring parameters). I think we close the connection with an error if there's an error parsing a known parameter.
If a parameter is unknown, then the parser doesn't know if the value is a varint and therefore can't check the length match. I thought it was better to have consistent behavior than not, because it's easier to write and easier to reason about. But if this has actual downstream consequences, I could be convinced otherwise.
I don't know what I was smoking when I came up with this title. My concern is that when a known parameter has the wrong length, the text says the decoder MUST ignore it. But it likely has the wrong length due to a bug, so this will cause unintended (non-fatal) behavior.
I understand what you mean. My point was that an unknown parameter has an inevitable result, and trying to make the processing for known parameters the same had some advantages. We'll discuss today.
Conclusion was to make it an error instead of skipping over the field if there's a length mismatch.
LG, though we can bikeshed about the error code name.
Removed the need for the new ash claim by inverting the way in which binding works by putting responsibility for maintaining the binding on the authorization server (see issue ).
I do love "ash" as a claim name but (as DPoP co-author and a DE on the JWT Claims registry) I'd strongly suggest that the binding be done the other way around. Basically just say that the AS binds the authsession value to the the public key from the DPoP proof and checks the binding whenever the client sends the authsession. Binding that way is simpler (from the spec perspective anyway) and provides more protections. It's also how most of the binding in DPoP works ("ath" is kind of an outlier and provides somewhat questionable value). URL URL
Suggestion: also require a unique DPoP key per session to avoid risks around session binding.
Completed in
Looks good
Signed-off-by: Piotr Sikora
So, what's the difference to , then? Should we just remove perhaps?
can be also sent if the connection is terminated before or when sending HTTP request. is more generic and can be sent in response to other events as well (e.g. read/write timeouts). But more importantly, either can be sent in response to the same event (i.e. connection terminated when receiving HTTP response), depending on the existing proxy implementation or various policies, i.e. "proxy should be as specific as it wants to be" from your last email.