That sounds good, but if it isn't a stream cipher, I would change the name.
I will take a look as soon as I have context dumped on my current stack. I have been one bug away from a release for 2 months. On Wed, Oct 6, 2021 at 4:02 PM Christian Huitema <[email protected]> wrote: > Phil, > > What we have in the current LB spec is called a "stream cipher", but > that's a misnomer. What we have in the spec is actually a variable size > block cipher, derived from AES-ECB using a construct similar to FFX. > Your review of that algorithm would be appreciated. > > -- Christian Huitema > > On 10/6/2021 11:13 AM, Phillip Hallam-Baker wrote: > > 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 > >>>> > >>>> > >>>> >
