Hi All,
On 17/01/2022 16:02, James Bottomley wrote:
On Mon, 2022-01-17 at 15:34 +0100, Jason A. Donenfeld wrote:
Hi,
While it looks like you put a lot of work into this patchset, I think
the general idea of adding PGP *to the kernel* is a pretty daunting
proposition. The general consensus in the crypto engineering world is
that PGP ought to be on its way out. We definitely don't want to
perpetuate this project-on-life-support into the permanence of kernel
code. Some quick Google searches will reveal a litany of blog posts
to the tune of, "why oh why are people still using this?" Here's one
from 2019:
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html . I
think these are arguments to take seriously. And even if you disagree
with some parts, you may want to consider whether the remaining parts
warrant a bit of pause before adding this to the kernel and
perpetuating PGP's design further.
So while I understand why this is being proposed and clearly effort has
gone into it, I also think it is not the right approach. It seems this
proposal is to include a full PGP packet parser and verification logic
in the kernel as an equivalent to allow PGP signatures to be submitted
via FS_IOC_ENABLE_VERITY:
"FS_IOC_ENABLE_VERITY accepts a pointer to a PKCS#7 formatted detached
signature in DER format of the file’s fs-verity digest."
I may be misinterpreting, but as I understand it logic for X.509/PKCS
validation already exists in-kernel because of UEFI and module signing,
so this signature would be verified up to trusted roots. The proposal is
to duplicate all of this logic but in terms of PGP-formatted keys.
I believe this is unnecessary. Since it seems to require both a
signature and verification up to a root, and distributions like Fedora
already deal with x509 module signing keys for their kernel modules, I
can't see the merit in including the full PGP system too. The
least-effort approach, I would suggest, is to include an x509
representation of the signature in the RPM and use the existing API to
push that up into the kernel, with the trust anchor the same as is used
for module signing keys, or whatever distributions prefer (they, after
all, control the kernel trust anchors).
I understand this requires some effort, but so too does maintaining a
fully fledged PGP packet parser as privileged code for all time, and I
think maintaining this in userspace is a) easier and b) less costly than
doing it in kernel. As an added bonus, a PGP-parsing library in a
memory-safe language could be used in userspace.
A slightly more drastic step would be to wholesale move to PKCS
signatures for packaging. Linux distributions could be their own trusted
roots for this purpose if they so desired, and since they control
certificate bundles anyway they've no need to add them to the browser
list if that is a concern, and can issue certs without SSL Client/SSL
Server types and OIDs.
The reason is simple though: for all the detractors and whining, no-
one's actually been able to come up with a more usable replacement.
Very few people who complain about GPG actually submit patches to fix
it. A few come up with their own infrastructure which tends to have
even more problems.
Probably replacing with PKCS is a non-starter, but it is at least
possible and it is highly likely distros package one or more tools
capable of validating such signatures in their base installs.
There are multiple problems with PGP that receive complaints. They are:
1) No forward secrecy in messaging-based crypto.
2) The data format.
3) Outdated cryptography still supported.
4) UX.
Of these, all four could be levelled against PKCS standards and related
tools too (except TLS protocols for the first point), and only 2 and 3
are relevant here since we are concerned with signature validation only.
I'm not "against" PGP per se, but I'm not convinced by the idea of
adding PGP support just for fs-verity.
If you're looking for a simple signature mechanism to replace the use
of X.509 and all of that infrastructure, may I suggest just coming up
with something simple using ed25519,
Please, no, use universally supported crypto that we can use TPM
hardware for, which for EC currently means P-256. It may be possible
to get the TCG and the other security bodies to add Edwards signatures
but the rate of progression of quantum means that Grover's Algorithm
will likely get there first and we'll need P-521 or X448.
I agree: whatever is chosen should in my view have decent support for
hardware-backed keys, because I strongly hope that is what distribution
key storage looks like. If not I might need to move to Gentoo.
The current RPM signing keys for Fedora are RSA-4096, which in my
opinion does not actually meet the bar for "good hardware support for
algorithm". RSA-2048 tokens are common, but 4096 much less so.
Unfortunately for this reason signify/minisign is not ideal as tools: so
far as I can see it has no support for hardware-backed keys. That's not
to say they couldn't, although they both use ed25519.
I am not sure if we'll end up in the situation where Grover's algorithm
is efficient but Shor is not, but this is all guesswork until we get
closer to a quantum computer with enough logical Qubits. But your
substantive point I think is valid: hardware vendors are disappointingly
slow at adopting edwards curves.
similar to signify or minisign? Very minimal code in the kernel, in
userspace, and very few moving parts to break.
Heh, this is the classic cryptographers dilemma: go for something
pejorative which can be minimal but which has only a relatively small
set of possible use cases and no future proofing or go for something
extensible which ends up more complex and others then criticize as
being a "swiss army knife".
I think this is the wrong framing for the problem. We already have one
extensible system that is complicated in the kernel. This patch proposes
to add a second one achieving the same purpose instead of a userspace
solution to take advantage of the existing code, which I think would be
preferable and safer.
Antony
