Subject: QUIC-LB update: Eliminate block ciphers?

From: Martin Duke <[email-masked]>
Date: Mon, 4 Oct 2021 13:20:45 -0700

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

---

From: Antoine FRESSANCOURT <[email-masked]>
Date: Wed, 6 Oct 2021 09:25:47 +0000

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

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

---

From: Ian Swett <[email-masked]>
Date: Wed, 6 Oct 2021 05:57:44 -0400

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-masked]> 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-masked]] *On Behalf Of *Martin Duke
> *Sent:* Monday, October 4, 2021 10:21 PM
> *To:* IETF QUIC WG <[email-masked]>
> *Subject:* QUIC-LB update: Eliminate block ciphers?
>
>
>
> Hello QUICWG,
>
>
>

---

From: Martin Duke <[email-masked]>
Date: Wed, 6 Oct 2021 09:32:36 -0700

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-masked]> wrote:

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Oct 2021 14:13:23 -0400

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

---

From: Christian Huitema <[email-masked]>
Date: Wed, 6 Oct 2021 13:02:14 -0700

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Oct 2021 16:16:23 -0400

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.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 07 Oct 2021 09:12:46 +1100

> Your review of that algorithm would be appreciated.

Christian,

I would call this a Feistel network, but avoid talking about FFX.  FFX has a bunch of guidance about the number of iterations of the network that this ignores; to call this FFX or even imply that it is FFX isn't really fair.  When you get right down to it, the real contribution in FFX is the analysis that produces guidance on the number of iterations and the inclusion of tweaks; if you use neither, then it's not really FFX.  As additional iterations are necessary to maintain a security level, we need to be careful about the claims we make in relation to security.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Oct 2021 19:20:36 -0400

I think this is a different cryptographic construct and we should create a
name for the generic. Something like Keyed Permutation.

Rather than bikeshed the name here, I propose taking it to either CFRG or
the Cryptography list (or both) to socialize the concept. It is quite
possible that there is a prior nomenclature we should follow.

It is not clear to me what the precise security properties required here
are. For my particular application, they are fairly weak because I am only
providing some traffic analysis resistance. I am not interested in
plaintext recovery attack, but I do care about the attacker being able to
discover that E(n), E(N+1) are a sequence.

None of my systems are going to collapse if this primitive is broken but it
might afford a foothold.

On Wed, Oct 6, 2021 at 6:13 PM Martin Thomson <[email-masked]> wrote:

> I would call this a Feistel network, but avoid talking about FFX.  FFX has
> a bunch of guidance about the number of iterations of the network that this
> ignores; to call this FFX or even imply that it is FFX isn't really fair.
> When you get right down to it, the real contribution in FFX is the analysis
> that produces guidance on the number of iterations and the inclusion of
> tweaks; if you use neither, then it's not really FFX.  As additional
> iterations are necessary to maintain a security level, we need to be
> careful about the claims we make in relation to security.
>
>

---

From: Martin Duke <[email-masked]>
Date: Wed, 6 Oct 2021 16:27:59 -0700

If the Block Cipher goes away, this will simply be the "encrypted" method.
No need to bikeshed the name for now.

On Wed, Oct 6, 2021 at 4:21 PM Phillip Hallam-Baker <[email-masked]>
wrote:

> None of my systems are going to collapse if this primitive is broken but
> it might afford a foothold.
>
>
>> I would call this a Feistel network, but avoid talking about FFX.  FFX
>> has a bunch of guidance about the number of iterations of the network that
>> this ignores; to call this FFX or even imply that it is FFX isn't really
>> fair.  When you get right down to it, the real contribution in FFX is the
>> analysis that produces guidance on the number of iterations and the
>> inclusion of tweaks; if you use neither, then it's not really FFX.  As
>> additional iterations are necessary to maintain a security level, we need
>> to be careful about the claims we make in relation to security.
>>
>>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 6 Oct 2021 16:44:45 -0700

As for the 'desired properties' of the encrypted method, there are 
basically two:

1- Make it somewhat hard for outsiders to generate connection 
identifiers that the load balancer will find valid.

2- Make it really hard for outsiders to generate or select connection 
identifiers that target a specific server in the farm.

The first one is actually kind of squishy, because it amounts to using 
longer identifiers than necessary, which does not improve performance. 
But in any case, the encrypted design should allow deployments to pick 
their one trade-off there. I do believe that the proposed design meets 
that goal.

The second goal is the key difference between the encrypted and clear 
text methods. I do believe that the current design meets that goal, 
because every bit of output depend statistically on all bits of input. 
But I agree with Phil and Martin that we should get an expert review. In 
fact I did ask the security ADs to help us organize that, a couple days ago.

-- Christian Huitema