[pkg-gnupg-maint] Upstream request: Please use the default keyservers

[Daniel Kahn Gillmor]

On Fri 2020-02-28 10:59:58 +0100, Andre Heinecke wrote:

> it's very hard to engage with you construtively by mail as you write such long 
> mails that it takes a lot of time and energy to respond / discuss with you. 

Sorry about that.  I've tried to keep this response short, but i failed
again :(  I appreciate your followup.

> I think that current GnuPG versions do well to protect against this.

Client-side fixes can only go so far in fixing this problem. Even if
GnuPG had no CPU issues at all, not everyone can afford to ignore the
additional bandwidth costs.

And, GnuPG *does* also have CPU issues that are attackable via the SKS
pool (though maybe the CPU issues are mitigated when talking to
hockeypuck, if hockeypuck is effectively stripping
cryptographically-invalid self-sigs these days).

GnuPG should not be automatically trying to contact servers whose
policies permit arbitrary flooding.

> No but GnuPG did. As mentioned in my original mail, we would look forward to a 
> decentralized keyserver network that does crypto and validation of signatures 
> etc.. Our hope there is hockeypuck.

I would also appreciate that.  If it works, and it is resistant to the
problems outlined in the abuse-resistant keystore draft, i'd be happy to
consider changing the debian default to a sensible pool that implements
those defenses.

> Do you have numbers on that? I think  that its way less then 1% affected by 
> that but I have to admit that I don't have the numbers. This is also not 
> something new. Keys like the Gpgtools team key, Werners key, Krisitians key, 
> were affected by spammed signatures for years.

Those earlier flooding attempts are different kinds of flooding, and
they were also less in size than has been done today.  The fact that
only 1% of the certificates *are* flooded tells us nothing about the
reliability of the SKS network for those certificates which are not yet
flooded.  Any certificate can be flooded trivially by any attacker.

> I'm sorry to be nasty here: So Debians Answer is to exchange a potential DOS 
> against telling Vincent Breitmoser everything about your keyring.

I think rather, we've exchanged telling Daniel Austin "everything about
your keyring" with telling Vincent Breitmoser "everything about your
keyring".  I'm not happy about either situation, but i don't have a
negative impression of either individual, and we need to use the more
robust service.

> Refreshing the full keyring is also in my opinion a very rare usecase. I also 
> don't really recommend it as it's to large of a privacy leak. But we digress. 
> What you do here by patching in keys.openpgp.net results in just breaking that 
> usecase as keys.openpgp.net only serves a heavily reduced subset of keys / 
> userids. So why do we even discuss refresh keys on keys.openpgp.org if that 
> server does not even work for that?

Refreshing the full keyring is useful for the same reason that
enable-crl-checks is useful in gpgsm -- to look for revocations (and
subkey updates, but that's a less widely-used
situation). keys.openpgp.org can and does effectively distribute
revocations, and some (patched, ahem) versions of GnuPG will even act
when they discover those revocations.

> You have a different opinion. :-( Which is also totally fine, but I don't think 
> that you should be allowed to break our software because of that opinion.

I'm pretty sure the software is not broken in either configuration.

> Maybe krisitian can give us numbers on that. Also I don't think that CPU is an 
> issue anymore with recent GnuPG versions. Yes your key is affected but 99.9% of 
> the keys are probably not.

Yet.  The goal is a service that will reliably transfer the relevant
information.  SKS does not serve that purpose today, because anyone can
flood the certificate you're interested in.  If you can't fetch a
revocation certificate because it's surrounded by 30MiB of garbage and
you're on a metered data connection, it doesn't do you much good.

> Yes, sad. Let's improve the keyserver network. But we cannot capitulate and 
> just say "Let's trust this one guy with one server to manage the OpenPGP Keys 
> for the world".

And yet, the SKS network has done just that for the hkps pool.  I really
appreciate Daniel Austin's work there, but he's just as much a SPOF as
Vincent is in k.o.o.

> But now I have to Answer something completely unrelated just for the record in 
> this mail thread >.<. GnuPG follows the OpenPGP Standard. The OpenPGP Standard 
> does not define signatures not bound to a userid.

We both know that GnuPG is a significant mover in the OpenPGP ecosystem,
and has shipped changes and improvements that are not part of the
current stable OpenPGP standard for years, much to the benefit of the
community.

That said, i don't believe that *anyone* has asked GnuPG to do anything
outside of the OpenPGP standard, including the patches in T4393.

> I will not respond to any response on this Answer. Please open a new thread or 
> a new discussion on that.

I'm tired of that discussion too.  I'll await followup on
https://dev.gnupg.org/T4393, maybe giving pings every few months as i
have been for the last half year.

> Unrelated.

These unrelated divergences between upstream and the Debian distribution
were examples of situations where priorities between upstream and
distribution priorities differ.  They were intended as demonstrations of
the principle that it is ok that the distribution doesn't exactly match
upstream. I won't pursue them further in this discussion because i think
they've demonstrated their point.

> This patch is our line in the sand. We can live with all your other patches 
> but we cannot live with trusting Vincent to manage the OpenPGP keys for all 
> Linux users (And all other packagers take their input from debian IMO). This 
> is a security issue, 

This is certainly a security issue, but i don't think it's a security
issue in the direction that you think it is.  Fetching revocations from
the SKS pool is currently unreliable, particularly for people with
limited connectivity.

> it makes our software worse and the GnuPG Project is willing to
> escalate this if you block it.

I'm not sure what kind of escalation you have in mind.  If you'd like me
to step down as a debian maintainer for GnuPG and related projects, i'm
willing to do that.  Just let me know.  It would make me pretty sad, but
it would also free up my time to work with other projects.

> Sure, let's fix that. But the Answer s/Kristian/Vincent/ is not really a 
> solution or change on that.

Right.  We haven't made the centralization problem any better, but we
haven't made it any worse either.  We've only addressed the robustness
problem.

> To try to summarize my point:
> It does not help me if I can get 1% of the published OpenPGP Key information  
> 99% of the time.

Fair point.  Are we measuring % based on bytes?  on certificates?  on
actively-used certificates?  on user IDs?  It's certainly true that
keys.openpgp.org publishes a small fraction of the total number of bytes
published by the SKS pool.

> Yes. keys.gnupg.net is hardcoded and handles specially in GnuPG. So we control 
> which servers are accessed by default. Currently this delegates to the SKS-
> Keyserver Network. If we thought that this should not be done, we could change 
> that.

GnuPG e.V. does not exercise this control at the DNS level.  What's
hardcoded in upstream GnuPG is hkps.pool.sks-keyservers.net, not
keys.gnupg.net.

>> I'm looking for data which would change my opinion.
>
> gpg --recv-key 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1
>
> Here is your data point. It does not work.

With your proposed defaults, anyone reading this thread can make that
command cost dozens of MiB of bandwidth (with the accompanying latency)
by flooding the certificate in question.  They can do this at any time.

I'm not going to do the flooding myself, but you seem to be implying
that it would be better for everyone who naively runs that command to
risk incurring 100MiB of bandwidth, than it would be for you to take the
step to verify control of your e-mail address with keys.openpgp.org.

Furthermore, this discussion assumes you actually want your OpenPGP
certificate retrievable by the keyservers, though you also have other
mechanisms available for distributing your certificate, like WKD,
DANE+OPENPGPKEY, and Autocrypt.

Note that some other people *don't* want their full certificates
retrievable by the keyservers at all.  The SKS pool doesn't respect
their wishes.  Additionally, some other people don't want their name and
e-mail addressed published in association with public key material
controlled by someone else.  I'm sure we can both identify data points
that demonstrate those problems with the upstream defaults, but are not
problems with keys.openpgp.org.

In this discussion, we haven't really begun to address the concerns
about keyserver search by domain name, by e-mail address, or by human
name, which are all facilitated by "gpg --search", and the impact on
usability implied by multiple indistinguishable answers.  But i think
that keys.openpgp.org has an advantage there, as well, despite my deep
reservations over the e-mail verification feedback loop.

> I doubt that we can change your mind. I don't have the energy to change your 
> mind. You don't trust our decision regarding the default keyserver. We trust 
> our decision. I don't find it acceptable that you overrule our decision for the 
> Linux Desktop Ecosystem.

Other free software distributions are free to make their own decisions,
of course.  If multiple downstreams from Debian do decide to drop this
patch and revert to the upstream default, it would be a signal to me
that the ecosystem is somehow fixed, but i don't see that happening
today.

> I'm just saying that SKS is the best of the bad alternatives that we have. You 
> say keys.openpgp.net is the best of the bad alternatives. But that is not a 
> Patch that is acceptable.

Keyservers themselves are a bad alternative to WKD and other certificate
transfer mechanisms.  If we're going to use keyservers, we need to use
ones that don't put people at risk of attack from anyone on the global
network.

> I'm writing software that uses GnuPG. My Software needs userID's to work. To 
> have a keyserver that does not deliver userIDs breaks my Software.

keys.openpgp.org does deliver user IDs.  It just doesn't deliver them
unless the certificate-holder has completed an e-mail confirmation step.

> So debian pupusefully breaks GnuPG and Software using it.
>
> The GnuPG Project protests against this.

I note your protest, though i don't agree with your characterization.  I
believe GnuPG works well in Debian, and hopefully will continue to do
so.

I understand that my decision here is upsetting to you.  Please know
that i haven't made this decision lightly, and that i'm not making it
with the goal of upsetting you, others in the GnuPG project, Kristian,
or anyone else for that matter.  I respect the work and care that you've
put into this ecosystem, even though we disagree on this one point.

My goal (like yours) is to provide sensible, safe defaults to as many
users as possible.  I hope we can find a way to work together to do
this.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20200228/5e6b6789/attachment.sig>