jiebi/CodeConvo huggingface dataset:
This lets servers be more permissive if they want to treat it like the Header but allows them to be strict if they want. Since this is not an error in the frame itself, change the code to a general error; reason phrase is available if people feel it important to share.
In . NAME highlighted our treatment of structured fields parsing failures for the Priority header was a bit naff. We should just defer to structured fields, and that's what PR does. It struck me that our requirement for similar failures while processing PRIORITYUPDATE frames seems a bit overzealous in light of . From URL We introduced the current text as part of addressing . I think perhaps I misread the comment at URL There's a difference between a badly formed HTTP/2 or HTTP/3 frame (imagine one that is shorter than it claims to be, that's already described by those documents), and a frame that contains contents some other specification deems invalid. It now seems to me like it would be ok to defer to structured fields rules here. This would manifest as the receiver having processed the frame, but ignoring the value altogether (and treating it like an omission, which we explain how to deal with elsewhere). Thoughts?
While I do not have a strong opinion, I'm not sure if we need to revisit our previous decision. FWIW, IIUC, this is choosing between two principles: Frames are hop-by-hop signal, therefore the connection should be closed when receiving a malformed signal. Syntax of the value of the PRIORITY_UPDATE frame is the same as that of the header field and therefore malformed values should be ignored.
In the quiche library H3 layer, we handle all of the frame handling recommendations inside the library. When we process received HEADERS frames, we enure frame and QPACK requirements are satisfied and that we can construct a field section but defer all processing of the field section to applications. We don't process PRIORITY_UPDATE frames yet but if we did, we would likely pass the Structured Field Dictionary up to the application to deal with. With the current text we would either need to embed structured fields parsing into the h3 library code, or make the application responsible for adhering to the requirements. Both of hose deviate from our general implementation design (that's not an excuse, we'll have to do what the WG consensus tells us to do).
My thinking is that the contents of a frame's Priority Field Value is not a property of an HTTP/2 or HTTP/3 connection. If the Dictionary cannot be parsed, it does not indicate a problem with the connection. It indicates a malformed Dictionary and there are procedures defined on how to handle that in Structured Fields. Since we allow for omission of parameters in this frame, it doesn't seem that different for receivers to parse a Dictionary, fail it and treat it like omission.
Thank you for elaborating. Reading your argument, I'd be supportive to relaxing the current requirement (MUST). Maybe changing MUST to MAY or SHOULD would be the most desirable outcome, as I believe there's no reason to prohibit endpoints from employing a validity check against hop-by-hop signals.
I see you point, thanks. I think this is a case for , I can make a PR for that. I don't think that is the correct code though. URL says: requirements or with an invalid size was received. And IIUC what you want is to communicate that a problem occured at a different layer of abstraction. I think is ok unless you think we need to define a new error code just for this.
From purely editorial perspective, I'm not sure if we need to say "if it can detect" when the keyword is "MAY." I think the choice here might be between SHOULD/MAY or MUST-if-detected. Regarding the choice of the error code, I think my mental model was that the use Structured Field is a layout requirement. But I agree that it's border line, I'm perfectly fine with using H3GENEALPROTOCOL_ERROR. We do not need a new error code for this - HTTP/3 stacks can always use the Reason Phrase field to communicate fine-grained information.
The text is almost the same as in RFC 4918, except that I removed the somehow bogus claim that status code 400 wouldn't be right.
Are we updating the IANA registry to point to this document? The only slight concern I have here is that this may unintentionally reinforce the view that "real" status codes are required to be in the core document. If we can find a way to discourage that view, that would be great (but that's a separable issue).
Yes. For all codes. That occurred to me as well.
Ok, should I merge this one?
It's commonly used, but defined in RFC 4918 (WebDAV),, which continues to confuse people. Should we include it in the core specs?
For reference: URL
+1
Discussed in Montreal; support for doing this.
NAME yes, as per issue discussion I was reconsidering this. See updated PR.
yeah, I like that. Will update.
It'd be good to say something about how weakly-framed content (e.g., no Content-Length in 1.0; no CL or chunked in 1.1) should be handled differently by caches, especially during reload. From URL
In , add:
currently has: Observations: the reference really should be more specific and go to "6.3. Message Body Length" is this clear enough for protocols other than HTTP/1.1?
Referring to h1-messaging 6.3 would make this specific to H1. Referring to 4.3.1 in caching keeps it protocol-generic. If another version doesn't crisply define what's an incomplete message, we can deal with that separately.
I think the text in 3.1 should change to:
This seems reasonable. It's also related to URL, asking whether servers can wait for end-of-stream to consider a message complete in HTTP/3. (Proposal in URL is "no, you can't.")
No, HTTP/1.0 is consistently optimistic. If the server desires more rigor, it can do the work to supply the framing that would indicate an error occurred. When it fails to do so, it is deliberately choosing to maximize performance over correctness. Hence, the assumption has always been that a close-delimited message is always complete.
I think Mark's suggestion is right. I would characterize HTTP/1.0 as ambiguous and that causes revalidation deadlocks. Its somewhat worse that this pattern needlessly shows up in HTTP/1.1 as well.
Thinking on this for a while, I think MAY might be more appropriate than SHOULD here; I have a strong suspicion that most caches will not consider a close-delimited response as incomplete. I could test it, I suppose.
Also, in the sentence: ...I think s/partial/incomplete/, based on context. Any concerns there?
I think "an" is correct.
An is generally used only before a vowel. As in, "A, E, I, O, and U". An can be used before a "vowel sound" as well. But "h" in "http" is neither in my book. See URL for more info.
In (British?) English, 'h' can be pronounced either as 'aytch' or as 'haytch' so I would say that both 'a' and 'an' HTTP something should be considered fine.
Let's at least be consistent.
If you pronounce 'a' as 'ahh' then "a HTTP" sounds ok. If you pronounce 'a' as 'aye' then it sounds wrong as you have two 'aye' sounds in a row unless you pronounce your 'h' as 'haytch'. American English would generally expect "an" to be used here, I think. Dialects might disagree. RFC 2616 & RFC 7230 use "an".
We had this fight (almost verbatim) for bis; "an" won. As Martin says, let's be consistent.
Suggested elaboration / re-focusing in the introduction to clarify how CH fits into things.
CI failed due to rfc-URL DNS failure; should be transient.
Feedback addressed, I think.
Thanks for working on this! A few comments...Looks great, thanks Mark! Based on recent direction and discussions, the sections that mention "defines initial set of hints" and reference to User-Agent header may need to be updated, but we'll tackle that in a separate thread.
NAME The new sections need to go in just after all the "", otherwise the XML doesn't build (order is fixed).
Question on the cases included: isn't there a case possible where network is managed and is IPv6 only DHCPv6 addressing is used (as intended by operator) - assume DHCPv6 hands out ULA addresses no RA-Guard is applied user brings stub router, plugs it in, and it advertises a ULA prefix in PIO other devices on the link start configuring a SLAAC IPv6 address and try to use this to communicate (and routing fails because the DHCP managed ULA was not used as the source, but rather the SLAAC based ULA) But maybe this is not relevant because the source address selection algorithm would always pick the correct, managed ULA due to a better prefix match with the IPv6 destination address ?
Regarding the DHCPv6-only use case, we are assuming that the network operator wants to control which devices have addresses on the local link. In this case, they MUST use RA Guard. If they do not, then there is no protection against random devices sending RAs. So this would be a misconfiguration, and hence we don't need to do anything about it.
NAME Right, I also agree we don't have to do anything about solving this "problem" other than pointing to RA guard. But still I think it's worth mentioning: it's the one identified corner case where the SNAC router has unwanted side effects. I wasn't even sure if I was correct in predicting the effects. Considering that there is I think no other IETF-specified / IETF-compliant device that, when plugged in, would instantly disrupt this network in the way that the stub router does. If this is the worst case we can find, it should actually show that our stub router is good to go.
During email discussion in 2023, there were worries that placing a SNAC stub router in a network (with its default configurations) would disturb / harm the existing network / AIL. For example due to the advertising of extra prefixes, or advertising particular (deviating?) values of bits, routes or time-durations in the RA. One proposed solution was to provide a taxonomy (e.g.
an appendix) that explains which particular topologies/configurations a SNAC stub router can work, and in which ones it doesn't work, and in which ones it can cause malfunctions (if any). Some examples: stub router doesn't work in a network that has RA-guard in a network without RA guard, and where no suitable prefix is advertised on AIL, stub router can "disrupt" by advertising its ULA prefix. In this case we assume the ULA prefix is not intended by the admin. (Maybe the admin and/or network users should know better here, but anyhow it's a possibility.) Having a better overview of success/fail cases also helps reviewers of the document to judge the risk. FYI here's a pointer to one of the messages in the thread of 2023 that summarizes some cases and how it could be documented: URL
PR resolves this issue.
In -04, "'L' bit is set" is required for a suitable prefix. However section 5.1.2.3 allows sending PIO with L flag cleared, in particular cases. This leads to the issue that the generated PIO AIL prefix won't be recognized as a "suitable prefix" by other stub routers. So the requirement "'L' bit is set" must be relaxed for particular link layer technologies where L=0. Taking one step back – I just tried to summarize SNAC stub router scenario archetypes; both good and bad. Of the below it seems that only scenario 4 is now discussed as having a risk of breaking the network, correct? 1) Non-expert home user connects stub router to own unmanaged home network; it magically works and provides IPv6 stub/AIL routing – no matter whether user’s ISP offers IPv6 or not.
2) Ignorant employee brings stub router to work and plugs it into well-managed network; companies’ IT network magically protects the network from ill effects (RA guard, and/or port-based access control, … ) 3) Ignorant employee brings stub router to work and plugs it into unmanaged (IPv6) network; nothing bad happens - there’s already a PIO prefix with ‘A’ on the AIL 4) Ignorant employee brings stub router to work and plugs it into not-so-well managed DHCPv6-only network; stub router sends RA PIO; many hosts on the link now autoconfigure a ULA which somehow breaks connectivity for these existing hosts. 5) Ignorant network admin connects stub router to company network without changing the default settings; then it becomes similar to 4. This case is btw probably out of our scope to solve and could be solved by the mantra “don’t do that then”. (The stub router is only intended for case 1, but of course the stub router cannot tell apart cases 1,4,5.) +1 on clearly defining the possible breakage scenarios. E.g. some devices may not configure multiple addresses and get stuck with a ULA only? Or known issues with source address selection; IPv4 interactions, etc. in presence of ULAs. When doing this the Type A, B and C IPv6 hosts may also be considered. If we find no issues then we may also state this in the draft in an Appendix – what was considered, and why it isn’t a problem. Esko From: Lorenzo Colitti Sent: Friday, September 8, 2023 11:38 To: Ole Trøan Cc: Lorenzo Colitti ; Ted Lemon ; Juliusz Chroboczek ; Esko Dijk ; Michael Richardson ; Handa Wang ; EMAIL Subject: Re: [Snac] Should a stub router learn RA header parameters from other routers? I am not OK with a SNAC router connecting to an existing IPv6 network and breaking it. If you can elaborate on the type of breakage you are concerned about, then we can discuss it and possibly design for it. FWIW, just the fact of the hosts getting new addresses does not qualify as breakage IMO. All IPv6 hosts have multiple addresses and source address selection generally gets hosts to do the right thing.
Two small changes here. First, adding unnegotiated semantics to reserved bits in existing frames feels like a REALLY bad idea, since you're almost guaranteed to have collisions, so I'm suggesting we remove that as something that extensions can do unannounced. Second, we permit negotiated changes to existing semantics, so I'm suggesting that instead of saying only DATA will ever be flow controlled, we say that making anything else flow-controlled is a changed semantic that has to be negotiated.
(And as a side-note, section 6.9 implies that there may be frames other than DATA which are flow-controlled defined elsewhere: "Flow control only applies to frames that are identified as being subject to flow control. Of the frame types defined in this document, this includes only DATA frame.")
Adds an example to the Examples section to clarify and illustrate that cookie names are case-sensitive. Additionally adds a clarification that cookie names could be empty to improve readability.
Agreed
What should a user agent do with the "set-cookie-string" ? The current RFC says that the name string can be empty and then in a subsequent step to ignore that cookie. URL
Hi, instructs >If the name-value-pair string lacks a %x3D ("=") character, then the name string is empty, and the value string is the value of name-value-pair. Otherwise, the name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. which covers the case of a nameless cookie such as . I think clarifying, similar to the value string, that the name string could be possibly empty would improve readability, I'll make that change.
Thank you NAME This means there is a change in the recommended parsing algorithm: now empty named cookies are ok. Is that intended?
That's correct. Even though it's strongly not recommended we found that servers still produced unusual set-cookie strings, including empty cookie names, and many UAs accepted them. So the parsing change is meant to standardized behavior so that UAs can at least all do the same thing with them. I still strongly recommend that any sites only use cookies with a non-empty name that conforms to 's syntax. Same for the value field too, now that I'm mentioning it. It'll probably work otherwise, but why make your life harder?
I think the spec would benefit from getting this fact explicitly specified. and are two different cookies.
If you had asked me if this already existed I would have guessed yes. Seems like an obvious improvement
LGTM. It'd be very nice if we could remove the notion of empty cookie names, but since we can't we should document them clearly. :/
fixes URL
Merging new mitigation proposal
I want to use my E-ID on a verifier website to prove my identity. If I authenticated on the correct website using a phishing resistant authentication and only after this, can I scan the QR Code to present my verifiable credentials presentation. This works good, as a lot of the website where I require a digital identity check, I already have an account and can use a phishing resistant authentication first. I could add a text for this, if you think this is a good idea. Greetings Damien
NAME I think of this as a type of "authenticated flow" where the user authenticated the channel before engaging in an additional cross device flow. I think it is a reasonable mitigation, would you like to take a stab at writing up a more detailed description of the attack?
NAME Thanks for the feedback. I created a PR for this: URL Greetings Damien
NAME noticed that is messed up. I think the fix is to indent the top-level 2-5 -- but I want to have a good look at it, compare to implementation, and I'd like others to verify, as I'm wary of making changes at this late stage. Blame seems to be , which I vaguely remember as being... surprising. That will teach me to slow down when something weird happens with Git...
Ping NAME NAME NAME to look over my shoulder...
Looking at URL the problem is that what became top-level 3 and 4 should have been steps inside top-level 2. Further changes have happened so now that applies to top-level 5 as well. (Top-level 2 itself seems good as that initiates the loop.) (Other for each statements do appear to have correct indenting.)
Like that?
Looks good to me.
Define workload identity. Resolves issue
The section talks about identity then defines identifier -- I would recommend it separate things a little more and clarify the differences and relationship. Is the identifier part of the identity? Does it point to the overall identity? Augment it?
NAME - I modified the section to differentiate workload identity and identifier a bit more. Let me know if it looks good enough to merge in as a straw man for the identity section. IN any case we can discuss in the 120 meeting
NAME definitely clearer that they're separate concepts now, and all this can be refined as the draft moves on. Thanks for updating!
Some (rather nit) comments that are not related to what's being discussed on the mailing list.
Our basic list of mitigations missed a fairly obvious one. Mentioning it should help with the class of confusion Magnus N. had with the draft. I decided not to include a note about the server being unable to examine early data before making this decision. That's just something people will need to discover for themselves. Generally, you have to decide whether you want 0-RTT without seeing any of it. Partly this is because it avoids a potential deadlock, but mostly it's because the TLS stack will not even decrypt 0-RTT if it is rejected.
Looks good to me, and indeed clearer. Thanks.
+1
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.
Roman Danyliw made some comments during IESG review related to receiver validation behaviour. RFC 3230 was quite relaxed about stating receiver requirements and we've followed suit by carrying over that normative langauge almost verbatim for Content-Digest and Repr-Digest. The intention has always been that applications are responsible for deciding what integrity checks are important and what validation failure means to them. Roman suggests that we make this intention more concrete by adding explicit statements. This seems like a good idea and I'll prepare a PR to this effect. Its a restatement of intent but it is new normative language, so I'll cross post to the HTTP WG list for any additional input.
Most of the text is copied from the security BCP and only slightly adjusted. I am not sure if 2.1 needs to contain the detailed description of mix-up attacks and variants (56b6b6cdcfccf30baa124d37597d18a7cecf032e) or if it would be sufficient to add mix-up mitigations (2d07d10b9787d3798fab0913ff67ea1cd2e29d89).
Thank you, in general we have been erring on the side of leaving the detailed discussion of the security considerations in the Security BCP, and only moving the mitigation recommendations in 2.1. Would you be able to remove the detailed description from this PR?
Finally had the time for this quick revert of my latest commit. Do you think the description of mix-up is fine now? Should we add a reference to the detailed description of mix-up attacks in the security BCP?
Thanks, I added a reference to the security BCP in that section
Fixing the "release" in the sense of a defined term as "SD-JWT Release"
We have fixed the term and definitions but a few still appear in the main text. We need to fix them as well, hopefully before the first individual draft is uploaded. So, s/signatures called releases/signatures called SD-JWT Releases/ s/SD-JWTs and releases/SD-JWTs and SD-JWT Releases/ s/Verifying a Release/Verifying a SD-JWT Release/
Fixed with PR
The follow-up discussion on indicated that the nature of the updates to RFC 3864 is essentially a "partial obsoletes", which means that we do not want to be part of BCP 90 even if we could -- we're carving off a piece of it and branching out on our own. This PR attempts to reword the description slightly to indicate that we're not just tweaking part of RFC 3864, but rather replacing part of it (the parts that relate to HTTP), hopefully without bloating the text too much.
This excludes HTAB (%x09) from the CTL characters that normally cause cookie rejection. HTAB is considered whitespace and is handled separately at a later step in the algorithm. Related to
NAME NAME PTAL.
LGTM
In URL, RFC 6265bis was modified to specify truncation of set-cookie-lines at the first {CR, LF, NUL} byte. This is consistent with Chrome's current behavior. NAME that this may enable an attack where an attacker may inject a CR, LF, or NUL byte into a cookie value to cause its truncation, thus changing the value of the cookie. Investigate interop/web compatibility and consider rejecting all cookies containing any control character (rather than truncating).
Addressed by and .
Thanks NAME Do you know if tests have been updated as well and implementations bugs have been filed against browsers that do not do this (yet)?
NAME I just submitted for review an update to the tests, and will soon file bugs based on the findings from running those. I'll post back here with links to any tickets I open. Thanks for asking about this For reference: URL
NAME FYI, here are the corresponding bugs: URL ​​URL URL
Thanks NAME for your work on this!
lgtm, thanks
[ ] to obsolete the IANA Digest Algorithms Registry or define another registry [ ] it can stay as historical ~identify whether and how it should stay~ [x] if it should stay, the note below should be fixed.
I think it's easiest to just add a request to update the note in the IANA considerations of digest spec. E.g. current: something like
cc: NAME guidance welcome
Note: this has been fixed. the IANA Digest Algorithm Registry Note not to mention "message body" since it's not even mentioned in RFC3230.
NAME NAME what is expected to happen to URL after Digest's deprecation? Can it be marked as "historical" to avoid issues with current Digest implementers?
Yes, IANA can be instructed to do that in IANA Considerations.