What I think was unsaid in Christian's reply was that the checks necessary to enforce this require state that an endpoint might not retain. I'm not clear about the exact test cases here and whether it would be reasonable to expect that an endpoint remember the values that are being duplicated. But that seems to be the source of the observed behaviour. Happy to be corrected if this is wrong.
My implementation of NEW_CONNECTION_ID in neqo, which hasn't landed yet, will only reject a duplicate value if it duplicates an active value. Remembering more values requires an arbitrary amount of additional state. I would expect similar behaviour from other implementations. neqo currently doesn't do anything with NEW_CONNECTION_ID, it just throws them away without looking at then. So these results are unsurprising. I think that the fundamentals here are important to examine though. If you are communicating with a peer that has no interest in protecting your privacy, there are many covert channels available to it that would allow it to exfiltrate your information. The spin bit works well for that. The endpoint can also, at some cost, implement packet number skipping or reencoding so that the ciphertext carries a low bitrate signal. IPv6 flow labels, which an adversary could write to, and which most endpoints are not checking are a very easy channel to exploit. Timing of packets is noisy, but probably usable. The possibilities seem endless. So we have to assume that your privacy - with respect to use of connection IDs, and in most other respects - is at the mercy of your peer. I don't think that we have any system that would prevent them from doing bad things (if such a thing exists or could exist, please contact me; I will do what I can to support credible ideas that need research). We have tried to build a protocol in which it is as easy as possible for an endpoint to do the right thing, we might even have a few places where it is hard to do the wrong thing and evade notice, but that doesn't mean that we can guarantee compliance. In light of that, I don't see any problem inherent to the specification. Unless it is to say that protecting privacy requires cooperation from both endpoints. Maybe that isn't well-enough understood that it can remain unsaid, I don't know. Cheers, Martin On Fri, Nov 13, 2020, at 10:41, Christian Huitema wrote: > The *spec says "**If an endpoint receives a NEW_CONNECTION_ID frame > that repeats a previously issued connection ID with a different > Stateless Reset Token or a different sequence number, or if a sequence > number is used for different connection IDs, the endpoint MAY treat > that receipt as a connection error of type PROTOCOL_VIOLATION." This is > a "MAY", and it is not surprising that some implementations have > stricter checks than other.* > > *Note that clients may well send a single ***NCID with the same value > as the client generated SCID. That's not a protocol violation.** > > **-- Christian Huitema ** > > * * > > *It does not test against the * > > On 11/12/2020 8:36 AM, Kashyap Thimmaraju wrote: > > * * > > > *Dear QUIC WG,* > > > * > > I’m Kashyap Thimmaraju, a postdoctoral researcher at Humboldt University > > Berlin. Recently I discovered a couple of attacks with the QUIC protocol. > > Lars Eggert recommended that I share my findings with the WG to discuss the > > impact and relevance of these findings. > > > > > In this email I’ve described my work on the new connection ID (NCID) for > > server implementations. > > > > > ANALYSIS > > > The draft does not specify how servers should handle new CIDs (NCID) where: > > > 1. All the NCIDs are the same as the client generated SCID > > > 2. All the NCIDs are the same as the client generated DCID > > > 3. All the NCIDs are the same but different from the client generated SCID > > and DCID > > > > > EVALUATION > > > The primary goal of my evaluation is to observe how implementations behave > > to the 3 test cases outlined in the analysis. To conduct this experiment I > > adopted the following methodology. First, I created a client that uses > > deterministic CIDs for the source and destination CIDs and the NCIDs (I > > modified LiteSpeed Technologies open-source QUIC client). Second, I used 15 > > implementations from those listed on the QUIC Working Group’s GitHub page1: > > either manually built Docker containers or the public test server. The list > > of servers tested are shown across the rows in the table below. To conduct > > the experiment, I always had the client open a QUIC connection with source > > CID 1 and destination CID 2. The NCID that was then used was either all 1, > > or all 2, or all 3. The connection was kept open (if possible) for a > > maximum of 10s with the server, and then closed. I saved the debug logs of > > the client, packet traces and session keys. I then repeated the process for > > each of the 15 implementations. Finally, to obtain the results of the test, > > I searched the debug log of the client or the packet trace to confirm > > whether the QUIC connection obtained a successful handshake or not. If not, > > I collected any error messages. > > > > > RESULTS > > > The results from my evaluation are shown in the table below. In particular, > > I found that either the handshake succeeded or the handshake failed due to > > a PROTOCOL_VIOLATION, Error Code: 10 message from the server. When I had > > tested this on quant early on, çase a resulted in crashing the server (see > > https://github.com/NTAP/quant/issues/68). The difference in behaviours > > raises the question on how servers should respond to such messages and what > > amount of detail should be provided in the reason of the error message. > > > > > TEST CASE : HANDSHAKE COMPLETED : PROTCOL VIOLATION > > > A : Aioquic, Cloudflare, Neqo, Nginx, Pquic, Akamai, Ats, Chromium, F5, > > Quinn, Mvfst : Lsquic, mvfst, ngtcp2, picoquic, quant, quicly > > > B : Aioquic, Cloudflare, Neqo, Nginx, Pquic, Mvfst : Ngtcp2, picoquic, > > quant, quicly > > > C : Aioquic, Cloudflare, Neqo, Nginx, Pquic, Akamai, Ats, Chromium, F5, > > Quinn, Mvfst : Lsquic, ngtcp2, picoquic, quant, quicly > > * > > Sincerely, > > -- > Dr.-Ing Kashyap Thimmaraju > > Lehrstuhl für Technische Informatik > Institut für Informatik > Humboldt-Universität zu Berlin > > Besucheranschrift: > Rudower Chaussee 25, 12489 Berlin > Haus 4, 3. OG > > > [email protected] > > > http://www.ti.informatik.hu-berlin.de
