Monday 22 January 2024

Re: Bumping apt RSA key length requirements to 3072-bit (2048 w/ warning) for 24.04

Hi,

On Thu, 18 Jan 2024 at 18:02, Julian Andres Klode
<julian.klode@canonical.com> wrote:
>
> Hi,
>
> we just noticed again that we are still trusting 1024R keys for
> signing repositories in APT, arguably because we do not have a
> means to tell gpgv the minimum key size.
>
> While the upstream bug[0] is being worked on,
> I have written a hack[1] that - if APT_SIGNING_REQUIREMENTS_HACK
> environment variable is set - makes gpgv error out on keys smaller
> than 2048R and warn on keys smaller than 3072R (following the
> current OpenPGP draft size length requirements, 3072 is a SHOULD,
> 2048 a MUST).

Separately we also care about NIST FIPS recommendations, for RSA it is
2048 until 2030, and with an option to bump it to 3072 from 2030.
Thus one can scope this as 2048 until 2030, and 3072 from 2030 already.

Also, given the performance penalty involved we should also consider
to support and accept ECC - as per NIST Ed25519 (more popular in new
deployments) is now approved as is P-256 (wider compat and support)
both of which are post-2030 acceptable to NIST, the wider internet
(TLS authorities) and us.

>
> I have also written code in APT to actually parse GPG error and
> warning status messages, and set the environment variable.[2]
>
> Sadly shipping this in 24.04 means that PPAs owned by user
> accounts created prior to 2014-03-11[3] until the key rotation
> mechanism(s) [4][5] have been implemented.
>

I do wonder how many active old PPA owners remain in action.

And if we can reset per-series signing keys on all of those for any
new PPAs, and noble series (meaning single signe, new key for noble+).

I have personally created a new team for myself, only added myself to
be a member of said team, to gain access to PPAs signed with 4k RSA
key, as I can no longer use my own ppas. I guess I should ask to
delete them all, and request removal of the signing key to gain back
personal PPAs with 4k signing key.

> However given that (I've been informed) ~800 bits were already cracked about 5 years
> ago, and we are planning to support 24.04 for 12 years, I believe
> that this is necessary and it's better to take the pain now then
> do an SRU to disable 1024R keys on existing systems.
>
> This is more painful than the digest transition because we have
> reason to believe that 1024R keys are potentially unsafe *now*
> and we need to stop trusting them, whereas when we deprecated
> MD5 and SHA1 we were able to have a deprecation period of a
> stable release.
>
> [0] https://dev.gnupg.org/T6946
> [1] https://gist.github.com/julian-klode/fbc56278cd0bdcd305f825479b094fad
> [2] https://salsa.debian.org/apt-team/apt/-/merge_requests/322
> [3] https://code.launchpad.net/~wgrant/launchpad/4096r-ppa-keys/+merge/210336
> [4] https://bugs.launchpad.net/launchpad/+bug/1331914
> [5] https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1461834
> --
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer i speak de, en
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--
Dimitri

Sent from Ubuntu Pro
https://ubuntu.com/pro

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel