jiebi/CodeConvo huggingface dataset:
(Yes, I am sure that somewhere, someone handles this properly, but I am willing to wager there are also places where an empty request body is incorrectly assumed by naive scripts.) To be proactive, lighttpd 1.4.74 and later will by default ignore Upgrade in all requests with a request body unless lighttpd 1.4.74 or later is explicitly configured to enable request body along with Upgrade via URL (gw == gateway in lighttpd, for CGI, reverse proxy, and other backends) tl;dr: I am not asking to restrict HTTP/1.1 Upgrade only to the GET method. I would like to request that optimistic-upgrade add guidance suggesting that future Upgrade tokens should suggest/recommend use in requests without a request body, and note that some proxies or origin servers may ignore HTTP/1.1 Upgrade when a non-empty request body is present. Thank you for your consideration.
Since we are discussing this publicly, I hope these details are appropriate. lighttpd 1.4.56 and later supports the HTTP/1.1 (now deprecated by the RFCs), but lighttpd ignores unconditionally if a request body is present. Among the reasons for doing so -- in addition to simpler implementation -- is that if an attacker controlled the request body content and wrote it in such a way to start with HTTP/2 Connection Preface and an HTTP/2 request, and if the server failed to handle the HTTP/1.1 request body before switching to HTTP/2 protocol, then an attacker could inject HTTP/2 requests via that mishandled (on the server) HTTP/1.1 request body.
As I understand, this problem is specific to HTTP/1.1. I'm not sure if we could add new requirements, unless we change the core HTTP documents and can modify all existing HTTP clients that use upgrade to adopt the new behavior. At the same time, IMO it would be perfectly reasonable to point out the "sharp edges" and provide guidelines to new extensions that would leverage the upgrade mechanism. In that respect, I like the idea of recommending use of GET but not any other HTTP method for new extensions, as suggested in the original post from NAME
NAME Yes, the request header is specific to HTTP/1.1. I can imagine a future Upgrade token which requires POST with some sort of (short) request body containing authentication and/or payment information.
[x] 3. It's probably worth mentioning that they're comma-separated in prose. [x] 3. Disagreeing plurals in 'an incremental digest-algorithms'. [x] 4. Is Want-Digest a request field, a response field, or both? In either or both cases, what's the scope of the assertion? [x] 4. A reference to SEMANTICS 12.4.2 is necessary. See
… section;
Hi Roy, Please consider this reference for the privacy considerations section: Bujlow, T., Carela-Español, V., Solé-Pareta, J., & Barlet-Ros, P. (2017). A survey on web tracking: Mechanisms, implications, and defenses. Proceedings of the IEEE, 105(8), 1476–1510. Regards, Rob
URL
NAME has done a lot of work in this area, so he might have another suggestion. The referenced paper does cover a good amount of techniques that target HTTP itself, so I'd say that it's worth citing unless a better option presents itself.
This is an attempt at clarifying MAXSUBSCRIBEID, feel free to make suggestions.
lgtm
In 6.16 of draft 6, the draft says that "receipt of a MAXSUBSCRIBEID message with an equal or smaller Subscribe ID value is a 'Protocol Violation'." ; however, later the section mentions that "If a Subscribe ID equal or larger than this is received in any message, including SUBSCRIBE, the publisher MUST close the session with an error of 'Too Many Subscribes'." This is can be ambiguous because technically MAXSUBSCRIBEID is any message. Should all sessions be closed if MAXSUBSCRIBEID message contains an invalid Subscribe ID value? Does any message exclude MAXSUBSCRIBEID if an invalid Subscribe ID value is provided? Clarification on this would be helpful. Thank you!
lgtmAgree with Alan's comment. Otherwise LGTM
by taking NAME suggestion of MAY and bolts it to an "if you can detect" caveat
Since this is a change of normative requirement, lets solicit for some more WG input before landing
I noticed the same while reading the document and thought that MAY would be more suitable. Or in more precisely, "MUST ignore any change and MAY treat it as a connection error".
I couldn't see this being discussed in an issue so far. This seems unnecessary. While there is no value to changing the value, it creates a special rule for handling of the setting. In particular, endpoints that don't distinguish between SETTINGS-in-preface and other SETTINGS frames might have trouble generating the special handling necessary to police this rule. While I can see the value to an endpoint in terms of being able to defer creating the whole priority tree mess for new connections until they receive the preface, and maybe avoid creating that stuff entirely. But as long as priority signals are advisory, you get most of the value from a strong recommendation to use the preface, noting that making a change later might be too late. No special exceptions would be needed. I'm sure that the editors will disagree with me here. That's OK, but it's worth noting why this special handling is included in the specification. It's not immediately obvious.
Would it be sufficient to make this a "MAY be treated"? That provides a disincentive to change without requiring special processing.
The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"
[x] Section 9.4 Furthermore, using multiple connections can cause undesirable side effects in congested networks. Using larger number of multiple connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. nit: "Using larger number of multiple connections" doesn't seem right, and possibly in more ways than just the singular/plural mismatch. Editors: URL [x] trailers and chunked The only general comment I have is that [Semantics] did such a good job of portraying the trailer section as a generic concept that I was surprised to see it presented as specific to the chunked transfer-encoding in this document. It seems to me (naively, of course), that when the content can accurately be delimited, whether by Content-Length or the chunked transfer-encoding, a trailer section could be read after the request or response and clearly distinguished from the start of a new request or response. I recognize that we have a significant deployed base to be mindful of backwards compatibility with, and so do not propose to recklessly add trailer sections everywhere. It might be worth some more prominent acknowledgment that in HTTP/1.1 the trailers section is limited to the chunked transfer-encoding, and discussion of why trailers are not usable in other HTTP/1.1 scenarios, though. Editors: The HTTP/1.1 message format does not allow adding trailers as a section following the message body. Trailers is allowed in chunked because the content itself is encoded into a format that concludes with an optional trailer section (within the message body). There is no possibility of generalizing this further for HTTP/1.x. [x] 2.2 trick a server into ignoring that field line or processing the line after it as a new request, either of which might result in a security vulnerability if other implementations within the request chain interpret the same message differently. [...] Given the previous procedure that gives as a permitted behavior to "consume the line without further processing", it seems like an attempt to get the server to ignore the field line would have succeeded if this procedure is followed? I suppose the important difference is that the field line is completely suppressed from any version of the message transmitted downstream, thus avoiding the opportunity for a different interpretation.
Please do :-)
[x] Section 9.4 Furthermore, using multiple connections can cause undesirable side effects in congested networks. Using larger number of multiple connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. nit: "Using larger number of multiple connections" doesn't seem right, and possibly in more ways than just the singular/plural mismatch. Editors: URL [x] trailers and chunked The only general comment I have is that [Semantics] did such a good job of portraying the trailer section as a generic concept that I was surprised to see it presented as specific to the chunked transfer-encoding in this document. It seems to me (naively, of course), that when the content can accurately be delimited, whether by Content-Length or the chunked transfer-encoding, a trailer section could be read after the request or response and clearly distinguished from the start of a new request or response. I recognize that we have a significant deployed base to be mindful of backwards compatibility with, and so do not propose to recklessly add trailer sections everywhere. It might be worth some more prominent acknowledgment that in HTTP/1.1 the trailers section is limited to the chunked transfer-encoding, and discussion of why trailers are not usable in other HTTP/1.1 scenarios, though. Editors: The HTTP/1.1 message format does not allow adding trailers as a section following the message body. Trailers is allowed in chunked because the content itself is encoded into a format that concludes with an optional trailer section (within the message body). There is no possibility of generalizing this further for HTTP/1.x. [x] 2.2 trick a server into ignoring that field line or processing the line after it as a new request, either of which might result in a security vulnerability if other implementations within the request chain interpret the same message differently. [...] Given the previous procedure that gives as a permitted behavior to "consume the line without further processing", it seems like an attempt to get the server to ignore the field line would have succeeded if this procedure is followed? I suppose the important difference is that the field line is completely suppressed from any version of the message transmitted downstream, thus avoiding the opportunity for a different interpretation.
"Highest ordered" implies some numerical rank-list of ordering, but we don't seem to clearly indicate whether older or newer requests receive higher numerical indices. It seems simples to just say "oldest" (or "newest", if that was the intent) rather than applying numerical ranking. Editors:
closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... I'm not a TLS expert. That said, if this is correct, would be lowercasing the two keywords be sufficient?
URL is for section 9.8
Change for 9.8 LGTM (as what might pass for a TLS expert).
suggestion
Replace use of "precedence" that could be confusing with something better. With this PR, there are still two remaining occurrences of "precedence," in , and . I think that those two are fine, as they are surrounded by other text explaining the context. I think it'd be clear to readers that we are using the term to describe difference of importance between multiple responses. FIxes Ea of .
Thank you, this looks good. I agree with your rationale about why we don't need to remove all instances.
Is there a reason why you did not use uppercase terms like MUST NOT or SHOULD? Because it's supposed to be informative?
Yes, the section is non-normative.
Currently logging guidance says "Txn-Tokens SHOULD NOT be logged if they contain Personally Identifiable Information (PII)". I have few questions on this one Risks with logging is that token is still valid for few minutes and if logs are rotated to any other central archival storage with access to broader set of people or someone has access to the server with logs, then they can reuse the token. So why not just say MUST not log token? Also how would a service know if incoming token has PII or not. They will have to validate the token, extract claims and then somehow know infer that a claim is PII or not. On similar lines, for PII , can we mention that TTS SHOULD evaluate encrypting or tokenizing PII claims rather than adding them in plaintext. Adding in plaintext is a risk because TTS isn't aware where the token flows.
Txn-Tokens already contain the subject identifier which is enough to be considered PII in some environments. Our own policy states that PII data can be logged, but the logs must be deleted after a few days (max 7) days. We forbid logging of Txn-Tokens in our integrations for security reasons, not just because they could contain PII.
Our implementation in my company, we do follow the same guidance i.e do not log tokens at all, nothing to do with PII. Tokens are pretty much considered as credentials as validating parties leverage the claims for authorizing the request.
The thinking has evolved considerably since the original reference was made. This is the right way to refer to this concept.
So the re-request review button doesn't appear to work; NAME any objections to landing this with the new reference target?
The current reference is in the WHATWG "infra standard": URL To use this, we need to ask for the "tracking-vector" anchor to be made permanent.
URL filed. I have changes for a pull request .
I'm a bit surprised you chose infra; the fingerprinting guidance document in the W3C is much more complete. There are also tons of academic references that have better descriptions; to start, Eckersley's original paper.
I was looking for a direct replacement, which is what that is. I can cite URL if you think that is better. Or URL if that makes more sense. I never know which is better.
Probably the TR - whatever bibxml says, I'd think.
I'm going to go with something simpler. RFC 6973 has an adequate definition.
None whatsoever.
This simplifies the CORS processing language in the doc, leaving all of the client-side readability processing to fetch and clearly spelling out the server responsibilities.
The new language is much better, but I think it still misses the point. We don't need to be shy about why these requirements are in the spec and under what circumstances they are necessary. I suggest starting with an explanation:
Thanks. I pulled in your explanation and tweaked the language to make it clear that precautions should be considered, one of which may be to not use dictionary-based content encoding. I like the new version a lot better as it allows for cacheable, public data to still use dictionary compression even if it is fetched in a cross-origin context and isn't client-readable. I'll have to be careful with the fetch language as, currently, the client will fail a cross-origin non-readable response in case the server hasn't applied relevant protections. It may be reasonable to relax that and allow for the client to process it and put the burden on the server but it might also let a weak configuration go unnoticed (though since attacker-controlled dictionary content isn't particularly practical in this model, maybe it's not really a concern).
For the existing draft, there is a lot of unnecessary confusion regarding features of fetch, like CORS, that don't make any sense from a security perspective. That's not what CORS is capable of covering, nor how it is implemented in practice, so reusing it doesn't make any sense. cc NAME Moved from private ID
CORS covers privacy from a browser perspective as far as the readability of responses relative to the origin of the containing document which is exactly the context that it is needed for here. The concern that it takes care of is to make sure that responses that shouldn't be readable from the document context of the client can't be exposed to oracle timing attacks (because there won't be any client-opaque responses). HTTP itself doesn't really have the same document framing context and need for protecting read access of individual responses on a shared connection by clients running in different document contexts.
From NAME I still don't see how CORS applies to the draft. If the origin is choosing both the available dictionaries and whether or not to apply them to a given response, why is the context of a request relevant to the nature or credibility of the compressed response? Neither one is controlled by the context. The origin server isn't going to attack itself.
The client might choose not to advertise an available dictionary based on the context, but I don't see how ignoring a server's valid response makes a difference. I assume the content of the response after decompressions would still be restricted by CORS, but that should already be defined by fetch; I wouldn't expect this document to specify it.
The concern raised by the security team is that a client could abuse dictionary compression and a timing attack to expose the contents of a CORS-opaque response. The contents themselves would already be prevented from being exposed directly but there's a theoretical risk that an origin serving private data through dictionary compression could expose that data unexpectedly in a cross-origin timing attack. I don't know enough about the practicality of timing-based oracle attacks using dictionary compression and the level of control that an attacker would need to have on either the payload of the response or the payload of the dictionary but in an abundance of caution we are recommending that servers avoid the problem entirely and don't use dictionaries in cross-origin opaque responses (even if it would be blocked from being processed in the client).
The shared-brotli draft has a fairly good write-up on the CRIME attack concerns which is what the CORS mitigations prevent (by making sure there is no mix of public and private data and only allowing for public data): URL Most of the CORS protections are on the client side and not something that needs to be exposed to HTTP or for origins to be concerned about. If a server never mixes public and private data or doesn't talk to a client that needs to partition that kind of data (i.e. not serving to a browser) then it can also ignore the one remaining case called out in the spec. If there's a chance that public/private data will me mixed AND the server is serving content to a browser (or other client that implements CORS) then there is a risk of a timing attack being able to reveal the private content if the crossorigin not-allowed case uses dictionary compression.
Closing this as the need for CORS for the client protection should be well documented at this point (and mostly applies to the WHATWG side of things in fetch processing but there is one case here where people should at least be aware of a possible attack vector if not handled).
I have no problem with this being a requirement for the fetch implementation (or for script-enabled browser implementations in general). However, I still don't understand how the requirements in 9.3.2.
* will pass muster for the IESG and RFC Ed reviews without a normative reference to the Fetch spec. A link to a web page isn't enough. Personally, I think these details should be moved to the fetch spec (where the right people will read it). The bits needed for the IETF are covered in 9.3.1 and the first two paragraphs of 9.3.2: and then everything else in 9.3 (and below) can be a replaced by a non-normative reference to fetch. Otherwise, this should be a normative reference and the several links to fetch replaced with an appropriate [FETCH] entry in 11.1.
To be clear, I don't object to moving forward with this as is, but I don't believe will be allowed as is, unless the chairs have some extra special hand-waving skills I haven't seen yet.
I almost take that as a challenge...
There is processing model stuff that is browser-specific that will be in fetch but the parts in 9.3.2.1 and 9.3.2.2 are the things that are required from any HTTP server that might be used to serve sensitive information to a browser. I stripped out as much as I could but there is a timing attack that can be performed in fetching cross-origin content that would allow a client to "read" the response even if it doesn't have access to it on the client side and the only way to prevent it entirely is to not serve a response in the first place. By making it only a requirement when the CORS headers are present, it allows servers that never talk to browsers to not have to consider it but it really does need to be considered carefully for any server that might serve responses to a browser (or anything else that implements cross-origin readability restrictions). Making the protection non-normative would make the privacy protections optional and risk servers not being aware or necessarily implementing it (and it is the same side-channel timing attack that killed SDCH). If we're comfortable making that change then I can make the fetch spec parts authoritative about the CORS restrictions on both clients and servers but it would probably have to be a normative reference.
Oh, I see, the server description contains things a server MUST do (or not do) based on the values received in those fields when they indicate a cross-origin request.
I was reading them as things a client would verify after receipt of the Response, since we usually don't rely on a bad client sending "I'm good" information in request header fields. [BTW, this is why the main HTTP specs always target requirements to a role instead of making them neutral requirements on a message.] In that case, these are definitely normative requirements, similar to conditional requests. HTTP servers don't normally parse CORS header fields, since pre-flights and such are handled by back-end applications (not httpd).
I'll make another pass over the CORS language tomorrow to make it clearer and make sure it only covers the parts that servers need to handle for fetch-compliant clients. The client bits can and should be in fetch.