jiebi/CodeConvo huggingface dataset:
I generalized the description. You need to rotate all keys.
I don't have strong opinions about the MUST vs. SHOULD requirement here. The group will have to sort this out
Was wondering whether the cases where keys are never rotated are actually valid. The implication is the following: if an end-entity certificate has an indefinite lifetime then the certificates of the subordinate and CA certificates also need to have an indefinite lifetime. Is this a realistic deployment? If so, can you describe this deployment?
Sitting in the SUITS meeting, the same question of MUST came up. Someone made the comment that the MIST could be required in the doc, but the doesn’t mean a service that doesn’t follow the MIST guidance, can’t physically operate or even interop with other services. It would mean it’s not conformant to informative guidance, and a security review could seem it not as secure. Which might be fine for a locked down, IoT scenario. After the SUITS discussion, I’m fine with a MUST for operational info, that enables a service to function as they deem fit
Keeping with MUST as it doesn't change the compatibility, and a service that doesn't rotate would still be interoperable, and be operationally not compliant.
LGTM!removed the hyphen from cryptoperiodsApproving the MUST text.
Values is correct in the first case, but the second should be "a value" by which it means "any value".
and 10.9: Please confirm that these instances of "value" should not be "values". Original: These include the value of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on the value of secrets is the best defense against any form of timing attack. Possibly: These include the values of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on secret values is the best defense against any form of timing attack.
These should both be "values".
Values is correct in the first case, but the second should be "a value" by which it means "any value".
We are inconsistent with our use of "registered" and "recorded" when referring to the addition of signed statements to the append-only log. I recommend using the term "registered" consistently to refer to this act. This implies that some "process" was applied before registration can occur on the append-only log.
Doing a quick search it seems easy and good to make this change, except one place that looks a bit janky. The current document (draft-08 as released) includes a line: It doesn't quite sound technically right to simply replace the word here because the VDS doesn't register things: there are other bits of the higher level TS involved there. Would it satisfy you in this case to change to: I don't want to mess too much with meaningful text changes and it would be a shame to hold up this issue for one detail. And I think this is strictly better because it also suggests that the VDS doesn't record (or validate, or witness, or any other word we might have come up with) Signed Statements that haven't been registered.
No objections here Jon. Thanks for resolving this issue so quickly. Please close this issue after applying appropriate changes.
URL
Closing as resolved by
LGTM
to
As far as I know, the idea of burning private keys to facilitate repudiation or reduced data value didn't resonate with any of the audiences for whom it was intended. I think the document would be better off without the paragraph copied below from URL And we might avoid some potentially difficult/confusing/painful/etc conversations in various latter stage IETF process steps.
I'm told that my statement that it "didn't resonate with any of the audiences for whom it was intended" might be premature.
I agree with deleting the text about publishing private keys. Yes, it's a technique that could be used with SD-JWTs but it's in no way specific to SD-JWTs. It could be used with normal JWTs, CWTs, SAML tokens, X.509 certs, etc. It doesn't add to the specification to describe this here.
leaving this open with no action for the time being because, as Dr. NAME says, "it's complicated".
agreed to remove.
Allow "." in . Also consistently reorders character lists for key.
I'm getting a high failure rate on parsing (but with a very low number of occurrences; it's not exactly a popular header). The failure seems to occur because of keys like this: Allowing in key would address this, but I'm not sure it's worth the change. Additionally, key currently only allows lowercase alpha; this is mainly to avoid confusion between and , etc. So far this seems to be pretty supportable in cache-control, accept- and elsewhere, with the vast majority of headers seeming to choose the lowercase form. However, it does cause issues in a couple of cases: In , the parameter isn't compatible, leading to a high failure rate for that header In cookies, this makes a number of things incompatible, but it's not clear that we can treat them as a direct mapping anyway.
I have no opinion about dots. As to case, though; I think the options are: say lower-case only – the current option we should probably instruct individual headers' specifications to define how to get into/out of SH, which is harder for extant specs open it up to anycase and be case-sensitive this means that parses to and if someone wants to collapse / they have to do it after the fact open it up to anycase and be case-insensitive still requires instructions for individual headers' specs to define how to get out of SH Incidentally we don't say anything about case for tokens, not that it matters as far as SH is concerned (we never have to compare them.) It might not hurt to say something to the effect that "tokens are case-sensitive so you aren't allowed to change them, but an individual specification that uses sh-token may have special rules for comparing tokens that only differ in case".
WRT lower-case -- I think your analysis is correct; my inclination is to either stay lc only, or to force to LC when parsing textual headers (much like H2 does for field names). WRT instructions for existing headers -- that's out of scope for SH "officially."
Your patch for looks good. Force-lowercasing makes me a bit nervous, because the wire form for h1 will be materially different than what appears in the data model. We'll have to be careful to distinguish between the h1 wire format and the abstract model for keys (which we currently are pretty sloppy about).
More seriously, even if we did force-lc, I realise it wouldn't be possible to round-trip things like includeSubDomains, so it probably isn't going to be useful on its own; there will always need to be some application knowledge / mapping. So, I'm inclined to leave casing in keys as-is.
I don't know what you mean by "force-lowercasing". Is that different from leaving it as-is?
i.e., forcing LC when parsing textual headers, as per above.
Oh, do you mean converting "FooBar" to "foobar" as part of some algorithm? Right, yeah, no, I don't like the idea of coercing data into the model if it can't be round-tripped back out. If an individual header field's spec supports a different data model (e.g. strings), then it's up to that header field's spec to define how to convert their string to an sh-key, and back again. I.e. don't do anything in SH, and punt it to RFC6797bis (or draft-mnot-bsh).
Agreed. Could you make the change into a PR?
It is.
Hi, NAME I think this looks mostly fine (it looks like the abstract is a tiny bit garbled, but we can fix stuff like that in an editorial pass). Based on the changed title, I'm assuming that we aren't worrying about SRT and RUSH in this draft - that's probably a good call, because I don't think their requirements are going to look much like RTP over QUIC requirements. There will be some places that I will need to tighten up what I wrote, because they were still in scope when I was typing. I'll merge this, and see where I end up in an hour or two of typing.
I needed a bit more context for this: I'm probably confused by "The protocol". URL says it provides this authentication using TLS 1.3 handshake. Are you thinking of something in addition to the QUIC cryptographic handshake? (Assuming the definition of "Media Transport Protocol" in ), something provided by the Media Transport Protocol level? Or something else?
Something in addition to the QUIC cryptographic handshake (in which I am talking about TLS mutual authentication here, where client presents a valid certificate to server, and verifies the server certificate). Consider: Existing protocols in this space usually offer some "shared secret" of some variety as part of either/or an authentication handshake, and encryption of media: which are just secret values set in the field during connection handshake (see § 6.4) - but note they also support a cert-based approach which more closely matches TLS mutual auth where the Stream ID and user define the authorisation Before RIST Main profile there hasn't been a need for a lot of certificate-based authentication and so existing folk in field would use these types of shared secret patterns, and that having to keep PKI for devices may be problematic. Consider things like encoding hardware deployed in remote locations. Other options could be considered, like using a more SIP-like approach, but we would have to be careful not to bring the rest of the SIP kitchen sink with its round peg that might not fit in the square QUIC slot. I get this requirement presently is a bit flaky in part because the requirements are a bit unclear. Perhaps I put a little more description on the requirement, or remove it from the draft now, and leave it for a "ask later". Thoughts?
NAME I think (1) adding the explanation that this is beyond the authentication mechanism provided by QUIC, and (2) leaving it in the draft, with a note that more detail is needed, and will be added as discussion proceeds, is all that's needed for now.
Closing this as I think it has been addressed, please by all means speak up if we still should do work here.
I THINK what we are doing, is roughly Start with current "Media - Media Transport Protocol", where "Media Transport Protocol" might be RTP Encapsulate in QUIC, to give "Media - Media Transport Protocol - QUIC" If that's right, we should be using "Media Transport Protocol" to describe the first layer under "Media", and what we're doing might better be described as something like "Media Transport Protocol Encapsulation" ("in QUIC"). Whatever we choose, we should be consistent - the Abstract says which would make me believe that we're designing a replacement for existing media transport protocols, but then under "Non-requirements, we have I think that the second quote is correct, so we just need to be clearer in the first quote.
I agree with this, and it should be fixed. Would you like me to clean it up or do you want to roll it in with other changes?
Hi, NAME would it be OK if you did this cleanup? I think adding the picture of the two protocol stacks, in some form, will be super helpful for readers.
I think we can close this as our nomenclature for the document is kind of done now the -00 is out.
We have been talking about "Media Over QUIC" as a broad term that would include any media transport protocol running over QUIC, which (apparently) would include RTP over QUIC SRP over QUIC RUSH, which runs over QUIC If we are doing "Media over QUIC", all of these (and potentially others) would be in scope. If the scope of this document is "Media over RTP over QUIC", that would be fine, but we should say that. Thoughts?
I think we've fixed this one - I'll close it for now.
For .
[x] 1. ----- FP: Is the working group aware that RFC 793bis is in IESG evaluation (URL) ? Was the choice of having a normative reference to 793 conscious, in order to avoid any delay that might come from publication of draft-ietf-tcpm-rfc793bis? (Just checking this was considered) [x] 2. ----- for HTTP/2 over TLS. The general TLS usage guidance in [TLSBCP] SHOULD be followed, with some additional restrictions that are specific to HTTP/2. FP: Given this requirement, I would have expected to see [TLSBCP] normatively referenced, rather than informatively. [x] 3. ----- layer. The frame and stream layers are tailored to the needs of the HTTP protocol and server push. FP: I would think the server push is part of the HTTP protocol, which makes this formulation "HTTP protocol and server push" confusing. [x] 4. ----- Type: The 8-bit type of the frame. The frame type determines the Flags: An 8-bit field reserved for boolean flags specific to the FP: I would find a reference to the IANA registry useful. [x] 5. ----- implementation of flow control can be difficult. When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion. Failure to do so could lead to a deadlock when FP: "When using flow control" might be rephrased to indicate "when flow control limits are lower than the maximum" (or something of the sort), since if I understand correctly the capability is always used, it is just the window size that changes (effectively implementing control of flow). Also "timely fashion" - I know that it is probably hard, but it would be nice to have a more precise qualification, or at least a hint of what is timely. [x] 6. ----- stream that it successfully received from its peer. The GOAWAY frame includes an error code that indicates why the connection is FP: "error code" - here as well I would have liked a reference to the IANA registry. [x] 7. ----- Exclusive: A single-bit flag. This field is only present if the PRIORITY flag is set. Stream Dependency: A 31-bit stream identifier.
This field is only present if the PRIORITY flag is set. Weight: An unsigned 8-bit integer. This field is only present if the PRIORITY flag is set. FP: I would have expected to see some definition of how the fields are used. If this is defined somewhere else, a reference would be good. [x] 8. ----- SETTINGS Frame { Length (24), Type (8) = 4, Unused Flags (7), ACK Flag (1), Reserved (1), Stream Identifier (31), Setting (48) ..., } Setting { Identifier (16), Value (32), } FP: Is there any reason why the Stream Identifier line is not: Stream Identifier (31) = 0, [x] 9. ----- a server does include a value it MUST be 0. A client MUST treat receipt of a SETTINGS frame with SETTINGSENABLEPUSH set to 1 as a connection error (Section 5.4.1) of type PROTOCOLERROR. FP: This is just my curiosity: what is the reason for this stronger requirement - I would think it shouldn't be a problem for the sender if it wants to advertise that it would permit/support server push. What am I missing? [x] 10. ----- A value of 0 for SETTINGSMAXCONCURRENTSTREAMS SHOULD NOT be treated as special by endpoints. A zero value does prevent the FP: When is it ok that the 0 value is treated as special? [x] 11. ----- set. Upon receiving a SETTINGS frame with the ACK flag set, the sender of the altered settings can rely on the value having been applied. FP: nit s/value/values. Also I believe this could be misunderstood - can it be made more precise on the fact that only the values that are present in the received frame with the ACK flag set (and not those that might have been ignored because not understood) have been applied. [x] 12. ----- A receiver MUST treat the receipt of a WINDOWUPDATE frame with an flow-control window increment of 0 as a stream error (Section 5.4.2) FP: nit s/an/a [x] 13. ----- FLOWCONTROLERROR (0x3): The endpoint detected that its peer violated the flow-control protocol.
STREAMCLOSED (0x5): The endpoint received a frame after a stream was half-closed. FP: would be good to add a reference to the relevant sections. [x] 14. ----- set after receiving the HEADERS frame that opens a request or after receiving a final (non-informational) status code MUST treat the FP: Where is a "non-informational status code" defined? [x] 15. ----- FP: Are the following two sentences in Section 8.1.1. in contraddiction? request or response. Malformed requests or responses that are detected MUST be treated as a stream error (Section 5.4.2) of type PROTOCOLERROR. on the remainder of the request being correct. A server or intermediary MAY use RSTSTREAM -- with a code other than REFUSEDSTREAM -- to abort a stream if a malformed request or response is received. FP: In section 5.4.2. I read: An endpoint that detects a stream error sends a RSTSTREAM frame So the first sentence above implies RSTSTREAM MUST be sent, while the second sentence states RSTSTREAM MAY be sent. [x] 16. ----- their definitions in Sections Section 5.1 of [5.1] and Section 5.5 of [5.5] of [HTTP] respectively and treat messages that contain FP: References need fixing. [x] 17. ----- from the control data of the original request, unless the the FP: nit Remove one "the" [x] 18. ----- Note that request targets for CONNECT or asterisk-form OPTIONS requests never include authority information. FP: Please add a reference to 7.1 of [HTTP] as this is the first time "asterisk-form OPTION" appear in this document. [x] 19. ----- Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams. This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. FP: Do these two sentences contradict each other? In the first sentence I am reading that the server can't create the necessary stream to send the PUSHPROMISE frame, in the second sentence I read that it can? [x] 20.
----- on a DATA frame is treated as being equivalent to the TCP FIN bit. A FP: Can a reference be added to the section where the TCP FIN bit is defined? [x] 21. ----- Content-Type: image/jpeg ==> - ENDSTREAM Content-Length: 123 + END_HEADERS FP: I think it would be good to add a sentence about the meaning of - and + (which I understand to be flag set or not set) in section 2.2. [x] 22. ----- treated as delimiters in other HTTP versions. An intermediary that translates an HTTP/2 request or response MUST validate fields according to the rules in Section 8.2 roles before translating a message to another HTTP version. Translating a field that includes FP: is "roles" supposed to be there? [x] 23. ----- The CONNECT method can be used to create disproportionate load on an proxy, since stream creation is relatively inexpensive when compared FP: nit s/an/a [x] 24. ----- FP: I think it would be good to keep the 3rd paragraph in Section 11 instead of asking the RFC Editor to remove it, just to keep a trace of the registries that have been defined in 7540, since those registries will now reference this document, but this document does not contain all the definitions of the different fields. [x] 25. ---- Comments: Obsolete; see Section 11.1 FP: I would suggest to be explicit and add "of this document" (unless links can be maintained in IANA registries Comments fields).
All done, closing.
Proposal for
Taking Mark's base, taking Herve's suggestions and removing some text. I think that this is good.
Folks in the Tor community point out that coalescing connections is a genuinely new vector for tracking users in HTTP/2. This should be pointed out in the Privacy Considerations subsection of Security Considerations, along with mitigations. While we're there, more specific text about mitigating HTTP/2-specific fingerprinting would be nice.
NAME I've marked this as Design, but I think we can prepare a proposal pretty easily. You want to take a crack at it, or should I do a pull?
I'm happy to take input. Since I'm basically offline this week, getting a start would help lots.
Marked as editor-ready; please consider list feedback.
: We had trouble parsing this sentence. If the suggested text is not correct, please clarify what prevents cookie-pairs from being sent on multiple field lines. Original: This header field contains multiple values, but does not use a COMMA (",") as a separator, which prevents cookie-pairs from being sent on multiple field lines (see Section 5.2 of [HTTP]). Suggested: This header field contains multiple values but does not use a COMMA (",") as a separator, thereby preventing cookie-pairs from being sent on multiple field lines (see Section 5.2 of [HTTP]).
We have an expectation that media itself is encrypted between a client and a server. We have identified a need for MOQ relays to have access to at least some, but perhaps not all, media metadata, in order to make forwarding decisions. So, for instance, timing metadata, but not names of media. If we intend to support media translators as well, the media translators will also need access to the media itself. It would be useful to be clear about what security relationships will be needed in various deployment architectures.
I think this is dependent on the conversation about MOQ entities and their functionalities, and what they need access to, in order to perform their functions, that we're having (especially starting at the January MOQ interim).
Note that there's one more reference to pragma remaining, but that will be taken care of by .
... is still hanging around, and even less relevant. We still recommend sending it in certain circumstances; can we drop that?
Specifically: [ ] In Constructing Responses from Caches -- although see [ ] In Pragma, "When sending a no-cache request, a client ought to include both the pragma and cache-control directives" [ ] In Pragma, "When the Cache-Control header field is not present in a request, caches must consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present" Proposal: Change s registration status to "obsoleted" Remove requirements relating to it. Retain text explaining its semantics, and note that it's superseded by .
BTW, I'm comfortable doing this because we're getting rid of requirements on request CC anyway -- see .
I have a few editorial changes to suggest here to make it more readable and remove the trailing note, but it is probably easier to commit this as is and we can tweak it later.
Bits seem to be numbered from 1 to N, which is very confusing since almost every software starts at zero. Also it's common to find macros like : #define BIT(N) (1 << (N)) and here that would introduce mistakes since one constantly has to think about shifting bits before using the macro (eg: BIT(3) to check bit called "4" in the spec, corresponding to value 0x8). Since there are not that many places where this happens, this commit aims at fixing them. Note that the hexadecimal values for each of them were already correct and non-ambiguous.
This text: URL a condition on the conformance requirement that suggests that clients that do know the server will support HTTP/1.1 (or later) can do something else. But it doesn't really address what constraints then apply. I think that this was just to permit the use of the chunked transfer encoding for delimiting the message body, but that does not follow. I think that this might be rephrased as follows:
It reads the same to me, but +1.