I came up against the same issue in a different spec. Stream ciphers appear to be the solution but open up a large attack surface. Stream ciphers are really difficult to get right and formal methods don't always help. There is a tendency to reduce the problem to what can be proved. If you use a stream cipher, you have to rekey for each encryption operation.
Block ciphers are more expensive but they are really hard to mess up. One option is to use a shorter block cipher. I put out a request for shorter block cipher on the Cryptography list and we had a discussion there if people are interested in that approach. Yet another approach is to just use DES which has a short block. Which is obviously insecure for data encryption but this application has weaker requirements. On Wed, Oct 6, 2021 at 12:33 PM Martin Duke <[email protected]> wrote: > Hi Antoine, > > Yes, the configuration agent generates the key in both cases. Sorry this > is confusing; if the block cipher goes away, the entire section will need a > deep editorial rewrite that will hopefully remove the confusion. > > Martin > > On Wed, Oct 6, 2021 at 2:58 AM Ian Swett <ianswett= > [email protected]> wrote: > >> I agree that the Block Cipher is not that likely to be deployed, and >> removing it simplifies the draft. >> >> On Wed, Oct 6, 2021 at 5:26 AM Antoine FRESSANCOURT < >> [email protected]> wrote: >> >>> Hello, >>> >>> >>> >>> A side remark on the Stream cipher and block cipher CID sections. As I >>> was reading both sections, I struggled a bit with understanding which keys >>> were used in each cryptographic operation. The block cipher section tells >>> that the key is generated by the configuration agent and distributed to the >>> LB, but there is no such mention for the stream cipher section. >>> >>> >>> >>> As I don’t have a clear view about how keys are created and managed, I >>> would love to see those concerns answered in the draft (and unfortunately I >>> would only be able to push misinformation myself) >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Antoine Fressancourt >>> >>> >>> >>> *From:* QUIC [mailto:[email protected]] *On Behalf Of *Martin Duke >>> *Sent:* Monday, October 4, 2021 10:21 PM >>> *To:* IETF QUIC WG <[email protected]> >>> *Subject:* QUIC-LB update: Eliminate block ciphers? >>> >>> >>> >>> Hello QUICWG, >>> >>> >>> >>> There has quietly been some recent work on tightening up the QUIC-LB >>> specification. At the moment, we are still short on implementations but I >>> am hearing something might happen soon. >>> >>> >>> >>> Anyway, Christian Huitema has made substantial contributions to the >>> security properties of Stream Cipher CID, which allows smallish CIDs, by >>> making it a three-pass algorithm. We still have the "Block Cipher CID >>> option" which requires CIDs of at least 17 bytes; AFAICT the only advantage >>> at this point is that it can be decoded with 1 block encryption operation >>> instead of three. >>> >>> >>> >>> In principle, QUIC-LB load balancers can be run with no per-connection >>> state, in which case this would be a per-packet operation. I strongly >>> suspect that real LBs will keep some per-4tuple state, as they do today; if >>> so, this crypto operation only needs to occur once per packet where the >>> 4-tuple is new. If so, the CPU impact is vanishingly small except in a >>> storm of garbage packets. >>> >>> >>> >>> So AFAICT, the use case for Block Cipher is as follows: >>> >>> - Willing to run one crypto operation per packet/new 4-tuple >>> >>> - Not OK with doing three crypto operations >>> >>> - satisfied with 17B + CIDs >>> >>> >>> >>> I strongly suspect this does not describe a real implementer, and am >>> inclined to simply delete this option in my effort to simplify the design. >>> Nevertheless, I'm taking this to the list in case someone thinks this is an >>> important use case. >>> >>> >>> >>> This is Issue 138 in Github >>> <https://github.com/quicwg/load-balancers/issues/138>. >>> >>> >>> >>> Thanks, >>> >>> Martin >>> >>> >>> >>
