[openpgp] Re: session key length with SEIPDv2

[Daniel Huigens <[e-mail]>]

Hi Heiko & all,

As I wrote in the issue you linked, I agree that this is an
unfortunate oversight.

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

Nevertheless, we should still have had guidance for the sender, at
least. Since there was never any intention to change the situation here
compared to SEIPDv1, I think filing an erratum to make the situation
the same again could be reasonable; although it's a bit unfortunate to
have to add a normative requirement in an erratum which may be missed -
but then again I'd assume by default implementations would do the same
as for SEIPDv1, anyway.

If others (e.g. the chairs) agree that we should file an erratum for this,
I would tend to keep it simple and just say in Section 5.1 and 5.3 that:

    The length of the session key MUST be the key size of the
    symmetric algorithm used in the encryption container.

Then, the implications for the producer and consumer can be inferred
from that, and that way it's closest to the situation for SEIPDv1
(and no real new guidance is introduced). If we do want more explicit
guidance it might be better to add it elsewhere, instead.

Btw, one case where some extra care is required for SEIPDv2 specfically
is if you want to reuse the session key as referred to in Section 13.8.
In that case, you have to additionally make sure that the algorithm
matches the key size of the session key. But that doesn't seem too
onerous, and Section 13.8 already lists a bunch of other caveats,
anyway.

And, thanks for raising this!

Best,
Daniel


On Sunday, September 22nd, 2024 at 18:48, Heiko Schäfer wrote:

> Hello list,
> 
> I believe RFC 9580 doesn't explicitly specify the expected/correct
> length of session keys for SEIPDv2, and think this is an oversight.
> 
> With SEIPDv1, the session key length - by definition - must equal the
> key length of the symmetric cipher.
> However, the construction in SEIPDv2 technically works with session keys
> of any length.
> 
> I imagine that the intent in RFC 9580 is that the session key length in
> SEIPDv2 must also equal the key length of the symmetric cipher.
> However, with the RFC as it stands, receiving implementations don't have
> clear guidance to reject overly short SEIPDv2 session keys (or
> unreasonably large ones).
> 
> This strikes me as an unfortunate risk for the ecosystem: An application
> could produce SEIPDv2 encrypted messages that use one-byte long session
> keys (and send them over risky transports). Multiple libraries would
> currently cheerfully accept and decrypt such a message, giving users the
> (questionable) sense that the message was strongly protected.
> 
> Of course one could argue that senders should just do better. But I
> don't find that a fully satisfying perspective.
> After all, recipients can very easily reject such dubious messages, and
> surface their fishiness.
> 
> 
> If there is indeed no legitimate reason why the length of a SEIPDv2
> session key should ever differ from the symmetric cipher key length,
> then I think we should clarify (with an erratum for RFC 9580?) that:
> 
> - The session key length for a SEIPDv2 packet must be equal to the
> symmetric cipher key length.
> - Recipients must refuse to decrypt SEIPDv2 packets with session keys of
> differing length.
> 
> Thanks,
> Heiko
> 
> 
> PS: For reference, I have previously raised this point in
> https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/issues/146,
> and this issue contains some discussion
> 
> _______________________________________________
> openpgp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]