[Rpm-maint] [rpm-software-management/rpm] Phasing out obsolete crypto in rpm (#1292)

[Demi Marie Obenour]

> > > > > Besides the currently obsolete things, new things need to be built with the mindset that all crypto _will_ become obsolete over time, and avoid putting it into new places where it only gets in our way eventually.
> > > > 
> > > > 
> > > > I suggest avoiding algorithm agility as much as possible. It is great in theory, but in practice, it leads to a bunch of extra complexity, which in turn causes exploitable vulnerabilities. The current header parsing code is already _far_ too complex.
> > > > Instead, choose _one_ ― and only one ― set of algorithms. Drop support for all the others. And change the file version number when an algorithm change is needed. That’s what signify, age, WireGuard, and most other new cryptographic protocols do.
> > > 
> > > 
> > > This would be a pretty bad idea for any archive format. That would mean we'd be making incompatible revisions of RPM very frequently, which would cause a whole host of problems as things move forward. Algorithm agility is the _only_ reason that new algorithms are easily adopted _at all_. If you decide to make algorithm selection part of the protocol/file format itself, you wind up with a different trap: the inability to upgrade. I think we can all agree that is a much worse outcome.
> > 
> > 
> > That’s understandable, and something I had not considered. Much of the complexity of the current format is not actually due to algorithm agility.
> > That said, versioned protocols do not prevent backwards compatibility. For example, v1 of a file format might use RSA signatures, v2 Ed25519, and v3 a hybrid of Ed25519 and CRYSTALS-KYBER (a post-quantum scheme). An implementation can support more than one version.
> 
> Right, but the issue is that there is no possibility of forward compatibility. Right now the RPM format is fairly good at forward and backward compatibility. Barring specific usage of features RPM can't handle (which is gated with specific details encoded in the RPM header), RPMs produced by newer versions can be installed by older versions. And some "new" features can be ignored by older versions of RPM without penalty (e.g. weak dependencies on RHEL 7 are ignored without issue).
> 
> At least in this specific case, we already encode what crypto is being used in the RPM archive and if RPM doesn't know what it is, it won't do anything. That's effectively the same as versioned protocol, it's just a versioned attribute in the format without changing the whole format. And that gives the opportunity to _backport_ the support to older systems, which has been done before in other circumstances.
> 
> Changing the whole format for this would make it pretty difficult to do that, since that would increment the RPM major version.

That’s a good point.  My main worry is that there could be a parsing bug in RPM that either:

- Allows compromising RPM before signatures are checked, or
- Allows modifying an RPM package without invalidating the signature.

> > > Your examples are also sufficiently immature that there is no way that any of them have seen the consequences of those choices. WireGuard itself was only mainlined fairly recently, and has no current plan for dealing with the inevitable issue of cross-version (thus incompatible) client and server mixes existing in production. As for signify and age, any project from OpenBSD winds up being problematic because longevity, compatibility, and accessibility are not virtues held by the OpenBSD project.
> > 
> > 
> > I suspect that the upgrade plan is to run both v1 and v2 services for a while, and eventually stop the v1 service.
> 
> If WireGuard worked purely in user-space, that would be possible. But it doesn't. It's a kernel-level security service, and that means that in order to do what you say, you have to run different versions of the Linux kernel, meaning older Linux distributions. This is a serious downside of the WireGuard system as it currently stands.

What I meant is that the WireGuard kernel module could support both versions of the protocol for a while, and eventually drop support for the obsolete version.  I do not believe that WireGuard intends to support products that are no longer receiving updates.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1292#issuecomment-751378526
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20201226/1ea8a82a/attachment.html>