Re: QUIC-LB update: Eliminate block ciphers?

[Phillip Hallam-Baker <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> 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=
> >> [e-mail]> 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 <
> >>> [e-mail]> 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:[e-mail]] *On Behalf Of *Martin
> Duke
> >>>> *Sent:* Monday, October 4, 2021 10:21 PM
> >>>> *To:* IETF QUIC WG <[e-mail]>
> >>>> *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
> >>>>
> >>>>
> >>>>
>