crypto review thread #2 ---------- Forwarded message --------- From: Martin Duke <[email protected]> Date: Thu, Nov 18, 2021 at 1:48 PM Subject: Re: Crypto review? To: Ilari Liusvaara <[email protected]> Cc: Christian Huitema <[email protected]>, Benjamin Kaduk <[email protected]>, Roman Danyliw <[email protected]>
Regarding the non-crypto parts that Christian asked me to reply to: On Thu, Nov 18, 2021 at 3:09 AM Ilari Liusvaara <[email protected]> wrote: > On Tue, Nov 09, 2021 at 08:40:10AM -0800, Christian Huitema wrote: > > Thanks, Ilari. Comments in line. > > > > On 11/9/2021 4:31 AM, Ilari Liusvaara wrote: > > <snip> > > > > - This uses three rounds even with non-even split. That might not be > > > enough. Firstly, non-even split might increase the rounds needed, > and > > > even with even split, fourth round seems to be needed in order to > > > withstand some attacks (those attacks might not be relevant here > > > however). FFX-A2 seems to use a lot more rounds. I do not know why, > > > it does even split and AES should be pretty close to ideal (tho AES > > > is already known not to be quite indistinguishable from ideal, e.g., > > > one can not use usual cipher-to-hash constructs with it), so I would > > > think four rounds would suffice. > > > > There is a discussion in one of the FFX appendices. From what I > understand, > > the 12 rounds recommendation in FFX is based on entropy considerations, > and > > I am not sure I understand that correctly. Each round merges entropy from > > input and key into the rather short target of the round -- say 24 bits > for > > example. Thus, although there might be 64 + 128 bits of input, only 24 > buts > > of entropy are injected, and one would need about (64+128)/24 = 8 rounds > to > > fully inject the entropy. Add the minimum number 3, rounded to 4, and you > > get 12. As I said, I am not sure I understand that correctly, and I am > sure > > that if we did request 12 rounds developers will just not use this > scheme. > > Okay, that does not make any sense. If one has 64 bit plaintext, it is > fundamentially impossible to inject more than 64 bits of entropy per > plaintext. And if one looks at some sort of multi-output generalization, > the entropy injections are much greater than 24 bits. > > And I would think that if 4 rounds is not enough, then that would call > entiere AES into serious question. Christian didn't directly reply to this, but I take this discussion to mean that we believe 4 rounds is sufficient; I have nothing more to add. > > > - How does reverse routing work? QUICv1 does not support server > > > migration (due to attacks), so presumably the server part of five- > > > tuple has to match (unless preferred address is used, but that has > > > its own serious deployability issues). That part is held by the LB, > > > so servers would somehow need to send on behalf of the LB. > > > > The CID are created by the server, and then passed to the clients. The > > clients put them in their packets. The LB reads the CID from the incoming > > packet, decrypts it to retrieve the server-id, and routes the packet to > that > > server ID. LB might cache the CID that have been seen recently to reduce > > decryption load. > > Oh sorry, that was unclear (and not directly related to crypto): > > I was talking about routing packets back from the server: > > - The client needs to see the return packets to come from the LB. Not > just for the client itself: Some NAT boxes will break otherwise. > - The server can not send on behalf of LB. That breaks in presence > of BCP38 filtering, which may be required. > - So the server need send via the LB. So it needs to put the LB > as outer IP in reply packets. But LB needs to put the client as > outer IP for reply pakets for those to reach the client. > - So LB needs to know the client IP. The packets do contain a CID, but it is randomly generated by the client, so LB would have to keep > CID to IP mappings. > - But even that breaks in case of migration (either voluntary or > involuntary), as either the address CID points to changes, or a > new never before seen CID appears. > To my knowledge, Layer 4 LBs are not using inner and outer IP addresses. Either they are NATing the client IP to its server-facing interface address, or they preserve the client IP and the server default-routes to the LB. QUIC-LB is agnostic as to whether the LB has per-connection state or not. It is certainly possible to decode every inbound CID and route it accordingly, or it can just decode the first packet from a 4-tuple and just use the 4-tuple from there. It's early days, but I've heard of implementations that make either choice. If the LB is NATing the client IP, then yes, it will need to keep some connection state, like any other NAT. If the server-LB traffic actually encapsulates the QUIC IP packets in an outer IP, as you suggest, I don't see that there's an issue: the LB simply decapsulates the packet and sends it on its way. > > > > > - If LB routes on SNI (I expect this to be pretty common), any > > > connection with unknown version is unrouteable. It seems the only > > > way to handle that without causing hard failures is for LB to enage > > > in version negotiation on behalf of sever. This presumably requires > > > knowledge of all QUIC versions enabled on the server, and support > for > > > all of those. > > > > The CID encryption scheme is not used in that scenario. The encrypted CID > > will only be used in later packets, after the initial handshake and the > > selection of a server. > > ... And this is another thing not directly related to the crypto. > > What should LB that routes on SNI do if it receives packet with unknown > QUIC version? > > - It can not pass that on, as it has no idea of next-hop. > - Dropping that packet or returning an error presumably causes QUIC to > fail hard. > - Sending back version negotiation might at least allow forward > progress. > - That version negotiation can not have versions the LB does not know > about or versions the backed does not know about. As client picking > any such version causes a deadlock. > - And then one has to disable the LB-unsupported versions on the > server, in order to avoid tripping downgrade attack detection. > I agree that SNI switching interacts poorly with new versions unless those versions are deployed in lock step. That is a property of QUIC versioning, not of migration or QUIC-LB. In the absence of routing based on the packet payload, QUIC-LB does allow LBs to support migration even if the LB never upgrades its supported versions. I have thought about an optional "Suggested CID" frame that would be a message to the client to use that CID for the next connection, so that it would be routed correctly. The use case for that is not clear, however, as you would still need to connect with an earlier version to bootstrap it. Thanks for this review! Martin > > > -Ilari >
