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 >> >> >> >
