>>>>> "Russ" == Russ Allbery <r...@debian.org> writes:
Russ> I worked on an update of my security review last night to take
Russ> into account the additional concerns that people have raised
Russ> and other feedback. I wrote a whole bunch of words about this
Russ> specifically because I don't think it's too obvious to explain
Russ> at all, and my opinion is more nuanced than simply saying this
Russ> archive property isn't important. From a security standpoint,
Russ> I care about attacks and defenses, and care about abstract
Russ> properties to the extent that they are useful in preventing
Russ> attacks. Here's what I came up with (this hasn't been
Russ> published yet; it's still a draft).
Russ, I have reviewed the additional text in your security review.
As you are aware, doing this sort of security analysis has been part of
my professional responsibility for a while. I've also spent a fair bit
of professional time reviewing security reviews like this including
analyzing whether they cover the right threats, and whether the
security analysis is complete and accurate.
I believe your analysis is good and I support your conclusions.
I do have one quibble: I think you may have missed one strength of the
tag2upload design.
Russ> ### Source package signatures
Russ> Currently, the source packages present in the archive include
Russ> OpenPGP signatures on the `*.dsc` file from the original
Russ> uploader. For packages uploaded by tag2upload, the `*.dsc`
Russ> file will instead be signed by the tag2upload service key, and
Russ> the original uploader, their key fingerprint, and a reference
Russ> to the original signed Git tag will be added as additional
Russ> Debian source package control fields in the `*.dsc`
Russ> file. Understanding the security implications of this change
Russ> requires some analysis.
Russ> The source package signature can be used for three purposes:
Russ> 1. Detect modifications to the source package after it was
Russ> uploaded. 2. Determine who uploaded this source package.
Russ> 3. Verify that the source package repesents the intent of the
Russ> uploader.
Russ> For the first purpose, the primary protection against archive
Russ> modifications is the sources list file, signed by the archive
Russ> key, which contains hashes of all of the source package
Russ> files. This case is therefore only interesting if the archive
Russ> processing software or database has been compromised, if the
Russ> source package is retrieved from the archive without checking
Russ> its hashes against the sources list, or if the source package
Russ> is being checked outside of the context of the archive.
Russ> The implications of a compromise of the archive processing
Russ> software are discussed above.
Russ> Verification that the package has not been modified, when
Russ> outside of the context of the archive, depends on the security
Russ> of the tag2upload service and its key. This is true of any
Russ> signed source package outside of the context of the archive:
Russ> verification that it has not been modified depends entirely on
Russ> the security of the key that has signed it. However, the
Russ> tag2upload service and key can be abused to generate far more
Russ> source packages without arousing suspicion than the typical
Russ> uploader key, since the tag2upload key is expected to sign a
Russ> variety of source packages.
In the case where the tag2upload key has not been compromised, the
tag2upload service appears to act somewhat as a trusted notary service.
(So does the sources file that is included in the release signature by
the archive processing software.)
Without tag2upload, when verifying the signature of a source package outside
of the
context of the archive (or when the archive's signatures are not
checked), we depend on the security of the uploader's key.
If the uploader's key is compromised at any point before we check the
source package signature, an attacker can create a signature that will
pass our check but that was not signed by the uploader.
In contrast, even if an individual uploader key is compromised, if the
tag2upload key is secure, we can trust tag2upload's assertions about
whether a signed git tag was ever turned into a source package that was
presented to the archive.
I think that this might help establish non-repudiation in a manner
similar to how signed timestamping services establish non-repudiation in
CMS-based PKIs.
In practice, most of the cases where such non-repudiation is valuable,
the Sources file plus the Release signature from the archive is going to
be more useful.
But I think this illustrates the complexity of the security trade
offs. We do not get a direct cryptographic link from the hash of the dsc
to a maintainer signature.
But we do get a security property that I personally think is more
useful: we get a more trusted attestation than the individual
maintainer's signature on the dsc plus the maintainer's signature on the
git tag.
If we are concerned about the possibility that the tag2upload server
will have performed an undesired transformation between the git tag and
the uploaded dsc, we have to check for that.
But in the far more likely case that the tag2upload transformation and
key are more trusted than the maintainer key used to sign the git tag,
we have a form of traceability independent of the archive software.
signature.asc
Description: PGP signature
