jiebi/CodeConvo huggingface dataset:
Taking that into account, how does this effect this issue? Looking at the last paragraph, "Remote attestation procedures are not a replacement for secure authentication, they are based on secure authentication." might be missing vital parts. Does anything need to be added or modified here?
Note that is INCORRECTLY referenced here. Is the resolution of a different issue about HTTPS vs Attestation.
I think comments from NAME do need to be taken into account when the text to address this issue is written. My text in opening the issue is not intended as the text to resolve the issue. Probably the text that resolves the issue needs to refer to "HTTPS plus the web certificate infrastructure that includes public CA's and browsers and/or private CA's used in B-to-B..." or such.
I think the RATS architecture document should probably have text that describes when attestation is applicable and when it is not, for example saying something like “attestation is not a replacement or augmentation for HTTPS/TLS" The design team disagrees with this. Every authentication (including HTTPS) can be said in terms of attestation. It is the verifier that allows the decoupling of the RP to know the expected state of the Attester.
Addresses
The architecture draft uses UDP checksums as an example of a protocol-specific property in Section 3.2 and 4.1.2. I find this a bit confusing because in the Interface draft, checksum coverage is a Generic Connection Property (Section 11.1.2). Should we maybe use a different example of a protocol-specific property, such as the TCP User Timeout we have in the Interface draft?
Sure, we can switch the example around
Thanks, LGTM!Thanks – works
I actually really like: "Simultaneous" and "Staggered" as descriptive terms that avoid the question of "delaying".
Opening this to follow up on a comment by NAME on that is now closed. "Simultaneous" and "Staggered" would be better names than "Immediate" and "Delayed". Just from these terms, I would normally think that "Immediate" means to start racing right away, whereas "Delayed" means that nothing would happen for some time. So these two terms are slightly misleading in my opinion.)
I agree this would be an improvement.
In Section 4.2.1., I didn't really understand what "immediate" means from the text. I think it just needs one sentence.
lgtm (side note - nothing blocking, this is just an idea: to me, "Simultaneous" and "Staggered" would be better names than "Immediate" and "Delayed". Just from these terms, I would normally think that "Immediate" means to start racing right away, whereas "Delayed" means that nothing would happen for some time. So these two terms are slightly misleading in my opinion.)Looks good, thanks! I will close this and open a separate issue for the naming.
Skirts the editorial/design line. Previously, DUPLICATEPUSH referred to a Push ID in a previously-sent PUSHPROMISE frame; that frame would have caused a connection error on arrival. This says that the error should be sent regardless of which frame arrives first. May need reconciling with .
Two questions: Should DUPLICATEPUSH respect max push ID limit? PUSHPROMISE says the following: provided in a MAXPUSHID frame (Section 4.2.8) and MUST NOT use the same Push ID in multiple PUSHPROMISE frames What should a client do if it sees a DUPLICATEPUSH for an ID of a PUSHPROMISE that it never received? This could be caused by a race condition, so it seems sensible to allow this to clients to support this without error. We should probably document that like we did for other racy things. E.g. a Push ID that has not yet been mentioned by a PUSHPROMISE frame.
(2) is covered in : For (1), yes it should -- the DUPLICATE might show up first, but the implication is that the ID has already been used in a PUSHPROMISE frame. If that would be invalid, we should be explicit that the DUPLICATEPUSH is also invalid.
SGTM
I think that we have a frame name problem, otherwise, this is fine.I think some wires got crossed in the suggested changes. Your comment points out that this might need reconciliation with but it seems to borrow the text directly from that PR. The outcome is that this PR is inconsistent with itself because at line the same error with PUSHPROMISE causes a MALFORMEDFRAME. I think the best path is to make this change be a MALFORMED_FRAME error and reconcile on if the group want that change.
There are two ClientHelloInners, the actual one used in the handshake, and the encoded one with outerextensions substituted in. Both are described as ClientHelloInner, but this makes it slightly ambiguous which goes into, say, the handshake transcript. (It's late now, so I'll leave this as an issue without a PR. If we don't end up resolving this separately, I'll probably fix this as part of . If we decide to implicitly copy over legacysession_id, the encryption payload becomes less and less defensibly an actual ClientHelloInner.)
In my own implementation, I've been referring to the plaintext payload as CompressedClientHelloInner. Which is terrible, but unambiguous.
Works for me. I was thinking EncodedClientHelloInner because it's shorter and still works even if you choose not to compress anything. (A no-op encoding is still an encoding.)
+1 to EncodedClientHelloInner, given that compression is optional. NAME if you have time, could you whip up a PR?
I noticed this while drafting a PR for . We're a little inconsistent about whether the ClientHelloInner or ClientHelloOuter is constructed first. Section 4 says inner before outer: Section 5.1 implies inner before outer: But section 6.1 says outer before inner: I think inner before outer makes more sense. You certainly can't finish the outer one before you've computed the inner one. (Of course, an implementation can pick whatever order is most convenient, but I think the spec should be consistent with itself.)
Further security considerations about how message content is protected against manipulation. Perhaps something like this: "Manipulations of message1 may not be detected at reception since there is no MAC but, since message1 is included in TH2, if I and R disagree on message1 then subsequent PRKs and MACs will be different. Manipulations of other messages are detected at reception through the MACs, except for manipulation of the encrypted padding of message2, since PAD2 is not integrity protected."
I made a PR for this
I merged to prepare for submission on -15. is just a simple clarification.
The selfie attack mitigation implies that an initiator is stopping the exchange if it receives its own identity. An active attacker can then use this behavior to test if an initiator identity is the same one as a responder identity. In turn, it implies that the initiator anonymity does not hold against an active attacker when this mitigation is enabled. To judge if this is an issue in practice, the following question should be answered: Are there scenarios where an identity is shared between an initiator and a receiver, but the initiator identity should still be protected? One could maybe think about the case where multiple initiators and receivers are on the same server, sometimes sharing public keys and using distinct ports, but it is expected that the initiators identities are still protected. Possible actions: mention privacy loss due to the selfie attack mitigation. update the selfie attack mitigation, by mentioning that initiators should conclude the exchange as usual, but can check at the end whether they are talking to themselves or not. remove the selfie attack mitigation. Classical selfie attacks are when there is a pre-shared key between an initiator and a receiver, and the initiator will be talking to itself while it believes to be talking to the receiver. When there are only public keys, as in EDHOC, it is unclear to me if what is currently called in the draft is indeed a selfie attack. An initiator talking to itself knows it and does not believe to be talking to some other identity. As such this is why it could be possible to either remove the mention of selfie attacks in the draft, or update it.
I and R are expected to stop the exchange it they receive any identity they do not want to talk to. This likely includes their own identity. Good point that this leaks information. I think that should be added, but I don't see that the own identity is special.
This PR looks good to me.
cTLS enumerates keys in the template, but does not explain how templates can be extended. Suggestion: Clients must reject the whole template if it contains any key they do not understand. The “optional” key holds a map of optional extensions that are safe to ignore.
Thanks for addressing your own issue with a PR. Creating an IANA registry for the keys used in the configuration data makes sense. I would, however, like to point out (and maybe we need to make this explicit) that the configuration information is defined for convenience but is not a mandatory-to-implement functionality for a stack.
Sure, some use cases can pre-arrange, or even hardcode, a specific configuration through a nonstandard channel. Some use cases (where the client and server are developed separately) obviously cannot.
That term doesn't appear above, so don't use it in the PTO section.
Thanks NAME I took your suggestions with one tweak.
Section 6.2.1: "The probe timer MUST NOT be set if the time threshold (Section 6.1.2) loss detection timer is set. The time threshold loss detection timer is expected to both expire earlier than the PTO and be less likely to spuriously retransmit data." What does "MUST NOT be set" means. The time threshold loss detection 6.1.2 only occurs if there is acknowledgement received by the sender sufficient late after the transmission. Thus, PTO timer needs to always be set. because even if Time Threshold timer fires it might not declare a loss.
It means if the time threshold timer is armed, you are not supposed to arm the PTO timer. If the Time Threshold timer fires and doesn't declare a loss, then I would consider that a bug.
So the above text about loss timer is only when one are under the condition created by this Section 6.1.2 sentence? "If packets sent prior to the largest acknowledged packet cannot yet be declared lost, then a timer SHOULD be set for the remaining time." Does the formulation in 6.1.2 need to be improved, possibly naming the timer?
I can see the confusion. This can either be a single timer or multiple, and sometimes we refer to it one way and sometimes as separately named timers, ie "The time threshold loss detection timer" We can either be more consistent about naming the timers or stop naming the timers entirely. Would you prefer the former?
Frankly I don't know which direction that is best. Could I ask you to take an editorial stab on your most preferred. I would guess when you sit down to do either you realize if it will work or not when you harmonize it.
NAME Does PR resolve this for you?
NAME we'd need a response, please
Yes, that simple tweak do make it clearer. So resolved.
The second suggestion is a little risky, but avoids a slightly awkward construction.Editorial suggestion. I'm fine with merging this, but NAME should probably see if it addresses his issue.
NAME you wrote: That sounds like you want to restrict the multipath extension to only one server address (but potentially different paths from different clients address)...? I think this restriction is unnecessary. Yes we don't specify a way to learn server addresses but that doesn't means that the client doesn't know (e.g. based on higher layer information) multiple addresses of the server. What should we restrict that?
However, can we maybe merge this PR as it is for now and you open a separate issue for your additional point NAME ?
Mirja, That was my understanding of the sentences in the PR. Maybe I got it wrong. I think that we should discuss the role of preferred address in section 3 where we explain how paths can be opened.
Fine, let's do it this way.
RFC9000 defines a list of transport parameters. 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 [QUICWG] These transport parameters apply to all the paths that compose a Multipath QUIC connection. We should probably confirm this in the mpquic draft to avoid any misinterpretation (e.g. for maxidletimeout or ack delays). There are two transport parameters that could warrant some discussion: disableactivemigration : This transport parameter is incompatible with enablemultipath. An endpoint that receives both this transport parameter and a non zero enablemultipath parameter MUST treat this as a connection error of type MPCONNECTIONERROR and close the connection. preferredaddress: RFC9000, section 9.2.1 contains the following: Once the handshake is confirmed, the client SHOULD select one of the two addresses provided by the server and initiate path validation (see Section 8.2). A client constructs packets using any previously unused active connection ID, taken from either the preferredaddress transport parameter or a NEWCONNECTION_ID frame. As soon as path validation succeeds, the client SHOULD begin sending all future packets to the new server address using the new connection ID and discontinue use of the old server address. If path validation fails, the client MUST continue sending all future packets to the server's original IP address.
For multipath, do we want to be stronger than SHOULD select one ? Can a client create news paths towards the initial address or only to one of the preferred addresses ? Should the client use both addresses (IPv4 and IPv6) if non-empty ?
Good point about "disableactivemigration". I would read it as also disabling multipath. We do not need to say that "transport parameters apply to all the paths that compose a Multipath QUIC connection". We are already inheriting that property from compatibility with path migration in RFC 9000. Multipath support is an extension to QUIC v1, not a new protocol, so we do not need to specify all the defaults. Same goes for the preferred address -- meaning does not change just because the nodes negotiate multipath. I would avoid debating "which server addresses the client can try" in the base multipath document. If we want the server to signal plausible addresses to the client, let's have a specific document for that.
I would maybe add a sentence that this draft does not change the meaning of preferred_address and if that address could also be used for multipath is out of scope for this extension.
Regarding disableactivemigration: this cannot be a connection error, as you can also send preferred address and after migration to the preferred address you can still use migration or multipath (if negotiated). I think the definition in RFC9000 is still valid; it means you can't send any packets from another address than the one used in the handshake. Which effectively means disabling multipath as well as Christian noted (if not moved to another preferred address). I guess we could explicitly note that this draft does not change the definition of disableactivemigration. For your reference this is what RFC9000 says:
I created a PR in . Is this sufficient to address this issue or do we need to say more? NAME ?
The proposed PR sounds good to me, with the slight addition I mentioned.
This was raised during the Reviewer: Qin Wu Review result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. The mechanism can be further broke down into incompatible Version Negotiation and compatible Version Negotiation. I believe this document is on the right track and but worth further polished with the following editorial comments. Major Issues: No Minor Issues: 1. Section 4 introduce verson downgrade term [Qin]What the version downgrade is? I feel confused, does it mean when I currently use new version, I should not fall back to the old version? Can you explain how version downgrade is different from version incompatible? It will be great to give a definition of version downgrade in the first place or provide an example to explain it? 2. Section 9 said: " The requirement that versions not be assumed compatible mitigates the possibility of cross-protocol attacks, but more analysis is still needed here." [Qin] It looks this paragraph is incomplete, what else analysis should we provide to make this paragraph complete? 3. Section 10 [Qin]: I am not clear why not request permanent allocation of a codepoint in the 0-63 range directly in this document. In my understanding, provisional codepoint can be requested without any dependent document? e.g., Each vendor can request IANA for Vendor specific range. Secondly, if replacing provisional codepoint with permanent allocation, requires make bis for this document, I don't think it is reasonable. Nits: 1. Section 2 said: " For instance, if the client initiates a connection with version A and the server starts incompatible version negotiation and the client then initiates a new connection with .... " [Qin]Can the client starts incompatible version negotiation? if not, I think we should call this out, e.g., using RFC2119 language. 2.
Section 2, last paragraph [Qin] This paragraph is a little bit vague to me, how do we define not fully support? e.g., the server can interpret version A, B,C, but the server only fully implements version A,B, regarding version C, the server can read this version, but can not use this version, in other words, it is partially implemented, is my understanding correct? 3.Section 2.1 the new term "offered version" [Qin] Can you add one definition of offered versions in section 1.2, terminology section? To be honest, I still not clear how offered version is different from negotiated version? Also I suggest to add definitions of accepted version, deployed version as well in section 1.2? Too many terminologies, hard to track them in the first place. 4. Section 6 said: " it is possible for some application layer protocols to not be able to run over some of the offered compatible versions. " [Qin]I believe compatible versions is not pertaining to any application layer protocol, if yes, s/compatible versions/compatible QUIC versions 7.1 said: "For example, that could be accomplished by having the server send a Retry packet in the original version first thereby validating the client's IP address before" [Qin] Is Version first Version 1? If the answer is yes, please be consistent and keep using either of them instead of inter-exchange to use them. s/version first/version 1
NAME NAME please have a look.
We also need to specify server-side HRR behavior, right? Specifically, the server MUST recheck the second ClientHello's ESNI extension before sending the server certificate, otherwise putting the key share into the AD field doesn't really mean anything. The attacker would be able to do a cut-and-paste thing. (We could also incorporate the nonce into key schedule, but that upsets the document's split mode use case.)
Yep! Thanks for bringing that up. I'll prepare text.
Thank you for the text. LGTM.
Minor nit while looking at ; the definition of generic "Long-Header Packets" won't actually match any real packet types, because it ends after the CIDs. This modifies the definition to add a final "Type-Specific Payload" section to the figure.
While the transport draft talks a lot about "1-RTT packets", the term is not defined. We also have a sentence that seem to imply that a long-header variant of 1-RTT packets might exist (URL). We refer to the packet less frequently as "short header packets" or "packet with a short header." As a resolution, I think we might want to change the title of section 17.3 from "Short Header Packets" to "1-RTT Packets". Rest of the text can remain the same, as the first sentence of that section says that it is the only type of short header packet that we define.
So a friendly pointer to detail that could be easily misinterpreted or missed? It seems like a table footnote is required but I'm not sure how to do that in Markdown.
While each frame's description indicates the stream type(s) on which it is allowed, there isn't one unified place to indicate which frames are expected on which streams. QPACK subdivides the instruction space per stream, which has the nice property that you can't put something on the wrong stream. While that's overkill for H3 (too dramatic a departure from H2, multiple IANA registries, etc.), having a table to indicate which frames are permitted on which streams would be helpful.
I like the table idea for both. Want a PR?
Text always welcome.
I'll submit two PRs in next day or so.
Minor nit; otherwise good. Given that we have two frames that fall into this camp, might it be worth doing something like "(*) = only as the first frame"?
The proposed text looks OK to me.
The ID said: “blocking or other interference by network elements such as firewalls” I think this language could be seen as having a little attitude that could be avoided. I suggest replacing “interference”, and instead say that this can change the forwarding policy. This also extends it to include action from QoS policies and service level agreements. “by network elements such as firewalls that rely on the port number for application identification.” I’d prefer “use” to “rely” … because they might well use other heuristics in future if they do prove more useful to classify sessions/packets.
Is the wording in better/good?
note: when merged.
We should probably make it clear what the application can do here (SPA for servers; maybe intentional migration for clients?) I'm not sure if migration is transparent to client applications or not.
The client application might have some knowledge if it's behind a NAT or not and as such might want to indicate to use Conn ID or not. We can make that more explicit in the text.
I did some small edits on the text in the connection migration section but NAME maybe you had something more in mind and want to propose more text?
This whole section should then also be moved to after the Conn ID section.
I like the move of text to the manageability draft. If it were me, I'd move "Server-Generated Connection ID" as well, as I don't think apps need to worry about it, but it's not a big deal. I think adding text about server preferred address is probably more important for this draft.
Added some more text in
NAME we think the current state of the draft addresses this issue; could you check and close this issue if so?
First, these documents can now refer to the published QUIC RFCs. While doing that, let's just replace all [REF] with {{REF}}, which works better for our tooling. Lastly, lets brush up the cross references between documents a bit.
I checked this locally and everything was good. It's easy enough to fix up later if I did break something.
qlog alreaady refers to the -34 drafts. Nominally this change should be easy. Although some section references might need double checking.
lgtm, assuming that the build tool correctly sets the links to the RFCs
I agree with justin here. my bad for missing that.
The 4th bullet on page 64 is ambiguous at "this m= section". It looks like this bullet should just be merged with the previous bullet.
I'm not sure what the problem is here, but I'm not against merging it. NAME
The bullet point in question is the one that reads If this m= section was present in the previous answer then the state of RTP/RTCP multiplexing MUST match what was previously negotiated.
LGTM