Re: QUIC-LB update: Eliminate block ciphers?

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

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