Re: QUIC-LB update: Eliminate block ciphers?

[Martin Duke <[e-mail]>]

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