RE: [1904.4 TF] AES-256 only or both AES-256 + AES-128

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Marek,

Designing chips for full functionality at extreme corner-case configurations would make them enormously expensive. At the same time, these chips may never get deployed in such extreme corner case configurations.

For that reason, a lot of resources in chips are designed as common sharable pools. Think about queue memory, MAC learning table, pool of shapers, table of rules, etc. Different users (operators) can decide whether to spread these resources wider and more thinly or narrower and deeper. That is why the spec has statements like this in many places: “The ONU shall respond with the “Insufficient Resources” code <…> to a request to add a new service port entity if the queues <…> cannot be allocated.”

Same is with key memory. Why should the spec require a huge on-chip memory for 512 ONUs if in 99% of cases, operator will only use 64 or 128 ONUs?

On the other hand, to be fair, compared to other constrained resources, the key memory may not be the most critical. After all, 25G-EPON requires much fewer keys than the 10G-EPON, because instead of key per every LLID, now we only need a key per ONU and a key per multicast LLID.

So, let’s scratch that argument that the key memory will be a limiting factor.

Even without the key memory argument, I feel very uneasy to burn the AES-128 bridge and only support AES-256. What if an operator doesn’t have the rest of infrastructure that is needed to support 256-bit keys?

I really don’t understand the argument for specifically precluding the 128 bit keys. I am usually enthusiastically in favor of simplified specifications and not carrying forward any obsolete baggage. But this is different -- AES-128 is not yet obsolete. If the OLT is going to support a mix of 10G-EPON ONUs and 25G-EPON ONUs, the AES-128 will be supported by the chip anyway. The only difference between the 1904.4 supporting and not supporting AES-128 comes to whether we define an attribute for key size selection or not. In other words, the restriction of AES-128 in 25G mode is entirely artificial, and as such, it will only incentivize a vendor to offer the AES-128 at 25G as a proprietary option, contrary to the goals of the standard.

Also, since encryption at the network layer is done on per-hop basis, the fact that older network segments use no encryption or weaker encryption schemes should not preclude us from using stronger encryption. I think we should level up, not down, in terms of security, especially if we can help it.

I agree with this line of thinking by an operator when it plans a deployment and develops the default configuration for the OLT and ONUs. But having an AES-128 as one of the options does not preclude an operator from using a stronger encryption. If the operator has no any technical or regulatory reasons to use AES-128, then they will configure and use AES-256. But if there are any such reasons, the operator will use AES-128, whether it is part of the standard or proprietary option. Or maybe this would be seen as an incentive to switch to a different PON standard that does formally support AES-128.

Glen

From: Marek Hajduczenia <mxhaj79@xxxxxxxxx>
Sent: Wednesday, March 22, 2023 5:08 PM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] AES-256 only or both AES-256 + AES-128

Glen,

I do not know how much the 128b vs 256b selection would impact the OLT implementation cost. You would be better positioned to speak what relative cost increase that would result in on the OLT and ONU side. I would point out, that the need to support both 256b and 128b keys does not lower the memory requirement because you'd still need to support the same number of LLIDs per OLT, irrespective. I do not think the solution like "with 128b keys, we support X LLIDs, with 256b keys, we support X/2 LLIDs" would be really viable as a marketable solution. Operators will expect the same number of LLIDs, irrespective of the key size, at which time, memory demand is the same, ergo the argument on memory saving will not hold then.

As far as the other argument goes - OTT encryption schemes change key size easily, since they are software based, so the fact that most encryption schemes use 128b keys today will not hold true likely in 2-3 years. PON implementation has to last much longer, IMHO, so it is likely that we will see 256b and likely longer encryption keys for OTT services.

regards

Marek

On 3/22/23 17:34, Glen Kramer wrote:

Sorry for the long silence. I had to switch to another project temporarily.

I would like to continue our previous discussion, but focus on one question per thread. Other questions will get their own threads.
This one is about supporting both 128 and 256 bit key or only the 256-bit key. Here is what was discussed earlier (copied from the earlier thread):

….
[MH] I do not see much value in supporting 128b keys if 256b keys seem to be the new norm. Given both supported, I would default to 256b key anyway, because why not. Unless there is some substantial pro of still doing 128b keys, I am not sure what it buys us, really.
[GK] I don’t have a strong argument for continued support of 128-bit key. I thought that it was possible that instead of generating keys in the OLT itself, operators will use some external security server. And that external infrastructure may or may not support 256-bit keys in various head ends. Maybe this is not the case. Just want to observe two things:
1.       The 128 and 256 refers to only the key size. The AES engine itself is always 128 bit wide.
2.       The newest ITU-T PON recommendation G.9804 includes encryption methods with both key sizes: AES-128 (mandatory), AES-256 (mandatory), Camellia-128, Camellia-256, and SM4(-128)
Does anyone have any concerns with not supporting AES-128?
[mh0308] I personally think we should minimize the key size count, not add to the complexity of supporting different encryption schemes. I understand what the driver was on the ITU-T side, but I feel we do not have to deal with that honestly. My vote would be for 256b key only.
[SG] From a risk management perspective, AES 128 is considered sufficiently secure by most authorities at the moment. A lot of SDOs are moving to AES 256, but I think that’s just because they can. It’s my understanding that there is delay added by using 256 relative to 128. However, its small and implementation differences in hardware or software probably matter more than the added number of rounds that AES 256 requires (AES 128 is 10; AES 256 is 14). However, for my part, I tend to want to trust the silicon manufacturers here because implementation matters.
[SG] That said, if we think 256 is more secure, supporting 128 provides a down grade attack path. I so no benefit to requiring 128 if 256 is mandatory and the performance penalty is minimal.

However, I do think now that there are arguments for supporting both key sizes:

1.       With large number of ONUs, the key memory is becoming an issue. For a given memory size, using the 128-bit keys, the OLT can support twice as many encryption flows as it can with 256-bit keys. The keys are usually stored in on-chip memory, because the OLT needs to be able to switch a key very quickly when one envelope ends and another envelope starts, as any two adjacent envelopes can be destined to (or arrive from) different ONUs that use different keys.
2.       256-bit keys in PON segment are unnecessary if the rest of the network still uses 128 bit keys. It is better to use smaller keys and allow more of them.

Steve, the MKA allows the SAK to be either 128 or 256 bits wide. What specifically determines whether the 128 bit or 256 SAK is used? If the size of CAK determines the size of SAK, then what determines the size of CAK?

Thank you,
Glen
To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1

To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1