[openpgp] Re: session key length with SEIPDv2

[Daniel Huigens <[e-mail]>]

Hi dkg,

On Friday, October 4th, 2024 at 11:12, Daniel Kahn Gillmor wrote:
> leaving consumer guidance implicit seems like it is the
> core of the original omission

I disagree with this part; I think producer guidance is the important
part, because (quoting from my previous email):

> Though, I do think all of the security risk is on the encryption /
> producer's side - i.e. as long as producers choose an appropriate
> length, the ecosystem is safe, and the consumer can't protect against
> the producer choosing an insecure session key in general, anyway
> (e.g. the producer could also choose a session key of all zeros,
> or a random session key but publish it somewhere).

Note that also for SEIPDv1, there was technically no consumer guidance
either - of course you might say it's obvious that decryption would fail
but the consumer could technically truncate or pad the session key, as
well.

To be fair, there's not much producer guidance either - the only things
I could find are (1) in the names of the algorithms:

   7   AES with 128-bit key [AES]
   8   AES with 192-bit key
   9   AES with 256-bit key

and (2) in these examples:

   For example, in a version 3 Public Key Encrypted Session Key packet,
   an AES-256 session key is encoded as follows, forming a 40-octet
   sequence:

   09 k0 k1 ... k31 s0 s1 05 05 05 05 05

   The octets k0 to k31 above denote the session key (...)

   In a version 6 Public Key Encrypted Session Key packet, the symmetric
   algorithm is not included, as described in Section 5.1.  For example,
   an AES-256 session key would be composed as follows:

   k0 k1 ... k31 s0 s1 06 06 06 06 06 06

   The octets k0 to k31 above again denote the session key (...)

I'm not sure if examples count as normative guidance, but at least this
shows that the intention was to keep the session key lengths the same
in SEIPDv2 as in SEIPDv1.

All of that is not to say that I'm opposed to consumer guidance, but I
think (normative) producer guidance is the more important part and the
part that can more unambiguously be shown to have been intended given
the above quotes of RFC9580, and thus I think it could go in an erratum?
Whereas if we want consumer guidance (for SEIPDv2 and v1) I'd expect
it'd have to go somewhere else. But, lmk if you disagree, of course.

Best,
Daniel