On Tue 2024-08-20 12:18:07 +0200, Julian Andres Klode wrote:
> Sorry I am slow with replying
no worries, i'm also slow in replying. thanks for getting back to this
discussion, Julian!
> I think we have a fundamental issue here that we are conflating
> different contexts of signing, it doesn't make sense to require
> all contexts to use the same signing requirements.
I agree with you that there might be different contexts or levels, and
sop as currently specified doesn't have such a distinction for signature
verification. Thanks for raising it specifically. I've opened
https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/108 to try to
discuss whether it makes sense for `sop verify` to take some sort of
`--profile` argument.
> For OS-level code signing like APT repositories we can make informed
> choices and we can increase the security level each release, vendors
> of third-party repositories can adjust to that reasonably.
>
> It's much easier to stay ahead of the crypto wars then in e-mail where
> you may need to wait ages to sign with an ed25519 key because others
> won't understand your signatures or stuff.
With OpenPGP (whether for e-mail or codesigning), you can sign with your
new key immediately, as long as you keep signing and the old key as long
as you care about old, unupgraded validators being able to verify the
message.
Anyway, the issue here isn't about delaying *signing*, it's about
handling the verification side of things, right? I think the levels you
propose are interesting here:
> The issue we need to solve is that we need to have at least 3 different
> levels of weak keys:
>
> 1. keys that are so weak we don't trust them anymore
> 2. keys that will soon be considered and we need to warn about
> 3. keys that are not best practices and if you opt-in to receiving
> messages about best practices, you should get a message about them
it sounds to me like we're in agreement about the any sop implementation
should be fine for category 1, but there are two concerns:
(a) there might be some disagreement about what specifically goes in
which category, and
(b) sop offers no clear mechanism other than unstructured stderr for
producing warnings about weaknesses that should be visible to the
user.
Is that right?
> That's what apt 2.9.x implements as the "current", "next", and "future"
> security levels, with the --audit flag to opt-into messaging about
> far-away/not-best-practices key algorithms.
I'm not sure i understand the distinctions in play here precisely. how
does --audit ("far-away/not-best-practices") interact with the security
levels? i'm assuming that 1 is "current" and 2 is "next" and 3 is
"future" -- does --audit simply make the warnings about "next" and
"future" appear for the system administrator?
> A validation of keys at signature level means that only 1 becomes
> meaningful, you'll only see messages about type 2 and type 3 keys
> once they become used for signing.
The risky algorithms in question for OpenPGP are both pubkey signature
algorithms, and digest algorithms. In the happy case, you'd hope none
of these get used after they *stop* being used -- they're presumably all
legacy things. But of course an attacker might find ways to use, say, a
weak hash algorithm with a strong asymmetric key. and at that point you
do want the signature to fail, or to have a
> However, you want to see messages about type 2/3 keys whenever
> they are configured as acceptable signing keys.
So i'm not sure about this, but i can see how you might want an OpenPGP
verifier to know that they're passing unacceptable signing keys.
I've opened https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/107 to
consider adding guidance about warnings when unacceptable signing keys
are present during signature verification operations.
> Example:
>
> If we get a easy rsa1024 attack, we can't just go put them in category
> 1 and block all third party repositories, we'd need to put it in
> category 2, have warnings for 6 months and give people time to migrate
> to newer signing keys.
I don't know what you think is an "easy" attack, but even though no one
has bothered to put together the resources to publicly break rsa1024, i
think we should be rejecting signatures made today from RSA1024 keys,
just like i think we should be rejecting signatures made over SHA1 or
RIPEMD160.
> People shout at you if you just say the validation failed and don't
> explain to them *why* it failed.
Well, there are lots of possible different failure modes, and more than
one of them could be true at the same time -- for example, you could
have a timestamp mismatch as well as a weak digest algorithm.
And in many cases, producing a "why" for interpretation by a harried
sysadmin can be counterproductive from a security perspective: they
might try to figure out how to make the warning "go away", when the
problem isn't something they can fix directly -- rather, it's something
that the apt repository owner needs to address. Is there any sort of
feedback mechanism that apt could use to alert the repository owner of
signature validation failures safely?
I'm willing to consider updating the SOP specification to explicitly
encourage signature verification *failures* to produce
human-comprehensible explanations to stderr, but i don't know how to
specify "human-comprehensible" formally (and i think it would probably
be a mistake to try). Additionally, there is a localization issue here.
Tricky! But again, if anyone is going nto try to craft such an
explanation, i think the OpenPGP implementation is the right place to
try to do this, and not APT. There could be OpenPGP subtleties that APT
doesn't need to know about. I've opened
https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/109 to try to
track that issue from the specification's perspective.
> Once we're at a point where every source has a Signed-By field,
> pointing at a filename the messaging becomes easier: You just tell
> them you could not verify using that key file, but right now for sources
> without the field it's quite confusing if you just say validation
> failed.
i agree with you that apt configurations should encourage the use of
Signed-By! I think you might be saying here that every apt source
itself might publish its own Signed-By information in its own Release
file, which i think introduces some interesting chicken-and-egg concerns
(not least among them how a repo maintainer can sign with multiple keys
and also update to new signing keys). i'd love to talk that over
separately from this discussion, if you think that would be useful.
--dkg
Attachment:
signature.asc
Description: PGP signature