Mandatory AES for v3 PKESK: AES is not a MUST in RFC4880

[falko-strenzke]

Currently our draft states (slightly revised text in my working branch) for ML-KEM cmposite encryption:

Note that unlike most public-key algorithms, in the case of a v3 PKESK packet, the symmetric algorithm identifier is not encrypted. Instead, it is prepended to the encrypted session key in plaintext. In this case, the symmetric algorithm used MUST be AES-128, AES-192 or AES-256 (algorithm ID 7, 8 or 9).

But this isn't possible with RFC 4880 to which we aim to be compatible here, as there AES-128 is only a SHOULD. The only MUST symmetric algorithm there is TripleDES. So either we require at the same time with introducing PQC that AES-128 becomes a MUST, which seems a bit strange to me, or we have to keep the symmetric algorithm flexible, which would make the most sense in my opinion.

From a practical perspective requiring AES-128 as MUST is most likely realistic. But from a formal perspective it means that a sending client conforming to RFC 4880 and sending an encrypted mail to multiple recipients, some supporting ML-KEM, some not, could come into the conflict of having to use AES-128 for the PQC supporting recipients and TripleDES for the legacy clients. Actually the similar but even bigger problem can happen to a client supporting the crypto-refresh and sending to mutiple clients, since the crypto-refresh even completely forbids TripleDES.

So should we simply assume that clients today all support AES-128?

@TJ-91 @wussler @fluppe2

[TJ-91]

Perhaps a short recap of how it came to the quoted text helps to evaluate the issue:

• When introducing X25519/X448 in the Crypto Refresh, there was an error such that the algorithm identifier byte caused v3 PKESKs and X25519/X448 to be incompatible due to a wrong length for AES Key Wrap (rfc4880bis issue 157).
• One proposal was to keep the identifier encrypted and use padding, the other was, to take it out of the encryption. The second approach was chosen.
• Afterwards, the symmetric algorithm identifier has been restricted to AES due to cross-mode attack concerns (see rfc4880bis MR 276).
• For consistency with the Crypto Refresh, the PQC draft adopted this solution (https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/42)

I think you raise a very valid point and this would have been a good argument against the chosen approach in the Crypto Refresh. The two options I see now:

• Stay consistent with the Crypto Refresh and assume AES is always supported and add some text to address this issue.
• Encrypt the algorithm identifier and add padding, remove the binding to AES.

So should we simply assume that clients today all support AES-128?

I think it's a reasonable assumption but it would be better to have something to back up this claim and justify the decision. I have no clear preference for any approach at the moment.

[wussler]

Stay consistent with the Crypto Refresh and assume AES is always supported and add some text to address this issue.

This is my preferred approach. We use AES Key Wrap, and makes no sense to extend the attack surface by adding TripleDES support (or any other algorithm).

Note that we can just make AES mandatory in this draft, and I would have no issue doing so. Implementing the latest PQC algos to then use CAST5 feels very silly.

[dkg]

I agree with @wussler that just mandating AES here is the only thing that makes sense. This is a weird backward-compatible thing, even bothering with the deprecated PKESKv3/SEIPDv1 approach; it doesn't need to be backward-compatible with every possible historical wart of OpenPGP.

If anyone is aware of an OpenPGP implementation that has any sort of vaguely active maintenance but cannot do AES, please point to it.

[falko-strenzke]

OK, so what remains is to decide whether we add an explicit note somewhere in the draft that with the introduction of PQC, AES-128 is considered to be mandatory to implement. A reference to the crypto-refresh would also make sense here.

[fluppe2]

I would rather specify AES-256 as MUST. Keep in mind that

• the security niveau of AES-128 doesn't match the one for pqc level 3 and 5 parameter sets, AES-128 is NIST level 1
• AES-192 (as a match for the entry level pqc security niveau, i.e. NIST level 3) feels like a peculiar choice, who is using that?
• we use AES-256 for the key wrap anyway.

AES-256 (instead of AES-128) as MUST in the pqc draft feels like the more correct choice to me

[wussler]

Agreed with @fluppe2 I think this is a very coherent choice

[fluppe2]

Yes, I guess "coherent" is the right word here. When it comes to quantum-safety the international recommendation (e.g. CNSA 2.0, ANSSI, BSI) is to use AES-256. So why not just pin AES-256 to the wall.

[TJ-91]

I have two points.

First, Stavros and Aron, you seem to be mixing "per-recipient stuff" and "per-message stuff" up. We do use AES Key Wrap as part of the PKESK packets (for X2559/X448/PQC keys), which are per-recipient. We choose the symmetric algorithm based on the principle of "least common denominator" and it is per-message, meaning, everyone gets the same message with the same encryption algorithm/key.

Also, are we still talking about the backwards compatible issue to legacy (RFC4880) certificates or about generally restricting the algorithm to AES for PQC? If the former, it does not make any sense to me to mandate AES-256 when we aim for compatibility. Remember: This affects all recipients, also the ones that do not have new algorithms and use AES256-KW anyway. If the latter, this is a much more severe change that we have to discuss separately.

Please keep in mind that the choice of the symmetric algorithm is orthogonal to the choice of the public-key encryption algorithm. Even requiring AES-128/192/256 for the PKESKv3 case as we (and the Crypto Refresh) currently do is not really "natural" for the protocol. Or am I severely misunderstanding something?

---

Second, I want to add a new perspective (but no new information) on the TripleDES issue.

In principle, the "Preferred Symmetric Algorithms" have to be honored. There is a mismatch between version standards. The mandatory-to-implement algorithm (TripleDES or AES-128) assures that implementations conforming to the spec will always find an intersection of all recipients' preferences (the mandatory-to-implement algorithm). But this is not the case when interoperating between the two standards.

The Crypto Refresh defaults to AES-128 when no other algorithm can be found in the intersection. It acknowledges the fact that old implementations might be TripleDES-only implementations but does not loosen the prohibition of using TripleDES and still mandates AES-128 (see 12.2. Symmetric Algorithm Preferences). Therefore, the Crypto Refresh overrides the mandatory-to-implement algorithm to be AES-128 and implicitly assumes that even recipients with old implementations implement it.

In summary I think: It's not up to the PQC draft to decide what to do here, since it already follows from the Crypto Refresh. Technically, there is no need to clarify any further but I'd not be opposed to a clarification. The right place for a clarification would be in the Crypto Refresh, however.

[falko-strenzke]

Thanks for the clarification Johannes. I think from this it is clear that we must be careful not to introduce any interoperability issues. Moving to AES-128 as mandatory is in line with the crypto-refresh and thus reasonable, but moving beyond that (i.e., to AES-256) would create interoperability issues.

[wussler]

@TJ-91

First, Stavros and Aron, you seem to be mixing "per-recipient stuff" and "per-message stuff" up. We do use AES Key Wrap as part of the PKESK packets (for X2559/X448/PQC keys), which are per-recipient.

True, indeed here we might be mixing PQ and traditional recipients. This would have definitely been simpler by limiting encryption to v6, but I still see the advantage of having v4 PQC.

Even requiring AES-128/192/256 for the PKESKv3 case as we (and the Crypto Refresh) currently do is not really "natural" for the protocol. Or am I severely misunderstanding something?

Here, I think it's okay. Implementations go forward, and if you are that outdated that you don't support AES, I would blame the person still relying on 3des in 2024.

As @dkg pointed out

If anyone is aware of an OpenPGP implementation that has any sort of vaguely active maintenance but cannot do AES, please point to it.

That I know of, there is no implementation not supporting all flavors of AES.

Re @falko-strenzke

Moving to AES-128 as mandatory is in line with the crypto-refresh and thus reasonable, but moving beyond that (i.e., to AES-256) would create interoperability issues.

I would still be in favor of mandating support of AES-256, and in the long run, when sending PQ-only messages we might be able to enforce it. We'd still allow AES-128 for v3 PKESK, and make mandatory AES-256 support (coherently with PQ requirements and the KW).

[TJ-91]

Here, I think it's okay. Implementations go forward, and if you are that outdated that you don't support AES, I would blame the person still relying on 3des in 2024.

What I meant is that mandating a specific symmetric algorithm that has to be used in combination with a specific public-key encryption algorithm violates the separation that OpenPGP used to have between the two kinds of encryption. Only in the case of v3 PKESK and the usage of X25519/X448/PQC, there is this restriction to use AES. That's what I'm saying is not "natural". It was more of a side node, though.

I would still be in favor of mandating support of AES-256

Even the Crypto Refresh does not mandate AES-256 so that requirement would be incompatible with a client that fully conforms to it. And we'd still have special cases where we use AES-128 so to me it seems inconsistent. I'd be in favor of not changing how the protocol handles the symmetric algorithms too much. Hopefully, most keys will include AES-192 and AES-256 in their preferences anyway. But this should probably be discussed in another issue.

[falko-strenzke]

That I know of, there is no implementation not supporting all flavors of AES.

Yet still, the crypto-refresh did not make AES-256 MUST for some reason, but only SHOULD. Before going one step furhter than the c-r, I would ask the WG about this.

As I understand, we agree that use of AES-256 as the symmetric algorithm can only happen if all recipients are found to support it. If we make AES-256 a MUST for PQC, then, if a recipient has at least one PQC key, this could be used to assert that they support AES-256. Possibly we would want to bind it only to the existence of PQC encryption key.

[TJ-91]

As an alternative to @falko-strenzke's proposal we can simply mandate that AES-256 MUST be part of the preferred SEIPDv1 / AEAD subpackets if the certificate has a PQ(/T) encryption key. I think that is uncontroversial and it wouldn't make sense to leave it out. We can further mandate that when encrypting to multiple recipients, and all recipients support AES-256, and at least one PKESK uses a PQ(/T) key, then AES-256 has to be chosen for the symmetric encryption.

Perhaps it could be loosened to the requirement that "Level 3" keys only require AES-192 to be supported, but that's not an important decision for now.

[falko-strenzke]

As an alternative to @falko-strenzke's proposal we can simply mandate that AES-256 MUST be part of the preferred SEIPDv1 / AEAD subpackets if the certificate has a PQ(/T) encryption key. I think that is uncontroversial and it wouldn't make sense to leave it out. We can further mandate that when encrypting to multiple recipients, and all recipients support AES-256, and at least one PKESK uses a PQ(/T) key, then AES-256 has to be chosen for the symmetric encryption.

👍

Perhaps it could be loosened to the requirement that "Level 3" keys only require AES-192 to be supported, but that's not an important decision for now.

I would leave out AES-192, from what I understood it is generally considered to be not so well supported.

[dkg]

@TJ-91 wrote:

What I meant is that mandating a specific symmetric algorithm that has to be used in combination with a specific public-key encryption algorithm violates the separation that OpenPGP used to have between the two kinds of encryption.

I agree with Johannes here that this "violates the separation that OpenPGP used to have", but i'm also not convinced that the separation is entirely healthy. I'll note that another aspect of this draft also "violates" a traditional OpenPGP separation: the SLH-DSA signatures are obliged to use specific choices of digest algorithm for the message. Traditionally, OpenPGP messages could select any digest algorithm with any asymmetric signature primitive. This isn't exactly the same thing as binding the symmetric cipher to the PKESK choice, of course (for one thing, if you can't read signature A you might still be able to read signature B), but "violating a traditional separation" as a general practice isn't necessarily a bad thing.

Anyway, i don't see why it would be an objection here, especially given that everyone, everywhere, that has any chance of reading a recent encrypted message appears to support both AES-128 and AES-256.

[dkg]

@TJ-91 wrote:

we can simply mandate that AES-256 MUST be part of the preferred SEIPDv1 / AEAD subpackets if the certificate has a PQ(/T) encryption key.

I like this idea, but a couple notes of caution:

• remember that the AEAD ciphersuite preferences packet has an implicit AES-128,OCB tacked on at the end if it doesn't explicitly contain it, due to the MTI algorithms in the crypto-refresh.
• saying "MUST be part of" implies that an OpenPGP certificate without it is inherently a malformed protocol data unit; what should a receiving OpenPGP implementation do with such an object? reject it? report it? refuse to use it?

Rather than introducing new failure mode, wouldn't it be more straightforward to say that there is an implicit AES-256,OCB in the AEAD Ciphersuite Preferences for any such public key, aligned with the implicit AES-128,OCB entry?

[TJ-91]

@dkg good points.

You are right about MUST and I guess SHOULD is enough here. That means, we recommend explicitly adding AES-256,OCB to the preferences for certificates that contain a PQ(/T) key; otherwise it's implicitly added at the end.

A few further points:

• Preferences for SEIPDv1 symmetric encryption should follow the exact same logic, correct?
• If we add AES-256 / AES-256,OCB at the end of the preferences, we might end up with cases where we use AES-128 / AES-128,OCB instead.
• Do we want to go a step further and assume that AES-256 / AES-256,OCB is at the front of the list (i.e., the most-preferred algorithm) for a certificate that contains a PQ(/T) key?
• We can even go another step further and generally recommend that a PQC-capable implementation should always favor AES-256 / AES-256,OCB when creating a SEIPDv1 / SEIPDv2 message (when it's in the intersection of preferred algorithms). This is a bit more effective but still honors the choice of a non-PQC certificate that does not explicitly list AES-256 / AES-256,OCB.

[dkg]

I think it might be simplest to say that, for keys like this:

• the implicit list at the end of SEIPDv1 preferences is AES-256, AES-128.

• the implicit list at the end of SEIPDv2 preferences is AES-256+OCB, AES-128+OCB.

[TJ-91]

I think that's a good suggestion that effectivly promotes the use of AES-256 by extending existing mechanisms.

What do the others think?

[wussler]

I agree this to be a good solution, and our first chance of reporting a substantiating change to the list

[dkg]

On Wed 2024-02-07 09:00:01 -0800, dkg wrote:

• the implicit list at the end of SEIPDv1 preferences is AES-256, AES-128.

After sleeping on it, i think the above change might be the only thing needed, since it relates to the PKESKv3 silliness.

• the implicit list at the end of SEIPDv2 preferences is AES-256+OCB, AES-128+OCB.

This one doesn't seem strictly necessary (PKESKv6's KDF folds in the algorithm ID, so there's no risk of cross-algorithm key mis/re-use).

If we want to include it, we should include it by making an explicit "needed for post-quantum" argument.

[TJ-91]

@dkg I think now you're confusing things but that's because this thread is about two different topics.

1. The initial issue regarding PKESKv3 and AES vs TripleDES as MTI algorithm is settled and we simply follow the Crypto Refresh in this regard. We bind the symmetric algorithm identifier to AES, and assume that any implementation supports at least AES-128 (already MUST in the Crypto Refresh). The AES restriction makes sure that no cross-algorithm attacks are possible.
2. The second topic in this thread is that we also want to promote the use of AES-256 since it matches the security of the PQC stuff better than AES-128 and using AES-256 is simply good practice and recommended (as Stavros points out). Your proposal to add AES-256 / AES-256+OCB to the preferences of PQC keys does exactly that, but plays no role in the cross-algorithm-attack concerns.

I hope I got it right since things got a bit confusing.

If we want to include it, we should include it by making an explicit "needed for post-quantum" argument.

We can't really say it's "needed". It isn't, and the proposal doesn't guarantee that we use AES-256 in all cases. But I think we have good reasons and no real drawbacks.

[dkg]

@TJ-91 thanks for the clarification, i think you're right that i got a bit confused by the overlapping topics.

And whether it's "needed" or not, it does make sense that if the asymmetric operation embeds the use of AES256 keywrap, it ought to have implied support for AES256 as a symmetric cipher.

[TJ-91]

In #90 I propose text for this change