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
