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

[Andre Heinecke]

Hi Daniel,

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. 
I'll try below:

On Friday 28 February 2020 00:01:01 CET Daniel Kahn Gillmor wrote:
> That patch is in place because the SKS keyserver network preferred by
> upstream by default will inflict major costs on users, including when
> they fetch or update certain certificates.

But that is a major concern with keys.openpgp.org I fetch keys by fingerprint 
both personally and in my software. This just does not work very well with 
this keyserver as it has a drastically reduced set of keys / information.

> I think you already know about this, but for the record in this
> conversation, the SKS keyserver network as it currently exists is
> vulnerable to a host of attacks, some of which are detailed here:
> 
>    https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-04

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

> The SKS pool has not taken any of the recommended mitigations in that
> draft thus far, as far as i know.

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.
 
> So, a user who fetches a flooded certificate from the SKS keyserver
> network might incur dozens of megabytes of traffic (and a
> not-insignificant amount of CPU time) in exchange for very little
> (possibly no) additional data.

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.

> Users who are refreshing their full keyring regularly (as recommended,
> to check for revocations or subkey rotation) would see their risks
> increase proportional to the size of their local keyring.

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

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?

> As /usr/share/doc/{gnupg,gpg,gpgconf}/NEWS.Debian.gz says:
> 
> -------------------
>   Upstream GnuPG now defaults to not accepting third-party certifications
>   from the keyserver network.  Given that the SKS keyserver network is
>   under attack via certificate flooding, and third-party certifications
>   will not be accepted anyway, we now ship with the more tightly-constrained
>   and abuse-resistant system hkps://keys.openpgp.org as the default
>   keyserver.
> 
>   Users with bandwidth to spare who want to try their luck with the SKS
>   pool should add the following line to ~/.gnupg/dirmngr.conf to revert to
>   upstream's default keyserver:
> 
>       keyserver hkps://hkps.pool.sks-keyservers.net
> 
>   See the 2.2.17 section in the upstream NEWS file at
>   /usr/share/doc/gnupg/NEWS.gz for more information about fully
>   reverting to the old, risky behavior.

This is what I mean by opinion. I don't think it's risky. I don't think its 
"trying your luck" I think its more "trying your luck" not finding any keys 
because people did not do the validation.

> Sorry, but i don't see the distinction between "opinion-based" and
> "fact-based" here.  As one of the maintainers of the GnuPG package in
> debian, I need to think about the impact that these choices have on
> users of GnuPG in Debian, and about the impact of Debian users on the
> rest of the OpenPGP ecosystem.

I have the similar thoughts regarding Gpg4win. Werner here has the same 
toughts regarding everyone. And when we objectively discussed the advantages 
and disadvantages of a centralized keyserver the GnuPG Project decided to take 
the disadvantages of the keyserver network.

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.

> Interacting with the SKS pool implies a significant increase in both
> bandwidth and CPU use.

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.

> Furthermore, deployment considerations and
> experimental testing shows that queries to the SKS pool take longer to
> complete on average (both with and without the use of Tor, even for
> non-flooded, minimal cetificates), and are more likely to return
> unreliable answers (e.g. gateway failures between nginx and the backing
> sks server, due to sks's non-concurrent nature and choice of bdb as
> backing store).

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".
 
> This unreliability for SKS is both confounded by and compounded by
> dirmngr's overaggressive negative caching policy for server availability
> (see https://dev.gnupg.org/T4513) -- users are more likely to get
> stochastically bad results when querying the SKS pool from dirmngr.

That issue is about the complete opposite. Dirmngr expects pools of servers 
and does not retry very well when a single instance is marked as dead.
 
> It is certainly my opinion that this set of facts represents a bad
> tradeoff for users and the ecosystem as a whole.  But i consider my role
> as a distribution package maintainer to take user and ecosystem concerns
> seriously even when upstream can't prioritize those concerns.

There is a line where upstream gets annoyed because we have discussed such 
topics over and over and spent a lot of brainpower regarding the pros and cons 
and then downstream comes along and says "I don't like your answer I have my 
own".
For example Gpgtools patched GnuPG for a long time to allow 8k RSA keys. This 
was just not very intelligent and we disliked it because we had good reasons 
not to give users this option. 

> Those differences of opinion can be quite wide-ranging.  For example,
> we've had user concerns about battery drain from unnecessary daemon
> wakeups, and we have patched those out in debian while it was feasible
> to do so, despite upstream being uninterested in that problem.  (i
> believe gniibe did upstream some of the work recently, thank you!)
> We've also adopted some trivial changes that make it safer and easier to
> modify the source that upstream sees no need for
> (https://dev.gnupg.org/T4593).
> And for nearly a year now, we've handled
> importing updates of revocation information and subkey rotation
> information for certificates even if the incoming certificate-like-thing
> has no User IDs (https://dev.gnupg.org/T4593), a problem which upstream
> seems unconcerned about. 

I don't know how many hours "upstream" has already spent on this. I'm 
disappointed that you pull out such issues.
We are talking about removing the keyserver patch here.

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.

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

> Similarly, we've limited ptrace access to RAM
> of gpg-agent and scdaemon, even though upstream doesn't consider this
> mitigation as significant or worth making
> (https://bugs.debian.org/712744).  And debian adopted changes to the
> cryptographic defaults well in advance of upstream, as an attempt to
> mitigate the increasing power of both cryptanalysis and large-scale
> computing farms.

Unrelated.

> So yes, there are differences of opinion, but i don't think it's correct
> to say that Debian should not patch software because it has a different
> opinion than upstream.

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, it makes our software worse and the GnuPG Project is 
willing to escalate this if you block it.

> As you know, i have also helped to operate one of the keyserver that
> used to be in the SKS pool for years, and i share your affinity for
> decentralized systems.
> 
> I agree with you that centralized keyservers are super problematic from
> a privacy perspective, and with your concern about a single-point of
> attack.  I'm not sure what to think about "etc etc" ;) but i'd assume
> that your additional concerns include robustness in the face of a legal
> or technical adversary as well.
> 
> However, we should look at the SKS pool with clear eyes on the same
> terms.
> 
> In terms of single-point-of-attack, Kristian's role is hard to ignore.

This is not really true. The GnuPG Project controls the default keyserver. We 
can change it if we think that there is a problem.

> If Kristian were compromised or incapacitated, his DNS service suborned,
> or his scripts that measure inclusion in the pool taken over, the SKS
> pool would certainly go down or could be redirected.

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

> In terms of information leakge to a single instance, the default SKS
> pool (hkps.pool.sks-keyservers.net) is not particularly decentralized:
> according to https://sks-keyservers.net/status/ today, only three nodes
> answer to hkps:
> 
>  - sks.pod02.fleetstreetops.com
>  - pgpkeys.eu
>  - pgpkeys.co.uk
> 
> the latter two hosts are controlled by the same entity (ironically, the
> link listed for the controlling entity on the status page,
>
>True, but at least they serve keys and not just a heavily reduced subset.
> https://sks-keyservers.net/pks/lookup?op=get&search=0xEBF54CD6472EFFFF,
> returns a 502 Bad Gateway error at the moment), and the first host only
> has an IPv4 address.  So an IPv6-only user would not spread their
> searches across multiple unaffiliated parties at all (both IPv6
> addresses go to the same party), and dual-stack hosts that selects
> randomly among the 5 available IP addresses will still send 80% of all
> their traffic to the same party.
>
> 
> Addressing the technical robustness concerns -- a distributed network
> *can* offer more technical robustness if it is implemented with an eye
> toward fault tolerance.  Unfortunately, the SKS network hasn't made
> strides to do that; performance problems have been worked around for
> years (i know -- i've helped work around them!) but the core issues
> (single-threaded, synchronous sks process; the archaic database backend)
> haven't been addressed.  keys.openpgp.org has seen significant attention
> to engineering efficiency and reliability, which results in the
> experimental results described above.

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.

> As for concerns about robustness against legal attack: the SKS network
> has seen participants drop off out of fear (warranted or not) about GDPR
> and similar privacy concerns -- there is a not insubstantial perception
> of legal risk associated with running a global, append-only datastore.
> The SKS pool also has no stated privacy policy, while keys.openpgp.org,
> despite its flaws, has at least formulated
> https://keys.openpgp.org/about/privacy, and has made several clear
> public decisions based on those concerns, which lead me to think it will
> have a clearer and simpler response to any legal attack based on claims
> of privacy violations.

This issue is unrelated and a whole discussion in itself. 

> > There is not even an instiution like the GnuPG e.V. behind this service, 
it 
> > might change at a whim.
> 
> There is no institution like GnuPG e.V. behind the SKS keyserver pool
> either, as far as i'm aware.  Am i wrong about that? 

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.

> If there is an institutional backing for the SKS keyserver pool, does that
> mean that the institutional backer is responsible for any legal attack
> against the pool generally?

Well, maybe we should try to get something done with the gnupg-verein to set 
up a keyserver network.
 
> I'm looking for data which would change my opinion.

gpg --recv-key 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1

Here is your data point. It does not work.

> I would be very
> happy to change my mind, and i would readily adopt an actually
> decentralized system that offers the types of robustness and user-driven
> features that are described above.  But i haven't seen such a system.

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.

> Furthermore, other distributions of GnuPG (e.g. gpg-tools on Mac OS X)
> have also switched to keys.openpgp.org.

Yeah, I have to nag them, too ;-) And sorry they are really not the best 
example regarding patches to GnuPG. We expect more of Debian.

> That's a good point, thanks for raising this.  I've updated our patch so
> that the dirmngr manpage makes it clear that this is a debian-specific
> change.  You should see that in the dirmngr(1) manpage that ships in
> dirmngr 2.2.19-2.

Thanks. 

> I'm as sad as you are about the fate of SKS, but we need to acknowledge
> that it was designed for a different network, without any appreciable
> defense in depth, and hasn't matured to the level where it is a
> responsible default.

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.

> GnuPG users on Debian need to be able to robustly and reliably fetch
> peer certificates, updates, and revocations, and they need the service
> that they use to not be susceptible to trivial flooding attacks by third
> parties that make any certificate (or even worse, any revocation
> notification) unavailable.  The SKS pool is no longer fit for those
> purposes (and perhaps it never was, but now it is visibly failing), so i
> don't think we can ship GnuPG in debian with that default in place in
> good conscience.

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. So debian 
pupusefully breaks GnuPG and Software using it.

The GnuPG Project protests against this.

Please let us only discuss the keyserver change here and not mix in everything 
about GnuPG in debian.

Best Regards,
Andre

-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 Düsseldorf.  VR 11482 Düsseldorf
Vorstand: W.Koch, B.Reiter, A.Heinecke        Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-211-28010702
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20200228/30524636/attachment.sig>