Can you elaborate a bit more about what you think the unnecessary complexity here?
A basic source of concern here is whether it's safe for the server to use an initial congestion window large enough to handle the entire PQ certificate chain without having an unacceptable risk of congestion collapse or other negative consequences. This is a fairly complicated question of network dynamics and the interaction of a bunch of different potentially machines sharing the same network resources, and is largely independent of the network protocol in use (QUIC versus TCP). It's possible that IW20 (or whatever) is fine, but it may well may not be.
There are two secondary issues:
1. Whether the certificate chain is consuming an unacceptable fraction of total bandwidth. I agree that this is less likely for many network flows, but as noted above, there are some flows where it is a large fraction of the total.
2. Potential additional latency introduced by packet loss and the necessary round trip. Every additional packet increases the chance of one of them being lost and you
need the entire certificate chain.
It seems you disagree about the importance of these issues, which is an understandable position, but where you're losing me is that you seem to be attributing this to the design of the protocols we're using. Can you explain further how you think (for instance) QUIC could be different that would ameliorate these issues?
For point 1, as I noted here [1], total bandwidth and resources are dominated by large flows. Endpoints are powerful enough to handle these large flows. The primary problems would lie with poor intervening networks and setup overhead.
For point 2, that is a valid concern of any case where you have just plain old more data. This dovetails into my actual point.
The problem of going from a 4 KB certificate chain to a 16 KB certificate chain, 160 KB certificate chain, or any arbitrary sized certificate chain should be equivalent to the problem of "server sends N byte response like normal". To simplify the problem a little it is just: the client sends a R-byte request message, the server responds with the Q-byte response message (which happens to be a certificate chain), the client sends the P-byte actual request, the server responds with a K-byte response message. So, at the risk of over-simplification, the problem should only be marginally harder than any generic "time to Q + K bytes".
Of course, if you previously had a 4 KB actual response and a 4 KB certificate chain and now it is a 160 KB certificate chain, you are going from "time to 8 KB" to "time to 164 KB". That is the essential complexity to the problem. But as I noted in my response to your point 1, the amount of server and client resources actually being expended on "small" requests is small with only poor networks where you are now consuming significantly increased bandwidth being a problem.
This then leads into the question of why "time to 8 KB" versus "time to 164 KB" is viewed as such a dramatic difference. This is a artifact of poor protocol design.
From a network perspective, the things that mostly matter are end-to-end bandwidth, end-to-end latency, endpoint receive buffer size, and per-hop bandwidth/buffering. You have a transport channel with unknown, dynamic bandwidth and unknown latency and your protocol attempts to discover the true transport channel parameters. Furthermore, excessive usage degrades overall network performance, so you want to avoid over-saturating the network during your discovery. In a ideal world, you would infer the transport parameters of every hop along your path to determine your holistic end-to-end transport channel parameters. This is problematic due to paths shifting or just plain dynamic throttling, so you will probably only limit yourself to "client to common bottleneck (e.g. your router) path" and "common bottleneck to server path". The "client to common bottleneck path" is likely client controlled and can be safely divided and allocated by the client. The "common bottleneck to server path" is not efficiently controllable by the client so requires safe discovery/inference.
The "initial congestion window" is a initial bandwidth-delay product to avoid over-saturating the network. This does not directly map to the transport parameters that matter. What you actually want is a initial safe "end-to-end bandwidth" which you refine via the discovery process. The latency of your roundtrip then only matters if the endpoint receive buffer size is too small and only effects how quickly you can refine/increase the computed safe "end-to-end" bandwidth.
Under the assumption that a 16 KB "initial congestion window" is fine and we assume the default RTT is ~100 ms (a somewhat reasonable assumption for geographically distributed servers who want to minimize latency) then that is actually a initial safe "end-to-end bandwidth" assumption of (16 KB / 0.1 s * 8 B/b) = ~1.3 Mb/s. Assuming the client advertises a receive buffer large enough for the entire certificate chain (which it absolutely should) and there are no packet losses, the client would get the entire certificate chain in ~(1 s + RTT) in the worst case. Note how that has only a minor dependency on the end-to-end latency. Of course it could get the data sooner if the bandwidth gets refined to a higher number, and a lower RTT gives more opportunities to get refined to a higher number, but that bounds our worst case (assuming no packet loss) to something that is not really that bad especially for the poor network throughput that we are assuming.
This then makes it obvious how to improve this scheme by choosing better initial estimates of "end-to-end" bandwidth or actively communicating that information back and forth. The "client to common bottleneck path" can be "controlled" by the client, so it can allocate bandwidth amongst all of its connections and it can set aside bandwidth on that leg for receiving. This allows higher initial "end-to-end" bandwidth assumptions that can be safely clipped when the client realizes it is in bad network conditions such as plane wifi. If the server determines "I have set aside N b/s to the 'internet' for this client" and the client determines "I have set aside M b/s from the 'internet' for this server" then your only problem is if there is a bottleneck in the broader backbone connections between the server and client. You would almost certainly be able to support better initial bandwidth assumptions or at least faster convergence after first RTT if you communicated that information both ways. This is just a example of what and how things could be improved with fairly minimal changes.
And this all assumes that we are even trying to tackle this fairly fundamental root issue rather than what are probably heaps of other forms of accidental complexity like middleboxes just giving up if the certificates are too large or whatever else nonsense there is which is what I am pretty sure is the real impetus by why they want the networking equivalent of wanting the 737-MAX to handle the same as a 737.
A few points of technical clarification might help here.
1. The reason for a relatively small initial congestion window (cwnd) is to avoid situations where a lot of connections start up and collectively exceed the capacity of the network, causing congestion collapse. Instead, you start slow and then gradually ramp up, as you learn the available capacity. Slow start started in TCP but it's in QUIC too. Initial windows actually used to be a lot smaller and TCP only moved up to its current 10 packet initial window (IW10) after a bunch of experimentation that determined it was safe.
2. The congestion window is actually a property of the sender, not the receiver. The receiver advertises the size of their flow control window, but that's about the buffer, not the sending rate (see section 7 of RFC 9002 for the discussion of slow start in QUIC). So in this case, the server controls cwnd, no matter what the client advertises (though the server isn't allowed to exceed the client's advertised flow control window).
3. QUIC and TCP behave fairly similarly in terms of the broad strokes of rate control. As I noted above, QUIC also uses Slow Start. The amplification limit you mention is a separate limit from initial cwnd, which is intended to avoid blind amplification attacks, because, unlike TCP, QUIC servers can start sending data immediately upon receiving the first packet, so you don't know that the IP address wasn't forged. However, even if the peer's IP is authenticated, that doesn't mean it's safe to use an arbitarily large initial cwnd.
The problem with this specific design is that it reveals your identity to the site, which is obviously undesirable from a privacy perspective.
For those who are interested one of my recent newsletter posts goes into a fair amount of detail about the various technical options here for using digital IDs in this context: https://educatedguesswork.org/posts/age-verification-id/
In this case the ZKPs are tied to a private key stored in a secure element in the phone, so effectively they are tied to control of the device where the original credential was enrolled.
That's nice and all for the cryptography but now think about what's needed to associate it with the physical attribute (such as the age) of the user of the device which may or may not change hands over time.
The Google system is tied to a mobile driver's license, and there is an identity check at enrollment that is intended to tie the credential to the device. It's true that if you give someone access to your phone without erasing it, then they can potentially use this mechanism to circumvent age assurance. This is true for a number of other age assurance mechanisms (e.g., credit card-based validation).
In any case, I'm not really interested in getting into an argument with you about the level of assurance provided by this system and whether it's "trivial to abuse" or not. I was merely describing the way the system worked in case people were interested.
The suitability of the remedy (ZKP) for the purpose of age assurance is the entire problem. The non-cryptographic aspects cannot be handwaved away as something not worth discussing when they're the primary area of concern here.
You're arguing with something I'm not saying. I didn't handwave anything away or say it wasn't worth discussing. I simply described how the system was designed.
But they must allow some kind of proxy signing so that you can sign in from other devices besides the phone. So how do you protect against misuse of that feature without logging any identifiers?
Running improvement isn't actually like this, except for beginners.
First, you actually do quite a bit of periodization at the season level, so you might have a long base block, followed by a more stamina/quality oriented block, then race specific sharpening, followed by taper and an A race, and then rest. Improvement is distinctly non-linear across these phases, and you'll actually start each season fairly far behind where you were at your peak.
There are also plateau effects, where you've basically adapted as much as you can to an existing stimulus and you need to find new ways of triggering adaptation.
Right. Basically, beginners in any sport are naive to effectively all training stimuli, and so they will respond to a wide variety of inputs.
Once you get adapted it gets harder and harder to find new stimuli that will trigger new adaptation without breaking you down too much. If you're interested in running, Steve Magness and Jonathan Marcus talk about this quite a bit in the On Coaching podcast (https://www.scienceofrunning.com/podcast-2?v=47e5dceea252).
This is actually true for many forms of physical training, including not just strength training but also endurance training (running, etc.) Plateaus and injuries aside, the basic principle of training is overload followed by recovery, and it's not uncommon during the overload phase to have high levels of fatigue and minimal improvement if not regression.
This is something a lot of casual athletes don't notice because there is a very steep development curve for the untrained, so you just getting better very quickly. Once you have been training for years, gains come much slower.
For example, I recently attended the IETF meeting in Montreal--practically the epicenter of v6 thinking--which offers a by default v6-only network. My Mac worked fine, but my son's school-issued Chromebook had glitchy behavior until I switched to the network that provided v4.
A basic source of concern here is whether it's safe for the server to use an initial congestion window large enough to handle the entire PQ certificate chain without having an unacceptable risk of congestion collapse or other negative consequences. This is a fairly complicated question of network dynamics and the interaction of a bunch of different potentially machines sharing the same network resources, and is largely independent of the network protocol in use (QUIC versus TCP). It's possible that IW20 (or whatever) is fine, but it may well may not be.
There are two secondary issues: 1. Whether the certificate chain is consuming an unacceptable fraction of total bandwidth. I agree that this is less likely for many network flows, but as noted above, there are some flows where it is a large fraction of the total.
2. Potential additional latency introduced by packet loss and the necessary round trip. Every additional packet increases the chance of one of them being lost and you need the entire certificate chain.
It seems you disagree about the importance of these issues, which is an understandable position, but where you're losing me is that you seem to be attributing this to the design of the protocols we're using. Can you explain further how you think (for instance) QUIC could be different that would ameliorate these issues?
reply