jiebi/CodeConvo huggingface dataset:
This change is primarily editorial and includes the following changes: Replace references to "Prio" with references to a generic VDAF. (This section was written long ago when we had Prio in mind.) Elaborate on known issues for collect requests. Discuss Sybil attacks, including enumerating the different types ().
From dkg in Vienna:
It seems like there are a bunch of assumptions about Sybil attacks generally that are not well articulated yet. This would certainly help.
The list of attacks is really a list of things we ought to fix in the protocol, so I would not even bother including them in the security considerations. If we want to use this as an opportunity to identify open issues that need to be addressed before we consider the protocol secure, I would simply list the open issues and keep discussion in GitHub. (That is, the text here seems redundant with the issue )
In , NAME noted that the concatenation approach used to combine multiple PSKs is not well validated. At the 2021-10-04 interim, we discussed moving from this approach to a "cascaded HKDF" approach, with the idea of doing the same thing here as the main key schedule. This PR implements that suggestion. One nice implication of the algorithm here is that when there are no PSKs, it produces the zero vector as a degenerate case. So you could implement it pretty cleanly:
The spec currently doesn't distinguish much between an external and a member commit w.r.t. how proposals by reference are handled. In theory, the server could keep track of proposals and send the external committer all proposals that were sent up until the time they want to commit externally. However, there are a few difficulties in committing proposals by reference in an external commit. Membership tags: The external committer doesn't have the ability to verify membership tags on proposals. This is probably not a show-stopper, as proposals still need to be signed by a group member, but if nothing else, this should be noted in the spec. Leaf positioning: The spec was changed such that the committer is added into the tree without an Add proposal being present. If there are other Add (and Remove) proposals present, it is unclear in what order they should be processed. Should the committer be added when the path is processed? Or should it still be processed as if it were an Add? There are probably other things that can go wrong when committing referenced proposals externally, but those are the first that come to mind. The simplest solution would be to simply ignore proposals by reference, although this would break the current principle that a commit must always include all valid proposals that were sent during the epoch. The consequence would be that Parties that sent proposals will have to re-send them if the epoch is ended by an external commit. It should be noted, that a Preconfigured sender will have no way to detect if their proposal was committed or not.
I'm not sure your worries here are very real: Membership tags: I don't think the membership tag issue matters, because the existing members will reject the proposal (and thus the commit) if the membership tag is invalid; at worst the joiner gets themselves wedged into a group by themselves.
And as you say, they're signed, and they keys can be tied back to the tree hash in the GroupInfo. Leaf positioning: We need to clear this up regardless of proposals-by-reference. It seems like basically having a synthetic Add at the beginning or end of the proposal list would work fine. Preconfigured proposer: This is a problem only when Commits are encrypted, so it's not a problem in the external commit case (since an external Commit cannot be encrypted). Nonetheless, the point that an external joiner can't fully verify a Proposal seems to argue pretty strongly for forbidding proposals by reference. I don't think this even violates the semantic of "include all valid proposals received in the epoch", since (1) that requirement is receiver oriented (it's not enough for the proposals to have been sent) and (2) the external joiner can't tell if the proposals or valid. Overall, I would lean slightly toward removing proposals by reference. And if we do that, it might even make sense to just define an ExternalCommit message that packages together the few things that are still allowed.
I'm not sure I understand how the receiver-orientation of the "all valid proposals must be included" rule matters to its application to this case. If we remove the requirement for external commits to include proposals by reference and don't soften that rule to exclude external commits, receivers will consider all external commits invalid in the presence of valid pending proposals by reference. In any case, I'm also in favor of keeping it simple and restrict the External Commit to a few, well defined components that do not include any proposals by reference.
Discussion on working call: "No proposals by reference" kind of follows from "all valid proposals", since the joiner can't necessarily determine that proposals are valid Maybe allow attempts? Might not get feedback to retry, though. Whole point of external commit is to allow async. Agreement to prohibit proposals by reference in external Commit
I believe there's a small mismatch between the text and the Key Schedule figure. The text says that if there are no PSK proposals, the should be a zero-length string, while the Key Schedule figure seems to indicate that it's a string of zeros of length .
Fixed in
One brief comment, otherwise looks good!
Another attempt to group related concepts in this section which hopefully (This is technically design, because previously-required server behavior is now only recommended.)
Why do I have to explicitly cancel after GOAWAY? Given that GOAWAY already tells the client this, what's the point?
GOAWAY tells the client that those requests aren't going to be serviced, but the streams will continue to exist. If the cleanup period is significant, having the streams open is a bad idea. However, attaching SHOULD to this is unnecessary, I think that we might instead just note that clients are free to do as they please with streams that won't be answered.
Discussed in Tokyo; this doesn't need to be required server behavior, but recommended (or RECOMMENDED) as a method to clean up state. Should have a reminder cross-reference to request rejection.
Lgtm now
Align with the latest VDAF draft. This requires two minor protocol changes: 02 added a value called the "publicshare" to the VDAF syntax. This is to support Poplar1 (and likely other schemes that need a similar extractability property). To accommodate this, the publicshare field has been added to the Report and ReportShare structures and appended to the AAD for input share encryption. (This may end up being useful for privacy.) 02 added the report count to the aggregate result computation. This is already passed to the Collector in the CollectResp, so we just need to update the aggregate result computation in the draft to match.
Rebased and pushed a minor update: The public share in Report and ReportStore now both have the same length prefix.
Rebased.
This will be VDAF-02 or 03, depending on when we need to cut DAP-02.
VDAF-03 is out, I will send a PR by end of week. URL
Is that not implied by the text here?
Kind of, but this text talks about the sender's perspective. Furthermore, checking for duplicates is inherently racy if you're using tokens for new connections while the old connection is still alive.
You know, I think that I put some proposed fixes for this in c016639e39c with rather than this branch. Moved it over here. NAME you approved , so I hope that moving that commit over here works for you.
Sec 13.2 of QUIC Transport explains what to do for the loss of a packet for every stream type except NEW_TOKEN. IMO it's nice but not critical to repair this loss, but I care less about how we resolve it than that we write it up.
Somewhat related question: Does this section fit better in the recovery draft?
I don't think so. This talks about the repair semantics of these frames, not the process of detecting loss. Recovery doesn't care about the distinction between PING and STREAM when it comes to repair.
LGTM, but do we need some text saying that when receiving a NEW_TOKEN frame, you MUST make sure that it's not a duplicate? Otherwise, a client might just save the token twice, and effectively reuse the token.
Separates for manageability and this PR for applicability
I actually find this sentence weak: "Therefore it is not recommended to use different DiffServ Code Points (DSCPs) {{?RFC2475}} for ... Considering that QUIC v1 as defined has a single congestion controller and recovery handler and don't treat different DSCP values as separate transport flows I would think that this should be stronger formulated. However, I could see that one could provide a bit more context to this DSCP and single QUIC connections vs multiple QUIC streams discussion by referencing Section 5.1 of URL and be explicit about the point that QUIC v1 is similar to SCTP in regards to the issues raised.
I think the new text do work.
Found some minor stuff in the draft, and had two questions (below). If I should send those to the list instead, let me know :) Does an application server have to have a unique keypair? E.g lets say I have multiple application servers sitting behind a load balancer, could I just share the keys used for vapid between them? In 5.2: Why is a MAY? If I, as a UA, create a restricted subscription my assumption would be that that is actually checked, right? If the Push Service is not planning to check it anyway, wouldn't it make sense to tell the UA directly by responding w/ an error at restricted subscription creation time?
The concept of an application server does not define the quantity— it's fine for multiple servers to share a single key. Martin added text allowing additional claims () which further clarifies that it's fine to include more specific information, for example which server created the message, which is useful if the push service has means for dealing with this. (E.g. QoS or analytics.) I don't recall why that's a MAY. We certainly shouldn't forward unauthorized messages for restricted subscriptions to the user. /cc NAME The changes themselves look good, thanks! :)
Thanks for the explanation NAME Should I open an issue regarding the ?
[x] 1. The Reference PPEXT is not cited in the document. seems it could be sited in the into PR [x] 2. I think it would be good to explicitly say that the HTTP authentication protocol is targeted at redemption and the issuer protocol is targeted at issuance. PR [ ] 3. Last paragraph in section 3.2.1 mentions Origin Allow Lists. These allow lists are not specifically mentioned earlier in the document. Can you clarify this. [ ] 4. In section 4.3 and 4.4 is the attester involved in the TokeRequest and TokenResponse messages? Is the attester proxying the communication? It would be good to clarify this in the text. [ ] 5. Section 6 has an incomplete reference. [x] 6. It seems that the Reference to RFC 8446 is not needed. PR [ ] 7. The link - URL does not work perhaps this is the updated one? - URL
It is permissible for a client to do 0-RTT resumption with a NST from one connection and a token from another. This clarifies that a client only needs to associate a token (from a NEW_TOKEN frame) with the server it was from and no additional state, and that a server can't require that a token be from the same connection as the NST in use.
The token is used for deciding whether the server believes the packet it's receiving actually comes from the address it says it's coming from. I could believe a server might trust a client only if it's doing a 1-RTT handshake, but not trust it if it's doing a 0-RTT handshake, so might encode that bit in the token. I don't think the server should be putting more specific bits like "this is the NST that should be used" or "here are the SETTINGS from the previous connection" in the token. If the server doesn't like a token it receives with a 0-RTT handshake, it can send a Retry packet but still continue with the 0-RTT crypto handshake (even though it's now 1-RTT from a transport perspective). I don't see the need for there to be fate sharing between accepting a token and accepting 0-RTT - a server can reject one without rejecting the other. I've created to express the problem statement as an issue.
If you're going to continue with 0-RTT, but not trust the token, why not just limit the amount sent by the amplification factor? The receipt of a Handshake packet constitutes path validation. Also, a Retry doesn't allow you to acknowledge the client's Initial or any 0-RTT packets.
For a 0-RTT resumption in H3, a client needs 4 pieces of state previously received from a server: 1) a NewSessionTicket 2) Transport Parameters 3) SETTINGS 4) a token (from a NEW_TOKEN frame) The last isn't strictly necessary, but without it the server is likely to burn a round trip with a Retry packet to prove the client controls the source address. On a given connection, there is only one server SETTINGS and Transport Parameters, though there may be multiple NewSessionTickets and tokens. The first 3 pieces of state are necessarily required to have come from the same connection.
A NST (from any connection) is needed since without it resumption can't happen. Transport Parameters and SETTINGS must come from somewhere for 0-RTT to be useful; the obvious and currently specified place is the SETTINGS and Transport Parameters that were sent on the same connection the NST came from. There's no such need that the 4th piece of state come from the same connection as the others. The token is used to prove that the client controls the address the packet is purportedly coming from. This can be done separately from any crypto state (in the NST), application state (SETTINGS), or the rest of the transport state (Transport Parameters). For a client to store the state needed for 0-RTT resumption, one possible implementation is to create cache entries containing an NST, TP, and SETTINGS. It's easy to do that where the TP and SETTINGS get duplicated N times, assuming N NSTs were received on a connection. If M tokens were received on that connection, and tokens need to be added to those cache entries, either the M tokens need to be paired to the N NSTs somehow, or all M tokens are in all N cache entries. This introduces noticeable complexity to a client's session cache implementation to correlate unrelated things. It should be clarified that the client doesn't need to associate the token with the rest of the state needed for 0-RTT. has suggested wording for that clarification.
As pointed out in NAME in URL, the proposed change essentially forbids a server from storing SETTINGS in the token. I think I'm persuaded by NAME argument above that we'd better forbid such coordination, as it would be a burden to certain client implementations. OTOH, I think that untying the relationship between session tickets and tokens does open a new issue, see .
I have some editiorial comments, but the design looks fine to me. While we might embed some information related to 0-RTT configuration in QUIC tokens, they would be decryptable and be usable, so we do not think there would be a problem for us (thanks to NAME for checking).A couple of editorial suggestions.
Also covers the PSK part of
Interim 2022-05-26: Ready to go once merge conflicts are resolved.
The collection of structs could be less chatty. Suggest PreSharedKeys is only used once, can be inlined in GroupSecrets Use GroupContext for the internals of GroupInfo
Note: was fixed in In , we did: So only the following remain: Use GroupContext for the internals of GroupInfo
currently described at time of use. In the "Pre-Shared Keys" section, we should just specify that it must always be a fresh value of length The ReInit provisions require , but those for branching do not. Presumably these should be the same? Currently, the processing rules for PreSharedKey proposal says “MUST be external”. This seems overly restrictive; for example, it rules out the scenario in Figure 8. Suggest “MUST NOT be branch/reinit” instead.
This should probably land after . cc NAME
I don't know the answer to this question, but, from the TLS 1.3 RFC: I noticed this while testing with a pre-baked ClientHello that had both extensions. The ECH draft clearly required that the extension be removed, but I wondered about .
Given URL, URL, and URL, I'd say quite the opposite.
Ah, I see text has been added saying it must appear in the ClientHelloOuter. Thanks for the references. I was working from draft-10.
Here's a fun case. Suppose the client talks to a 0-RTT-capable, ECH-capable server. It'll send earlydata + presharedkey in ClientHelloInner, wrap that in some ClientHelloOuter, and follow it up with early data records. Now the server rejects ECH and handshakes with the ClientHelloOuter. But the client has already sent early data, so the server needs to know to skip past it. I believe this means we need to require the client mirror ClientHelloInner.earlydata in ClientHelloOuter, even though it's not actually offering to resume anything. Sending earlydata without presharedkey is slightly weird (if tolerated at all), so we might even want to recommend a fake outer presharedkey. We almost_ don't care about this: the client may as well stop the handshake at server Finished and skip the client Finished flight anyway, for purposes of the recovery flow. However: What's not what the draft currently says If the server rejects ECH, handshakes with ClientHelloOuter, and sends HelloRetryRequest, we do care about the client's second flight getting through. That second case is extra fun because the client-facing server must look for the second ClientHello too.
Wasn't this already the outcome from ? (That is, if the inner CH has a PSK, then the outer one ought have a dummy PSK, too.) As for mirroring earlydata, why can the server not just ignore the application data (as if it received earlydata and decided to ignore it)? Taking a quick look back at RFC8446, the server behavior where clients send application data without early_data is not defined, so are you concerned about that, or something else?
Well, I think we only got as far as MAY in , but yeah I think this is another reason. Regarding ignoring application data, our server implementation only skips early data if there was an early_data extension that we rejected. I believe that matches RFC8446 since it doesn't say to skip application data in general, just that case. And, yeah, that's the concern.
Since this is behavior for the client-facing server, which supports ECH, can't we specify the desired behavior in this spec? That is, we might say that a client-facing server which rejects ECH MUST ignore any early data sent by the server, or something. Would that work?
We could, but then it'd break the nice property that a plain RFC8446 server will handshake ClientHelloOuter without any fuss. This property is great for rollback safety. (Otherwise any ECH server deployment needs to be two-stage, and introduces a lower bound that you cannot rollback beyond.) And elsewhere we've tried to avoid contradicting RFC8446. Yet another option would be to tell the client to retry on certain kinds of errors if it offered 0-RTT in ClientHelloInner, but that's a bit more fuss since retries are often outside the TLS stack. (Besides, the fact that you offer 0-RTT in ClientHelloInner is all but public anyway. While we don't have a cleartext 0-RTT marker[], it's pretty obvious from timing that some post-ClientHello record came before ServerHello.) [] In TCP... I want to say QUIC does, but I could be misremembering.
True! This is fun. :-)
I'm not sure why ignoring stuff is fuss. What's the alternative? To terminate the handshake if the server receives early data? Wouldn't that be more fuss? If RFC8446 doesn't specify what to do in this situation, I'm not sure why specifying it is in contradiction to RFC8446 (as opposed to expanding on it).
I think RFC8446 does say what to do in this situation. Section 5.2 says at the bottom: URL The default for the record layer is that decryption errors are fatal (as it should be).
Early data skipping is an exception to this described in section 4.2.10, and the exception only applies when the server declines an earlydata extension. Oh no, the goal is to ignore stuff. That's what makes the recovery flow work. The issue is that, in RFC8446, servers only ignore the early data if there was an earlydata extension in ClientHello which they declined. Otherwise, it's just a fatal decryption error. In order to meet that condition, ClientHelloOuter needs the early_data extension whenever ClientHelloInner does.
ACK -- thanks for closing the loop!
LGTM
Overall looks good - added some minor suggestions
lgtm
F. Section 4.1.1: Regardless of policy, the application will always try to negotiate BUNDLE onto a single transport, and will offer a single BUNDLE group across all media sections. I think this sentence may be a bit misleading without additional sentence(s) to explain that the actual number of established transport streams will depend on the peer's response to the attempt to bundle.
OK. This could be resolved by adding a final sentence of the form "Of course, the answerer can choose whether or not to accept BUNDLE".
This PR fixes a typo reported by NAME in the "Fields in Order Objects" section. Previously it referred to the listed fields as relating to the "new-account request". This PR changes the text to make it clear they relate to a "new-order request". Resolves URL
Merging based on manual review; CircleCI seems to be busted at the moment.
The section on the "" registry says that "Fields marked as "client configurable" may be included in a new-account request". This seems like a copy-paste-o, and perhaps should say that such fields may be included in a new-order request.
Good catch. I opened URL to fix. Thanks!
Also removes odd MAY when suggesting that a sender can use TCP's pipeACK method. Addresses .
In Recovery-31 there are several references that I judge as normative and not informative ones. Section 7.8: "A sender MAY use the pipeACK method described in Section 4.3 of [RFC7661] to determine if the congestion window is sufficiently utilized." A normative reference necessary to follow if one selects to use the optional method.Sectiom 7.3.2: "Implementations MAY reduce the congestion window immediately upon entering a recovery period or use other mechanisms, such as Proportional Rate Reduction ([PRR]), to reduce the congestion window more gradually." Another case of a suggested mechanism, which if one is to follow it requires one to read that PPR reference. Secondly, why the alternative reference style.Section 8.3: "Markings can be treated as equivalent to loss ([RFC3168]), but other responses can be specified, such as ([RFC8511]) or ([RFC8311])." So RFC3168 is the normative specification for the treat it equal to loss. RFC8511 is the TCP alternative back-off an experimental specification for the alternative. And RFC8311 is the process for performing other experiments with alternative responses. I judge all necessary depending on what one intendeds to do. So to my understanding this results in two downrefs to experimental specifications. I think that is acceptable in the context they are used in this document. But to be tried in IETF last call. However, I think I don't want to generally recommend them to be acceptable as downrefs so I have no intentions to promote them for the Downref registry.
Moving discussion from the PR to the issue. NAME : I'm not the expert on what should be normative, but these were intentionally marked as informative references since they're all TCP specific RFCs. The pipeACK reference in particular seems like an odd one. If this is what the chairs want, then I'm ok with it as an editor, but these choices were intentional. NAME : I see what NAME is saying, but I also see some wiggle room in RFC 3967, Section 1.1: When a reference to an example is made, such a reference need not be normative.