Re: SKS Keyserver Network Under Attack

[Andrew Gallagher]

> On 4 Jul 2019, at 03:23, Ángel  wrote:
> 
> A point I don't like about the design of hagrid is that verification is
> performed by the server itself.
> Thus, it seems that if there were a reconciliation protocol between
> them, either entering into one of them would lead to all of them blindly
> trusting it, or the owner would need to validate a challenge for each
> keyserver to which it gets replicated.

Exactly. This is why I believe we need to separate the functions of “master” 
keystores (such as hagrid, keybase, WKD) from “caching” keystores such as SKS. 
The master (but not authoritative) keystores would provide IDs and third party 
sigs, at the cost of having to perform verification (email in the case of email 
IDs and domain in the case of server IDs). The caching keystores would 
synchronise, but only the primary keys. They would then spider the master 
keystores for the rest of the key info. 

There is no reason for the master keystores to publicly certify keys - their 
verification process is an antispam measure, not an attestation of identity. 
But we can’t do away with verifying entirely, because there is no other known 
way to prevent flooding. 

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Local solutions: SKS Keyserver Network Under Attack

[Mirimir via Gnupg-users]

On 07/03/2019 10:19 PM, Mirimir wrote:
> Moved by Roland's requests, I've broken Enigmail in a fresh VM. And I'd
> appreciate some advice about how to fix it.
> 
> I installed Thunderbird and Enigmail in a Debian 9.5 x64 VM with Gnome.
> Using Enigmail Key Management, I tried to get rjh's 1DCBDC01B44427C7
> from pool.sks-keyservers.net, but that just timed out.
> 
> So I downloaded it via HTTPS. And it was ~60MB. I tried importing from
> the downloaded file, but that went nowhere. With 100% CPU.
> 
> So I got it from https://keybase.io/rjh and imported from clipboard in
> Enigmail Key Management. That worked just fine. So then I tried
> refreshing keys in Enigmail, leaving pool.sks-keyservers.net as the
> default keyserver. And that failed, complaining about no dirmngr. Then I
> tried refreshing keys with gpg in terminal, and got the same error about
> no dirmngr.
> 
> Then I deleted rjh's key, and got my own from Keybase, and imported it.
> But when I tried refreshing keys, I got the same error about no dirmngr.
> 
> So gpg must still work, because I can import and delete keys via
> Enigmail. But something seems borked about dirmngr. I guess that I'll
> try purging and reinstalling. Or is there a better fix?

Damn. Somehow dirmngr didn't get installed with Thunderbird and
Enigmail. How embarrassing. So now Enigmail does refresh my key.

But after importing rjh's key, refreshing in Enigmail fails:

| Downloading of keys failed
| gpg: keyserver receive failed: No data

I also tried in terminal:

| user@debian:~$ gpg --refresh-keys
| gpg: refreshing 2 keys from hkps://hkps.pool.sks-keyservers.net
| gpg: key ...: 22 signatures not checked due to missing keys
| gpg: key ...: "mirimir " not changed
| gpg: Total number processed: 1
| gpg:  unchanged: 1

Then I disabled rjh's key, and found that my key still refreshed
quickly. Using hkps.pool.sks-keyservers.net.

So that's good news, yes? Trying to refresh rjh's key failed, but it
failed quickly, and the attempt apparently didn't break anything.

> And yes, I should have tested everything first with a clean key, before
> messing with rjh's key. Is it likely that I borked dirmngr during the
> intital attempt to get it from pool.sks-keyservers.net?
> 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Local solutions: SKS Keyserver Network Under Attack

[Mirimir via Gnupg-users]

Moved by Roland's requests, I've broken Enigmail in a fresh VM. And I'd
appreciate some advice about how to fix it.

I installed Thunderbird and Enigmail in a Debian 9.5 x64 VM with Gnome.
Using Enigmail Key Management, I tried to get rjh's 1DCBDC01B44427C7
from pool.sks-keyservers.net, but that just timed out.

So I downloaded it via HTTPS. And it was ~60MB. I tried importing from
the downloaded file, but that went nowhere. With 100% CPU.

So I got it from https://keybase.io/rjh and imported from clipboard in
Enigmail Key Management. That worked just fine. So then I tried
refreshing keys in Enigmail, leaving pool.sks-keyservers.net as the
default keyserver. And that failed, complaining about no dirmngr. Then I
tried refreshing keys with gpg in terminal, and got the same error about
no dirmngr.

Then I deleted rjh's key, and got my own from Keybase, and imported it.
But when I tried refreshing keys, I got the same error about no dirmngr.

So gpg must still work, because I can import and delete keys via
Enigmail. But something seems borked about dirmngr. I guess that I'll
try purging and reinstalling. Or is there a better fix?

And yes, I should have tested everything first with a clean key, before
messing with rjh's key. Is it likely that I borked dirmngr during the
intital attempt to get it from pool.sks-keyservers.net?

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Ángel]

On 2019-07-02 at 10:01 +0200, Wiktor Kwapisiewicz wrote:
> > It is a real shame that a decentralized Hagrid isn't really
> >possible, though, at least to my understanding. It's quite the
> >limitation for GnuPG.
> 
> Decentralized non-identity information hagrid could still be
> possible. 
> It's just a question over which protocol to synchronize this kind of
> data.

A point I don't like about the design of hagrid is that verification is
performed by the server itself.
Thus, it seems that if there were a reconciliation protocol between
them, either entering into one of them would lead to all of them blindly
trusting it, or the owner would need to validate a challenge for each
keyserver to which it gets replicated.

My expectation would be that the verification added a (non-dropped)
signature by the entity which performed the verification.
The keyservers themselves would be configured with a set of introducing
keys whose signatures they accepted for non-stripping.

This way, multiple servers, managed by different individuals, could rely
on a common verification entity (which may not run a keyserver itself).

The current reconciliation protocol (ie. the one used by SKS) would
probably work if all keyservers in a network trusted the same
verification keys, as they would share the same view.
(I admit my utter ignorance of the gossip protocol, though)

It would be desirable that it worked even with separate ones, so eg.
gentoo could use a single server that allowed its own CA and
keys.openpgp.org, even if the later only trusted its own verifier.

Unpublishing of uids would simply be triggered by the publication of the
revocation signature.
This is akin to other systems, like the old "PGP Global Directory Verification
Key" signatures.

I see on https://sequoia-pgp.org/blog/2019/06/14/20190614-hagrid/ that a 
machine-readable vouch was not added since "we don’t think that the 
verification 
is strong enough to even warrant a positive certification". However, I do think
that will be needed in order to have a successful keyserver network, and it 
would
be helpful to separate both roles.
They could be made at the persona cert level (1), to make gpg ignore them (by 
default), though, as a way to disincentive treating them as a CA. 

Kind regards


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Local solutions: SKS Keyserver Network Under Attack

[Peter Lebbing]

Hello Roland,

On 03/07/2019 15:00, Roland wrote:
> And for Enigmail: your suggestion or In the terminal, to edit
> ~/.gnupg/dirmngr.conf so as to say "keyserver
> hkps://keys.openpgp.org/" or, if that file does not exist to create it
> as per your suggestion.

I don't think Enigmail respects dirmngr.conf, it just provides its own
set of keyservers. At least, if I delete them all from the Preferences
dialog of Enigmail, it prompts me to enter a keyserver, defaulting to
the literal text "undefined".

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Local solutions: SKS Keyserver Network Under Attack

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 12:58, pe...@digitalbrains.com said:

> reached its intended goal: dirmngr said "re-reading config". It just
> didn't have an effect for some odd reason. For people thinking about

Check that you do not have a keyserver entry in your gpg.conf or
Enigmail is calling gpg with that options.  The keyserver specified by
gpg overrides whatever dirmngr has been configured to.

  debug ipc
  log-file /some/file

in dirmngr.conf should shows what is going on.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Local solutions: SKS Keyserver Network Under Attack

[Roland]

Thanks, Peter, for this confirmation.

You give further detail to what I had guessed in the course of playing 
with the settings of GPA and Kleopatra.


I conclude that there are at least two possible actions for those who 
want to protect there systems:
In the GUIs of GPA or Kleopatra to fiddle the settings as I suggested 
earlier in this thread. And for Enigmail: your suggestion

or
In the terminal, to edit ~/.gnupg/dirmngr.conf so as to say "keyserver 
hkps://keys.openpgp.org/" or, if that file does not exist to create it 
as per your suggestion.


This could be useful for some mere common GnuPG users, like me.

Greetz

Roland

Some side thoughts:
1/ Perhaps the fear of compromised communication (including distributed 
software, private messages) can be mitigated by practicing short feed 
back lines: confirmations. Like "did you get my communication, what did 
it say?"
2/ Perhaps one should not give too much trust to a WoT at all. After 
all, a crook can pretend to be a friend, and thus yield the entire WoT 
untrustworthy. Sometimes a friend becomes an enemy at a later stage. As 
a very ordinary mere user, I do not really understand the trust levels 
that GnuPG asks me to consider. How can a WoT that is not 100% 
understood by absolutely all users be reliable?
3/ With these thoughts, I hope NOT to embarrass the developers. Forget 
it, if you consider it useless for your troubles. (Thanks for GnuPG!)



On 03/07/2019 12:58, Peter Lebbing wrote:

Hello Roland,


Hansen's and DKG's blog are only partly helpful. For example my Linux
system seems to *not* have a  ~/.gnupg/dirmngr.conf file at all (one
of those files recommended for editing). I.e. Nautilus cannot find it.

The usual case on Linux systems is that if a configuration file would
otherwise be empty or equal to the default (the two can be entirely
different things in general!), the configuration file simply does not
exist.

So instead of modifying ~/.gnupg/dirmngr.conf, *create* one and put a
single line in it saying

keyserver hkps://keys.openpgp.org/

I encountered some strange behaviour here: I invoked

$ gpgconf --reload dirmngr

afterwards (otherwise dirmngr will not reconsider its now changed
configuration), and it *did not work*. It was still using the default.
It did work after I rebooted (I was not in the mood to fiddle more with
it and did the most heavy-handed thing that would work).

Also, Enigmail doesn't seem to use this configuration at all and instead
it is configured at

Enigmail -> Preferences -> Keyserver

I did verify using systemd's journal that the gpgconf --reload command
reached its intended goal: dirmngr said "re-reading config". It just
didn't have an effect for some odd reason. For people thinking about
this: no, I don't use Tor for keyservers, it's not related to dirmngr
refusing to change keyservers when on Tor.

HTH,

Peter.




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Local solutions: SKS Keyserver Network Under Attack

[Peter Lebbing]

Hello Roland,

> Hansen's and DKG's blog are only partly helpful. For example my Linux
> system seems to *not* have a  ~/.gnupg/dirmngr.conf file at all (one
> of those files recommended for editing). I.e. Nautilus cannot find it.

The usual case on Linux systems is that if a configuration file would
otherwise be empty or equal to the default (the two can be entirely
different things in general!), the configuration file simply does not
exist.

So instead of modifying ~/.gnupg/dirmngr.conf, *create* one and put a
single line in it saying

keyserver hkps://keys.openpgp.org/

I encountered some strange behaviour here: I invoked

$ gpgconf --reload dirmngr

afterwards (otherwise dirmngr will not reconsider its now changed
configuration), and it *did not work*. It was still using the default.
It did work after I rebooted (I was not in the mood to fiddle more with
it and did the most heavy-handed thing that would work).

Also, Enigmail doesn't seem to use this configuration at all and instead
it is configured at

Enigmail -> Preferences -> Keyserver

I did verify using systemd's journal that the gpgconf --reload command
reached its intended goal: dirmngr said "re-reading config". It just
didn't have an effect for some odd reason. For people thinking about
this: no, I don't use Tor for keyservers, it's not related to dirmngr
refusing to change keyservers when on Tor.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Werner Koch via Gnupg-users]

On Tue,  2 Jul 2019 13:47, look@my.amazin.horse said:

> Huh, that's interesting. I was not aware of this issue, and wish you had 
> reached
> out to me, or to supp...@keys.openpgp.org, or filed an issue on Hagrid.

I assumed that newly launched server software with the goal to take over
all existing keyservers has been properly tested on the major desktop
platform.

We track the case as https://dev.gnupg.org/T4597

> This BSI requirement was not known to me. While it would be preferable
> to stick

It is not a requirement but it is what has been evaluated.  Changing
anything crypto related requires discussion on whether this will affect
the approval.  It won't be a problem for GnuPG 2.3 because a lot of
things will change there anyway and a re-evaluation will be required.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Vincent Breitmoser via Gnupg-users]

> Unless you are on Windows where the server can't be accessed because it
> uses a pretty limited set of TLS cipher suites.  Thus the majority of
> GnuPG encryption users are out of luck.

Huh, that's interesting. I was not aware of this issue, and wish you had reached
out to me, or to supp...@keys.openpgp.org, or filed an issue on Hagrid.

> Even with the fear of padding oracles on CBC and old as well as a forthcoming
> attack, the restriction of the server to use only GCM based cipher modes is
> not helpful.

This BSI requirement was not known to me. While it would be preferable to stick
with AEAD ciphersuites, I would of course add another ciphersuite if you say you
consider this a worthwhile tradeoff.

It would be good to sort out the policy issue at some point as well, but
I understand that won't happen overnight.

 - V

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Werner Koch via Gnupg-users]

On Tue,  2 Jul 2019 10:01, gnupg-users@gnupg.org said:

> No such issues on keys.openpgp.org, gpg --send-key and the new updated
> key is immediately available with no time outs or delays.

Unless you are on Windows where the server can't be accessed because it
uses a pretty limited set of TLS cipher suites.  Thus the majority of
GnuPG encryption users are out of luck.

On Windows we use the ntbtls library which has not yet support for the
GCM mode and we hesitate to add this to 2.2 because GCM has not been
approved for the use of GnuPG in restricted communication (VS-NfD).  It
is not a technical problem but a policy one which we first need to sort
out.  Even with the fear of padding oracles on CBC and old as well as a
forthcoming attack, the restriction of the server to use only GCM based
cipher modes is not helpful.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Local solutions: SKS Keyserver Network Under Attack [edited]

[Roland]

Dear Forum,

GNUPG Users Digest is nearly flooding my mailbox with exchanges about 
the WoT and keyserver issues.


A simple user (me) needs to know how one could make adaptations in the 
settings of GPA or Kleopatra. I would expect instructions here:

https://kde.org/applications/utilities/org.kde.kleopatra
www.gnupg.org/related_software/gpa/
or perhaps here:
www.gpg4win.org/index.html
www.enigmail.net/index.php/en/
*There are not.*

Hansen's and DKG's blog are only partly helpful. For example my Linux 
system seems to *not* have a  ~/.gnupg/dirmngr.conf file at all (one of 
those files recommended for editing). I.e. Nautilus cannot find it.
So, I did adapt gpg.conf by outcommenting (#) any line starting with 
keyserver, but was not able to adapt the dirmngr.conf.
Upon inspection, thereafter, my GPA and Kleopatra were NOT correctly 
configured.


Trying to figure out how GPA and Kleopatra could be adapted, I found, 
for GPA: Menu > Edit > Backend preferences > Network > Configuration for 
Keyservers > Use custom value > adapt to hkps://keys.openpgp.org
For Kleopatra: Menu > Settings > Configure Kleopatra > Directory 
Services > Open PGP Keyserver > adapt to hkps://keys.openpgp.org
(I would have included an inline screenshot, but this list is allergic 
to html)


Apparently these GUI manipulations generated the ~/.gnupg/dirmngr.conf 
file! (Only hereafter they existed). And that file indeed showed the new 
keyserver.


GPG4Win and Enigmail need further research. (This is a suggestion. I 
cannot do it).


And further, I would have expected a program update that sets the 
defaults to the ones suggested by Hansen and DKG. Or is the matter still 
under consideration, or is it not that important? (I personally cannot 
judge it).


The only hint that I can give: The WoT nor keyservers are not very 
important in my case. I use GnuPG inside a small group of people who 
(for identity verification) can talk to each other, at least by 
telephone. I do not use Enigmail (since limited to few mail clients and 
not accepted by sufficient of my recipients), but just send encrypted 
messages as attachments.


Best regards

Roland



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Local solutions: SKS Keyserver Network Under Attack

[Roland]

Dear Forum,

GNUPG Users Digest is nearly flooding my mailbox with exchanges about 
the WoT and keyserver issues.


A simple user (me) needs to know how one could make adaptations in the 
settings of GPA or Kleopatra. I would expect instructions here:

https://kde.org/applications/utilities/org.kde.kleopatra
www.gnupg.org/related_software/gpa/
or perhaps here:
www.gpg4win.org/index.html
www.enigmail.net/index.php/en/
*There are not.*

Hansen's and DKG's blog are only partly helpful. For example my Linux 
system seems to *not* have a  ~/.gnupg/dirmngr.conf file at all (one of 
those files recommended for editing). I.e. Nautilus cannot find it.
So, I did adapt gpg.conf by outcommenting (#) any line starting with 
keyserver, but was not able to adapt the dirmngr.conf.
Upon inspection, thereafter, my GPA and Kleopatra were NOT correctly 
configured.


Trying to figure out how GPA and Kleopatra could be adapted, I found, 
for GPA: Menu > Edit > Backend preferences > Network > Configuration for 
Keyservers > Use custom value > adapt to hkps://keys.openpgp.org
For Kleopatra: Menu > Settings > Configure Kleopatra > Directory 
Services > Open PGP Keyserver > adapt to hkps://keys.openpgp.org
(I would have included an inline screenshot, but this list is allergic 
to html)


GPG4Win and Enigmail need further research. (This is a suggestion. I 
cannot do it).


And further, I would have expected a program update that sets the 
defaults to the ones suggested by Hansen and DKG. Or is the matter still 
under consideration, or is it not that important? (I personally cannot 
judge it).


The only hint that I can give: The WoT nor keyservers are not very 
important in my case. I use GnuPG inside a small group of people who 
(for identity verification) can talk to each other, at least by 
telephone. I do not use Enigmail (since limited to few mail clients and 
not accepted by sufficient of my recipients), but just send encrypted 
messages as attachments.


Best regards

Roland


On 02/07/2019 05:48, gnupg-users-requ...@gnupg.org wrote:

Send Gnupg-users mailing list submissions to
gnupg-users@gnupg.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.gnupg.org/mailman/listinfo/gnupg-users
or, via email, send a message with subject or body 'help' to
gnupg-users-requ...@gnupg.org

You can reach the person managing the list at
gnupg-users-ow...@gnupg.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gnupg-users digest..."


Today's Topics:

1. Re: Your Thoughts (Stefan Claas)
2. Re: SKS Keyserver Network Under Attack (Alyssa Ross)
3. Re: Your Thoughts (Alyssa Ross)
4. Re: New keyserver at keys.openpgp.org - what's your take?
   (Mirimir)
5. Re: Your Thoughts (Robert J. Hansen)


--

Message: 1
Date: Tue, 2 Jul 2019 00:09:47 +0200
From: Stefan Claas 
To: gnupg-users@gnupg.org
Subject: Re: Your Thoughts
Message-ID: 
Content-Type: text/plain; charset=utf-8

Ryan McGinnis via Gnupg-users wrote:


Null modem transfer of your messages?  Yikes.  To me that?s the issue with
PGP in general as it relates to secure communications - the nerds and the
criminals and the spies know how to work it, but your average end user
doesn?t need their step one to be ?go to a Goodwill in a city you don?t live
in wearing a disguise and buy a laptop with cash?, they need PGP to almost be
automatic.  Think of how easy it is to bootstrap Signal and how hard you?d
have to try to accidentally send something cleartext over that application.
Linking your key to a new device is as easy as scanning QR code. Perfect
forward secrecy, rich media, voice and video synchronous communications
upgrades, you name it.  And my grandma could probably set it up without
help.  I guarantee most big data scooping intelligence services are a lot
more worried about OpenWhisper protocol than PGP because *people actually use
it*.  Just being caught with WhatApp in China can get you sent to a camp,
depending on your ethnicity.

Not to be off-topic, but you gave me the keyword "China" ...

I just recently found this and was wondering what purpose it
serves? Are people in China also allowed to use GnuPG?

pgp.ustc.edu.cn/

Regards
Stefan



--

Message: 2
Date: Mon, 1 Jul 2019 22:43:18 +
From: Alyssa Ross 
To: Mirimir 
Cc: gnupg-users@gnupg.org
Subject: Re: SKS Keyserver Network Under Attack
Message-ID: <20190701224317.x3mffnm63klnx...@x220.qyliss.net>
Content-Type: text/plain; charset="us-ascii"


And yes, hkps://keys.openpgp.org would fall over and die if too many
users started using it. So cert poisoning will be an issue until there's
a secure alternative.

Just as a point of interest, I've talked to the people running
keys.openpgp.org about their capac

Local solutions: SKS Keyserver Network Under Attack

[Roland]

Dear Forum,

GNUPG Users Digest is nearly flooding my mailbox with exchanges about 
the WoT and keyserver issues.


A simple user (me) needs to know how one could make adaptations in the 
settings of GPA or Kleopatra. I would expect instructions here:

https://kde.org/applications/utilities/org.kde.kleopatra
www.gnupg.org/related_software/gpa/
or perhaps here:
www.gpg4win.org/index.html
www.enigmail.net/index.php/en/
*There are not.*

Hansen's and DKG's blog are only partly helpful. For example my Linux 
system seems to *not* have a  ~/.gnupg/dirmngr.conf file at all (one of 
those files recommended for editing). I.e. Nautilus cannot find it.
So, I did adapt gpg.conf by outcommenting (#) any line starting with 
keyserver, but was not able to adapt the dirmngr.conf.
Upon inspection, thereafter, my GPA and Kleopatra were NOT correctly 
configured.


Trying to figure out how GPA and Kleopatra could be adapted, I found, 
for GPA: Menu > Edit > Backend preferences > Network > Configuration for 
Keyservers > Use custom value > adapt to hkps://keys.openpgp.org
For Kleopatra: Menu > Settings > Configure Kleopatra > Directory 
Services > Open PGP Keyserver > adapt to hkps://keys.openpgp.org
(I would have included an inline screenshot, but this list is allergic 
to html)


GPG4Win and Enigmail need further research. (This is a suggestion. I 
cannot do it).


And further, I would have expected a program update that sets the 
defaults to the ones suggested by Hansen and DKG. Or is the matter still 
under consideration, or is it not that important? (I personally cannot 
judge it).


The only hint that I can give: The WoT nor keyservers are not very 
important in my case. I use GnuPG inside a small group of people who 
(for identity verification) can talk to each other, at least by 
telephone. I do not use Enigmail (since limited to few mail clients and 
not accepted by sufficient of my recipients), but just send encrypted 
messages as attachments.


Best regards

Roland


On 02/07/2019 05:48, gnupg-users-requ...@gnupg.org wrote:

Send Gnupg-users mailing list submissions to
gnupg-users@gnupg.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.gnupg.org/mailman/listinfo/gnupg-users
or, via email, send a message with subject or body 'help' to
gnupg-users-requ...@gnupg.org

You can reach the person managing the list at
gnupg-users-ow...@gnupg.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gnupg-users digest..."


Today's Topics:

1. Re: Your Thoughts (Stefan Claas)
2. Re: SKS Keyserver Network Under Attack (Alyssa Ross)
3. Re: Your Thoughts (Alyssa Ross)
4. Re: New keyserver at keys.openpgp.org - what's your take?
   (Mirimir)
5. Re: Your Thoughts (Robert J. Hansen)


--

Message: 1
Date: Tue, 2 Jul 2019 00:09:47 +0200
From: Stefan Claas 
To: gnupg-users@gnupg.org
Subject: Re: Your Thoughts
Message-ID: 
Content-Type: text/plain; charset=utf-8

Ryan McGinnis via Gnupg-users wrote:


Null modem transfer of your messages?  Yikes.  To me that?s the issue with
PGP in general as it relates to secure communications - the nerds and the
criminals and the spies know how to work it, but your average end user
doesn?t need their step one to be ?go to a Goodwill in a city you don?t live
in wearing a disguise and buy a laptop with cash?, they need PGP to almost be
automatic.  Think of how easy it is to bootstrap Signal and how hard you?d
have to try to accidentally send something cleartext over that application.
Linking your key to a new device is as easy as scanning QR code. Perfect
forward secrecy, rich media, voice and video synchronous communications
upgrades, you name it.  And my grandma could probably set it up without
help.  I guarantee most big data scooping intelligence services are a lot
more worried about OpenWhisper protocol than PGP because *people actually use
it*.  Just being caught with WhatApp in China can get you sent to a camp,
depending on your ethnicity.

Not to be off-topic, but you gave me the keyword "China" ...

I just recently found this and was wondering what purpose it
serves? Are people in China also allowed to use GnuPG?

pgp.ustc.edu.cn/

Regards
Stefan



--

Message: 2
Date: Mon, 1 Jul 2019 22:43:18 +
From: Alyssa Ross 
To: Mirimir 
Cc: gnupg-users@gnupg.org
Subject: Re: SKS Keyserver Network Under Attack
Message-ID: <20190701224317.x3mffnm63klnx...@x220.qyliss.net>
Content-Type: text/plain; charset="us-ascii"


And yes, hkps://keys.openpgp.org would fall over and die if too many
users started using it. So cert poisoning will be an issue until there's
a secure alternative.

Just as a point of interest, I've talked to the people running
keys.openpgp.org about their capac

Re: SKS Keyserver Network Under Attack

[Wiktor Kwapisiewicz via Gnupg-users]

Hi Alyssa,

On 02.07.2019 00:43, Alyssa Ross wrote:

The impression I got was that they're very optimistic about their
ability to handle traffic to their server -- they were happy to have a
distro make the switch, and will be changing the defaults in Enigmail
and OpenKeychain very soon, as I understand it.


I did work on one scheme that uses OpenPGP and I did some extensive 
tests even before keys.openpgp.org was announced and in terms of 
reliability it's day vs night compared to SKS.


Hagrid, as far as understand it, serves keys from static files so it by 
design has good performance. SKS on the other hand requires caches in 
front of the server and, in my tests, it was frequent that an old 
version persisted in the cache long after I updated a key.


No such issues on keys.openpgp.org, gpg --send-key and the new updated 
key is immediately available with no time outs or delays.



It is a real shame that a decentralized Hagrid isn't really possible,
though, at least to my understanding. It's quite the limitation for
GnuPG.


Decentralized non-identity information hagrid could still be possible. 
It's just a question over which protocol to synchronize this kind of data.


Kind regards,
Wiktor

--
https://metacode.biz/@wiktor



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Alyssa Ross]

> And yes, hkps://keys.openpgp.org would fall over and die if too many
> users started using it. So cert poisoning will be an issue until there's
> a secure alternative.

Just as a point of interest, I've talked to the people running
keys.openpgp.org about their capacity in #hagrid, when we were exploring
whether to change the default keyserver in Nixpkgs' GnuPG[1] (which we
ended up doing).

The impression I got was that they're very optimistic about their
ability to handle traffic to their server -- they were happy to have a
distro make the switch, and will be changing the defaults in Enigmail
and OpenKeychain very soon, as I understand it.

It is a real shame that a decentralized Hagrid isn't really possible,
though, at least to my understanding. It's quite the limitation for
GnuPG.

[1]: https://github.com/NixOS/nixpkgs/pull/63952


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Leo Gaspard via Gnupg-users]

Mirimir via Gnupg-users  writes:
>>- Embeds a hardcoded list of already-disrupted keys for which packets
>>  should be filtered-out when serving them
>
> That's what I meant. Plus some mechanism for testing keys, so poisoned
> ones are blocked, as soon as possible.
>
> It'd also be useful for SKS to report "this key has been poisoned", and
> suggest alternative sources, rather than just failing silently.

I think we can't rely on humans actually reading the output, even if
GnuPG was able to display the output on eg. `--refresh-keys` in a way
understandable by a human.

Also, the aim of my suggestion was to actually *not* block the
keys. This second point of part 1 is there to just filter some hardcoded
list of packets, thus making key updates still propagate.

The first point was there to prevent additional keys from being
poisoned, and the second to limit the damage caused by already-existing
keys -- the first one is unfortunately quite necessary, as
sks-keyservers can't reasonably be coordinating changes on the ~220
keyservers every time a new key gets poisoned (or even twice, for that
matter, one flag day is already bad enough)

>> Do you think such a plan might be reasonably done, to at least keep the
>> most basic functionality of not breaking existing installations and
>> allow them to keep revocations flowing? The biggest issue I can see is
>> it requires a quite big amount of development work.
>
> But less work than actually fixing SKS, right?

Well, nowadays “fixing SKS” means “making hagrid able to synchronize its
cryptographic-only content and propagate third-party signatures under
some circumstances”, as far as I understand.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Mark Rousell]

On 01/07/2019 10:54, Robert J. Hansen wrote:
>> I think not.
> Thankfully we live in free societies where dissent is allowed: on good
> days, even tolerated and encouraged.  You're wrong, of course, but
> please understand I encourage you to be wrong.  :)
>
> Also, if it isn't clear: although I emphatically disagree with you, this
> is not a personal dispute.  I plan on turning your idea into a pinata,
> but on a personal level as far as I'm concerned there's nothing but
> peace between us.

I can see that you are (rightly and understandably) very, very angry
that this has been done and that you have been personally targetted but
it nevertheless seems to me that it is not a childish act. Its very
carefully targetted nature strongly suggests to me that is was done to
produce specific results (which should actually be beneficial for the
community as a whole).

This does not mean that I condone the act. I do not! It was a bad thing
to do in this form.

>
>> You yourself say that the SKS system has had known problems for well 
>> over a decade and yet nothing has been done about it.
> No.  No.  No.  I have not said that.  In the last ten years the
> sks-de...@nongnu.org community has explored pretty thoroughly the
> problem space and concluded it cannot be solved at the SKS level, given
> the community's level of manpower and funding.

And yet, despite this, SKS is still in use and not currently fully
replaceable, as I understand it.

Is that not a problem of inertia? It certainly seems like it to me. No
natter what the issue of lack of manpower or lack of funding, if these
have not been overcome in 10+ years despite there being widely
recognised problems then that's inertia. (No, this is not
"victim-blaming". Read on for why not).

However, all is not so dark as it might seem. You go to say...

> In a very real sense, WKD, Autocrypt, Hagrid, dkg's work in
> abuse-resistant keyservers, and so forth, all sprang from the sks-devel
> community's recognition of the problem and the inability of SKS to
> effectively fix it.  If SKS were in better shape it's likely none of
> those projects would have ever started.

But this is good. It means that, in large part, inertia has in fact been
overcome from new directions. People have contributed to improving
things through innovation and new approaches.

It just needs to go that little bit further, it seems.

> There is a line of thinking which I find to be morally appalling, and
> you describe it quite clearly in your footnote:
>
>> 1: You referred to this inertia as "powerful technical and social 
>> factors" which is true but they still represent a bug, not a
>> feature. These factors are in effect societal excuses, not legitimate
>> reasons for lack of action.
> If the sks-devel community has repeatedly made it clear over the course
> of a decade that "we lack both the manpower and the financial resources
> to fix this problem", never receives manpower or financial resources,
> and then ten years later this happens... our reward is to be
> victim-blamed?  "If you were really serious you would've done something
> by now"?

Don't be silly. I was merely pointing out how change is sometimes needed
to overcome roadblocks. In corporate circles they (annoyingly enough)
call it "thinking out of the box".

Furthermore, I am not "victim-blaming" as you claim. Lack of manpower
and funding is not what I regard as victimhood. Lack of manpower and/or
finding is just normal life for many, many projects or human endeavours
and is a natural and normal issue that needs to be overcome somehow for
any project or endeavour of almost any type to initially succeed and
then to be maintained.

In my own case, I am involved in a project that I would dearly like to
do better and it is in fact held back by lack of both manpower and
funding. However, when people tell me that I need to overcome these
issues, no matter how difficult they are to overcome, I do not claim
victimhood or say that my critic is "victim-blaming" me. Instead I agree
and ask my critic for possible sources of manpower or funding, or for
other ways to address the issues that the project is intended to solve.
And you will note in the footnote I did in fact mention an initiative
that Eric S. Raymond is working on that might, at least in part, address
issues of funding. So I have not made the mistake of criticising without
at least offering some possible solution to the obvious problem.

>
>> of this community, they have brought absolutely unavoidable attention
>> to the fact that something needs to be done *now*.
> At a tremendous price.  A price that I, and many others, think is
> morally appalling.  These people are not our friends and have done us no
> favors.

Time will tell. Do you think that something substantive will now be done
that could not be done before because of previous lack of manpower or
funding?

Sometimes, the obvious and undeniable existence and public highlighting
of an egregious flaw prompts the new availabi

Re: SKS Keyserver Network Under Attack

[Alyssa Ross]

> Third-party signatures from locally unknown certificates are arguably
> not so useful, so how about using ?--keyserver-options import-clean??
> (Or even making it the default behavior?)  Of course it's not perfect as
> it still clutters network traffic and gpg(1) needs to clean up the mess
> client-side (which is slow and CPU expensive), but at least it mitigates
> the DoS attack: it doesn't prevent keyring updates, and limits the bloat
> on disk.

Alas, this doesn't fully mitigate the issue, because it's not exactly
difficult to get a key into somebody's keyring, especially with the
existence of the auto-key-retrieve option. All I would have to do would
be to sign the key of somebody in the strong set lots of times with
the same key, and then send you an email signed by me, and an email with
a body signed by the key I was attacking (I could find some sort of
statement signed by that key online somewhere). Alternatively, I could
construct a Git repository that would load the keys into your keychain
in the correct order when you examined the commit signatures if I could
find a commit signed by my victim somewhere. I'm sure it's easy enough
to get a public key imported even without auto-key-retrieve, too. I
imagine there are MUAs that would import a key attached to a message,
maybe.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Peter Lebbing]

On 01/07/2019 11:54, Robert J. Hansen wrote:
> [...]

I think this mail sums up the most important points about this whole
ordeal very well. I completely, wholeheartedly agree. I encourage
everyone to re-read it and internalise it.

The only point not touched upon in this specific mail, I think, is why
people who say that the damage that has been done is not of consequence,
are wrong.

It seems to me that rjh's and dkg's keys will be in many public keyrings
and in many (key) signature chains, and thus have the potential to cause
major problems for many people all around the world when they refresh
their keys. I'd say the consequences of poisoning precisely these
well-connected keys are pretty major. People who depend upon OpenPGP
will find their software is hung and timing out, even when they're not
trying to do anything with these specific public keys: often it's enough
the poison is on the keyring, as far as I can tell. Lacking the
knowledge to fix this, they will no longer be able to check signatures,
and probably be unable to read encrypted messages altogether.

For me, that'd be a nuisance.

For some people, it may have very large real-life consequences.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Robert J. Hansen]

> I think not.

Thankfully we live in free societies where dissent is allowed: on good
days, even tolerated and encouraged.  You're wrong, of course, but
please understand I encourage you to be wrong.  :)

Also, if it isn't clear: although I emphatically disagree with you, this
is not a personal dispute.  I plan on turning your idea into a pinata,
but on a personal level as far as I'm concerned there's nothing but
peace between us.

> You yourself say that the SKS system has had known problems for well 
> over a decade and yet nothing has been done about it.

No.  No.  No.  I have not said that.  In the last ten years the
sks-de...@nongnu.org community has explored pretty thoroughly the
problem space and concluded it cannot be solved at the SKS level, given
the community's level of manpower and funding.

That's not "nothing".  That's a very important result and it is
literally the most the sks-devel community can be asked or expected to
do, given their critical shortages of money and manpower.

In a very real sense, WKD, Autocrypt, Hagrid, dkg's work in
abuse-resistant keyservers, and so forth, all sprang from the sks-devel
community's recognition of the problem and the inability of SKS to
effectively fix it.  If SKS were in better shape it's likely none of
those projects would have ever started.

There is a line of thinking which I find to be morally appalling, and
you describe it quite clearly in your footnote:

> 1: You referred to this inertia as "powerful technical and social 
> factors" which is true but they still represent a bug, not a
> feature. These factors are in effect societal excuses, not legitimate
> reasons for lack of action.

If the sks-devel community has repeatedly made it clear over the course
of a decade that "we lack both the manpower and the financial resources
to fix this problem", never receives manpower or financial resources,
and then ten years later this happens... our reward is to be
victim-blamed?  "If you were really serious you would've done something
by now"?

It's like telling a doctor in the developing world who has for ten years
been screaming that she needs polio vaccine, after a polio epidemic
starts in her neighborhood, "the poverty is in effect a societal excuse,
not a legitimate reason for lack of action"?

It takes stuff to do stuff, and it's really rude to blame the victims
for problems they inherited but did not create.

> Well, someone has now brought widespread attention to the issue. By 
> poisoning the certificate of (at least) two very high-profile 
> members

Three now, since apparently Kristian has been hit.

> of this community, they have brought absolutely unavoidable attention
> to the fact that something needs to be done *now*.

At a tremendous price.  A price that I, and many others, think is
morally appalling.  These people are not our friends and have done us no
favors.

> Good can come of this attack on you and DKG.

I seem to recall people saying the same after 9/11: that yes it was a
horrific thing, but that "good can come of this tragedy".

I seem to recall people saying the same after my best friend's suicide:
that yes it was a horrific thing, but that "good can come of this tragedy".

It is the nature of goodness that, like hope, it springs eternal and in
the most unlikely of places.  But it is also barbarous to claim the good
that may come out of a horror should be counted to the horror's credit.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Mark Rousell]

On 30/06/2019 13:44, Robert J. Hansen wrote:
> This has all the hallmarks of a child playing with matches and
> clapping with glee as the house catches fire.

I think not.

You yourself say that the SKS system has had known problems for well
over a decade and yet nothing has been done about it. In other words,
inertia has overruled both prudence and strategic avoidance of
predictable problems[1].

Well, someone has now brought widespread attention to the issue. By
poisoning the certificate of (at least) two very high-profile members of
this community, they have brought absolutely unavoidable attention to
the fact that something needs to be done *now*. As things stand, it's
still not too late for something to be done to protect the vast majority
of users and use cases.

Good can come of this attack on you and DKG.

Yes, as you say in your Gist, the attackers could have come to you and
worked together. But I can also understand why they didn't: This
approach has made waves, and sometimes waves are necessary to wake up a
community that really knows it should be taking action but hasn't done so.

Both you and DKG are clearly furious that you were targetted (and
rightly so!) but if 'lesser' members of the community had been attacked
in this way it's entirely possible that either no one would have noticed
or that it would not have had the radical shake up effect that this is
now having.

I'm not condoning an attack like this. In the UK (where I am located) it
is likely to be illegal, and it is probably illegal in other
jurisdictions. But I just don't see a "child [...] clapping with glee".

Instead it seems to me that the net result is that long overdue action
is now taking place.

Thank you for all your input into OpenPGP. Yes, it's made you a target.
But, despite the seemingly personal nature of this, it does seem that
good can come of it.

(And for the avoidance of doubt: I do not know who was behind this and
it was not me.)




Footnote:-
1: You referred to this inertia as "powerful technical and social
factors" which is true but they still represent a bug, not a feature.
These factors are in effect societal excuses, not legitimate reasons for
lack of action. As I write this, I fully appreciate the fact that very
few people receive remuneration for writing code or maintaining key
servers (or much of anything else connected with OpenPGP). But again,
perhaps this is also a bug of sorts. Perhaps there does need to be a way
for critical non-hierarchical Internet infrastructure like this to be
financed. Isn't Eric S. Raymond working on something like this right now?

-- 
Mark Rousell

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Chris Narkiewicz via Gnupg-users]

> I must have missed the memo
> describing the exact nature of the problem.

https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Robert J. Hansen]

> OK, that's great news. And I get from the HN thread that repository keys
> are updated via signed packages, with no calls to SKS keyservers. So I'm
> no longer freaking about that level of damage.

Eh.  Yes.  No.  Hard to say.  The problem is that many of these distros
allow third parties to run their own repositories under more permissive
rules, and some of these third parties are extremely popular.  Plus,
often sysadmins will roll their own RPMs of packages: in such cases you
quickly lose the ability to say definitively what will or will not happen.

If the major distros update their distro signing certificates through
signed packages, great: that's good.  But don't go thinking that means
you're out of the woods.

Whenever anyone gives you concrete yes-or-no, this will-or-won't happen
answers about a complicated ecosystem that has a ton of hidden bits that
can't be seen, that person most likely has misunderstood the problem.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Mirimir via Gnupg-users]

On 06/30/2019 10:37 AM, Leo Gaspard via Gnupg-users wrote:
>> 1. We would have to ensure that all keyservers block the same
>> uploads. One permissive keyserver is a backdoor into the entire
>> system. We can’t block bad keys at reconciliation time for the same
>> reasons that have been hashed to death already.
> 
> One way to do that, though it would mean officially sunsetting SKS,
> might be to:
> 
> 1. Publish an update to SKS that:
>- Blocks all uploads of any packet that is not a revocation signature
>  packet (maybe also having to check the revocation is actually
>  correctly signed, to avoid flooding of revocation packets to become
>  the new flaw)

I wasn't suggesting that. As long as only a few keys are being poisoned,
it's arguably not necessary, and too disruptive. But if this becomes a
game in the chans, that might become necessary.

>- Embeds a hardcoded list of already-disrupted keys for which packets
>  should be filtered-out when serving them

That's what I meant. Plus some mechanism for testing keys, so poisoned
ones are blocked, as soon as possible.

It'd also be useful for SKS to report "this key has been poisoned", and
suggest alternative sources, rather than just failing silently.

> 2. Pressure keyserver operators into updating
> 
> 3. Kick all not-up-to-date keyservers from the pool after some delay
>deemed acceptable (shorter means less broken GnuPG, longer means less
>keyservers kicked out)
>Note: I do not know how the pool is handled. Maybe this would mean
>that the new update to SKS would need to stop synchronizing with
>earlier versions, and that the hkps pool should be turned off until
>enough keyservers are updated to handle the load?

Makes sense.

> Do you think such a plan might be reasonably done, to at least keep the
> most basic functionality of not breaking existing installations and
> allow them to keep revocations flowing? The biggest issue I can see is
> it requires a quite big amount of development work.

But less work than actually fixing SKS, right?

> Hope that helps,
>   Leo
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Mirimir via Gnupg-users]

On 06/30/2019 08:55 AM, Andrew Gallagher wrote:
> 
>> On 30 Jun 2019, at 15:07, Erich Eckner via Gnupg-users 
>>  wrote:
>>
>> maybe I don't get the original idea - but I thought, it was to block 
>> *uploads/updates* which would poisson a certificate - not to blackhole them 
>> after they got poissoned?

No, I did mean blackholing poisoned certs.

> Hm, that’s not how I read it, although I could be wrong. It is possible to 
> prevent submission of bad keys, but this just leads to new problems:
> 
> 1. We would have to ensure that all keyservers block the same uploads. One 
> permissive keyserver is a backdoor into the entire system. We can’t block bad 
> keys at reconciliation time for the same reasons that have been hashed to 
> death already. 
> 
> 2. Although it may be possible to block an individual upload of tens of 
> thousands of key packets, it will not in general be possible to prevent an 
> attacker from incrementally increasing the number of packets attached to a 
> key over time. If we impose a reasonable limit on the cumulative number of 
> packets attached to a key, that key may never become undownloadable, but it 
> will at some point become unmodifiable - so we have just transformed one DOS 
> vector into a different one.
> 
> A 

It does seem that it's impossible to keep certs on the current SKS
network from being poisoned. I only see two alternatives: 1) fixing SKS,
and 2) replacing SKS. And meanwhile, preventing poisoned certs on SKS
from doing further damage.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Mirimir via Gnupg-users]

On 06/30/2019 08:33 AM, Peter Lebbing wrote:
>> "Look, this one guy who just got mugged? [...]
> 
> I had to read it twice to distill what I think Mirimir meant, but I
> think they meant that if you blacklist/blackhole all affected
> certificates, you remove the incentive for the attackers to poison more
> certificates since the poison can't spread to the people fetching keys.
> Thus stopping the attackers.

Thanks. That's almost right. But I'm not focusing on incentives. I'm
focusing only on impacts. Because as I understand it, you can't stop
people from poisoning certificates on the SKS keyservers.

> I concluded that Mirimir perhaps forgot about that this creates a second
> attack model, where you can block keys from being on the keyserver. This
> seems like a new problem that means this stopgap measure is probably not
> the one we want, since it still provides the incentive for attackers to
> poison keys.
> 
> Peter.

I didn't forget about that. I just don't think that it matters. Unless
I've misunderstood the situation, the SKS keyservers are dead meat. And
have been dead meat for a decade.

So the focus has gotta be on a secure and capable replacement. And
meanwhile, on mitigating damage done through the SKS keyservers.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Mirimir via Gnupg-users]

On 06/30/2019 07:33 AM, Robert J. Hansen wrote:
>> Your third point is actually why I suggested this. Maybe I'm just
>> twisted, but what if some dickhead goes after certs that would break
>> stuff for millions of people? One might, for example, block Linux kernel
>> maintenance and development. Maybe just before using some 0-day.
> 
> For whatever it's worth, as soon as I heard word there were poisoned
> certificates in the strong set I spoke to a friend who's well-connected
> in the kernel community and made sure to pass on the warning and the
> mitigation.
> 
> I am not worried about the kernel hackers being hit.  They're
> technically savvy, close-knit, and largely self-sufficient technologically.

OK, that's great news. And I get from the HN thread that repository keys
are updated via signed packages, with no calls to SKS keyservers. So I'm
no longer freaking about that level of damage.

> I'm very worried about people who lack technical skills (for many
> people, just editing a config file is beyond them), who are in loose
> contact with the GnuPG/keyserver community (people who might check in
> once a year to see if there's any major updates), who are dependent on
> others for their communications ("I don't know how this works, my IT
> department sets it up for me").
> 
> Those people are -very- vulnerable to this.  They're going to get hit hard.

Yes, people like me. Whose Enigmail was setup to query SKS keyservers.
So somehow they must be alerted.

>> It would stop when certs can no longer be poisoned.
> 
> Please show me how we can prevent certs from being poisoned.  This is a
> phenomenally hard problem.  You are handwaving away a huge amount of
> difficulty.
> 
> What you are saying here is, "it would never end."

Well, given what you've said about the chances that SKS keyservers will
get fixed, it would likely never end for them. From what I've read, I
gather that spam signatures to them can't be blocked.

But using keyservers like hkps://keys.openpgp.org, certs couldn't be
poisoned, right? Right now, I gather, keys can't even be signed after
uploading. So basically, it would end when we switch to them, or to
another secure alternative.

And yes, hkps://keys.openpgp.org would fall over and die if too many
users started using it. So cert poisoning will be an issue until there's
a secure alternative.

>> I don't see that as "doing the bad guys’ work for them". I see it as
>> preventing bad guys escalating from hurting a few people to doing
>> serious damage. That's not "punishing the victim".
> 
> "Look, this one guy who just got mugged?  Clearly the street gang
> doesn't like him.  So if we just, you know, don't help him, then the
> gang won't also go after us.  We're not 'punishing the victim'.  We're
> just saying, the needs of the many outweigh the needs of the few.  I
> mean, it's too bad, what's happening to him.  And it's too bad the gang
> is making us turn our backs and walk away.
> 
> I bet that once we're a block away we're not going to be able to hear
> him screaming.
> 
> Come on, let's walk faster."

I apologize. I know that this has been horrible for you. And I get that
it's not at all your fault.

Nonetheless, your key on the SKS keyservers is hosed. It could happen to
anyone. And given the design, it can't be fixed.

However, it's not like your key and its authentic signatures are lost.
You have it on your machines, it's at https://keybase.io/rjh, and you
could put the key on hkps://keys.openpgp.org or another keyserver.

So it's not you that's getting thrown under the bus. It's the SKS
keyserver network that's getting thrown under the bus.

And if someone needed signatures only available from the SKS keyservers,
there must be some way to recover them. One could import the key safely,
edit the signatures, and then put it on some secure keyserver.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Guilhem Moulin]

On Sun, 30 Jun 2019 at 22:23:11 +, Alyssa Ross wrote:
>> Third-party signatures from locally unknown certificates are arguably
>> not so useful, so how about using ?--keyserver-options import-clean??
>> (Or even making it the default behavior?)  Of course it's not perfect as
>> it still clutters network traffic and gpg(1) needs to clean up the mess
>> client-side (which is slow and CPU expensive), but at least it mitigates
>> the DoS attack: it doesn't prevent keyring updates, and limits the bloat
>> on disk.
> 
> Alas, this doesn't fully mitigate the issue, because it's not exactly
> difficult to get a key into somebody's keyring, especially with the
> existence of the auto-key-retrieve option.

Ah yeah, good point.  At least this vastly limits the scope of the
attack: instead of affecting every keyring upon refresh/import, the
attacker needs to somewhat target which keyring they want to poison.

-- 
Guilhem.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Guilhem Moulin]

On Sun, 30 Jun 2019 at 00:36:19 -0700, Mirimir via Gnupg-users wrote:
> | High-risk users should stop using the keyserver network immediately.
> 
> So OK, I can purge requests to SKS keyservers from my machines. But what
> about upstream impacts? As I understand it, GnuPG authentication is
> pervasive. And I suspect that getting missing keys from SKS is common.
> As an error trap, if nothing else.

Third-party signatures from locally unknown certificates are arguably
not so useful, so how about using ‘--keyserver-options import-clean’?
(Or even making it the default behavior?)  Of course it's not perfect as
it still clutters network traffic and gpg(1) needs to clean up the mess
client-side (which is slow and CPU expensive), but at least it mitigates
the DoS attack: it doesn't prevent keyring updates, and limits the bloat
on disk.

Compare

~$ export GNUPGHOME="$(mktemp --tmpdir=/dev/shm --directory)"
~$ alias time="command time -f '%E (%U user, %S sys)  %P CPU  %Mk maxres'"
~$ gpg --import /usr/share/keyrings/*.gpg
~$ gpg --with-colons --list-sigs | grep -c ^pub:
1187
~$ gpg --with-colons --list-sigs | grep -c ^sig:
56001
~$ stat -c %s "$GNUPGHOME/pubring.kbx"
34041308
~$ time gpg --recv-keys \
C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 \
CC11BE7CBBED77B120F37B011DCBDC01B44427C7
gpg: key 1DCBDC01B44427C7: 149109 signatures not checked due to missing keys
gpg: error writing keyring '…/pubring.kbx': Provided object is too large
gpg: key F20691179038E5C6: 54608 signatures not checked due to missing keys
gpg: error writing keyring '…/pubring.kbx': Provided object is too large
[…]
Command exited with non-zero status 2
10:53.44 (269.47 user, 362.81 sys)  96% CPU  330976k maxres

(which fails the keyring update operation) with

[…]
~$ time gpg --keyserver-options import-clean --recv-keys \
C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 \
CC11BE7CBBED77B120F37B011DCBDC01B44427C7
gpg: key 1DCBDC01B44427C7: 1 duplicate signature removed
gpg: key 1DCBDC01B44427C7: 1 signature reordered
gpg: key 1DCBDC01B44427C7: public key "Robert J. Hansen 
" imported
gpg: key F20691179038E5C6: 2 duplicate signatures removed
gpg: key F20691179038E5C6: 2 signatures reordered
gpg: key F20691179038E5C6: "Daniel Kahn Gillmor " 
not changed
gpg: no ultimately trusted keys found
gpg: Total number processed: 2
gpg:   imported: 1
gpg:  unchanged: 1
49:48.80 (1668.47 user, 1305.03 sys)  99% CPU  190840k maxres

(The initial import of /usr/share/keyrings/*.gpg is merely there to
start with a non-trivial keyring.  In particular, a keyring containing
certificates that issued third-party signatures on 1DCBDC01B44427C7 and
F20691179038E5C6.  The keyring even contains a non-poisoned version of
dkg's key, as on my system the glob matches 
‘/usr/share/keyrings/debian-keyring.gpg’.)

I suppose validating keyservers are the way to go, but it seems like
there is currently no good solution for third-party signatures.  For
workflow relying on these (at least for locally known signers), or which
for some other reason need to stick to SKS, a possible mitigation is to
pass `--keyserver-options import-clean`.  As seen above refreshing the
keyring might take a veeery long time (possibly room for improvement,
from an algorithmic perspective I don't get why filtering signature
packets from unknown signers is so slow), but at least succeeds in
getting updates from SKS. 

-- 
Guilhem.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Leo Gaspard via Gnupg-users]

> 1. We would have to ensure that all keyservers block the same
> uploads. One permissive keyserver is a backdoor into the entire
> system. We can’t block bad keys at reconciliation time for the same
> reasons that have been hashed to death already.

One way to do that, though it would mean officially sunsetting SKS,
might be to:

1. Publish an update to SKS that:
   - Blocks all uploads of any packet that is not a revocation signature
 packet (maybe also having to check the revocation is actually
 correctly signed, to avoid flooding of revocation packets to become
 the new flaw)
   - Embeds a hardcoded list of already-disrupted keys for which packets
 should be filtered-out when serving them

2. Pressure keyserver operators into updating

3. Kick all not-up-to-date keyservers from the pool after some delay
   deemed acceptable (shorter means less broken GnuPG, longer means less
   keyservers kicked out)
   Note: I do not know how the pool is handled. Maybe this would mean
   that the new update to SKS would need to stop synchronizing with
   earlier versions, and that the hkps pool should be turned off until
   enough keyservers are updated to handle the load?

Do you think such a plan might be reasonably done, to at least keep the
most basic functionality of not breaking existing installations and
allow them to keep revocations flowing? The biggest issue I can see is
it requires a quite big amount of development work.

Hope that helps,
  Leo

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Konstantin Ryabitsev]

On Sun, Jun 30, 2019 at 03:49:55AM -0700, Mirimir via Gnupg-users wrote:

c) what happens when they go after more certificates?

If you're willing to blackhole two certs, great.  Where does it stop?
How many certs can the strong set stand to lose?


Your third point is actually why I suggested this. Maybe I'm just
twisted, but what if some dickhead goes after certs that would break
stuff for millions of people? One might, for example, block Linux kernel
maintenance and development. Maybe just before using some 0-day.


I highly doubt this would be effective, mainly because I don't think 
anyone on the kernel development side of things runs keyring refreshes 
in any routine fashion -- if ever. For those relying on PGP to verify 
downloaded releases, we provide WKD lookups 
(https://www.kernel.org/signature.html).


This whole thing *will* probably push me towards setting up a Hagrid 
instance, especially if we can teach it to compare submissions against 
an allow-list. Not sure what I'm going to do about the whole "web of 
trust" side of things, though. I *really* don't like the idea of setting 
up any kind of certification/trust authority.


-K

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Andrew Gallagher]

> On 30 Jun 2019, at 15:07, Erich Eckner via Gnupg-users 
>  wrote:
> 
> maybe I don't get the original idea - but I thought, it was to block 
> *uploads/updates* which would poisson a certificate - not to blackhole them 
> after they got poissoned?

Hm, that’s not how I read it, although I could be wrong. It is possible to 
prevent submission of bad keys, but this just leads to new problems:

1. We would have to ensure that all keyservers block the same uploads. One 
permissive keyserver is a backdoor into the entire system. We can’t block bad 
keys at reconciliation time for the same reasons that have been hashed to death 
already. 

2. Although it may be possible to block an individual upload of tens of 
thousands of key packets, it will not in general be possible to prevent an 
attacker from incrementally increasing the number of packets attached to a key 
over time. If we impose a reasonable limit on the cumulative number of packets 
attached to a key, that key may never become undownloadable, but it will at 
some point become unmodifiable - so we have just transformed one DOS vector 
into a different one.

A 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Erich Eckner via Gnupg-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 30 Jun 2019, Andrew Gallagher wrote:


On 2019/06/30 11:49, Mirimir via Gnupg-users wrote:

It would stop when certs can no longer be poisoned. And I don't see the
downside. I mean, what good does it do to have people downloading keys
that break their stuff?

I don't see that as "doing the bad guys’ work for them". I see it as
preventing bad guys escalating from hurting a few people to doing
serious damage. That's not "punishing the victim".


It prevents escalation, yes. But at the expense of exiling the targeted
people from the network - which may well be the attacker's real intent.

Any "solution" that turns a general problem into a problem for a small
number of *specific individuals* is not a solution, it's a lynching. I'm
sure those specific individuals will be thankful that they've been
thrown under the bus for the greater good. I'm sure nobody else will be
looking over their shoulder wondering whether they'll be next.

We solve this issue for *everyone*, or we all go home.

--
Andrew Gallagher




Hi,

maybe I don't get the original idea - but I thought, it was to block 
*uploads/updates* which would poisson a certificate - not to blackhole 
them after they got poissoned?


cheers,
Erich

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl0YwjkACgkQCu7JB1Xa
e1ozlA/+O7leg3qYlW1KO8+z1cE2IDe03CDUYX1PovzIpbxSiSYREEqbcJJkelqv
Bp1h8LZKUZuRNYIHD7NbFYMSUMaJTpI6S1p3stN214cK5vqY01x6ncEMvtpHJTGK
/87VtN+g+9qch59lCAZMjOrVtrgW0R5AqCsjIisPFAPyAHjNYF+EjQ5xQkYfVq35
ny4TJXjSBjCzFO8+OcUW5ThHGwIq5CL6CW5PFmPDtkzIdI/yPowq20BWHz/AGiSq
uxe32hKyJXNABe0Ow73NB4IOK8GrlGuUs2WAoMDKfQaBdNNguqgf8rSP52BLhtUT
wY1xI2f/6mpi7Ygrwqnw6kIHEvhFAVR5T3KobLERn7B9uiXlBAp+PVIc/QDuPFG5
dVMgBacuGdXXM+dpjGKYbDVi1WYVr5JyqeJwNOiC/0fyNgO69HQGmSPPsFFauo9s
i2pbVO/cv9X/aF9KLCcBbMP/nKHokLnShU3xAoIinFdGHN68iFVCPGlQhLwGlpMN
0Xq52TVjlpwt8OtEak0GIPhdyXQQkLrZnsDc2sB6s99u8R0L78KFoWAorvTDP9Hb
o8+rz93AZxiObn9q2iTKYve0tWLuvTUTiTmgd42I2qFLNIfGLQCBtkqpcgBje4AK
S6mrCP8AMrdhO3bOU1bdarN4FEonV6DUHAk8aMiqbwp1quAyHaw=
=+Lsx
-END PGP SIGNATURE-___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Peter Lebbing]

> "Look, this one guy who just got mugged? [...]

I had to read it twice to distill what I think Mirimir meant, but I
think they meant that if you blacklist/blackhole all affected
certificates, you remove the incentive for the attackers to poison more
certificates since the poison can't spread to the people fetching keys.
Thus stopping the attackers.

I concluded that Mirimir perhaps forgot about that this creates a second
attack model, where you can block keys from being on the keyserver. This
seems like a new problem that means this stopgap measure is probably not
the one we want, since it still provides the incentive for attackers to
poison keys.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Jerry]

On Sun, 30 Jun 2019 08:44:43 -0400, Robert J. Hansen stated:
>> What would have prevented a state level actor from activating this
>> exploit on a wide level during a time when it would have been most
>> effective for them?  
>
>A nation-state with a professional intelligence service probably isn't
>very interested in taking down the keyserver network.  Why should they
>take down something that's not a big priority for them, especially if
>it'll cost them a lot of international goodwill if it gets attributed
>to them?

I seriously doubt that a nation, such as North Korea or China, a nation
that openly runs over its own citizens, would much care what anyone
thought. However, I do agree with your general premise.

>This has all the hallmarks of a child playing with matches and clapping
>with glee as the house catches fire.

While that is probably correct, it could also be attributed to some
intelligence agency trying to test a 'proof of concept' in the real
world in real time. Never-the-less, I think that Ockham's Razor applies
here.

-- 
Jerry


pgplAAwhgBEFN.pgp
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Ryan McGinnis via Gnupg-users]

I can’t speak for others, but I wasn’t suggesting you were personally 
responsible for where things are right now, only making observations about the 
utility of continuing to use the product going forward, and what the targeted 
end users likely expect from the software.

-Ryan McGinnis
http://bigstormpicture.com
PGP: 486ED7AD
Sent with ProtonMail Secure Email

On Sun, Jun 30, 2019 at 08:50, Robert J. Hansen  wrote:

>> I guess that’s one way to look at it, but if your end users are
>> dissidents and journalists communicating in happy fun places or
>> developers signing critical software, then surely you’d want the
>> product to be resilient against 10 year old trivial attacks from your
>> users’ adversaries.
>
> I feel like I am screaming into the void here. I'm going to be quite
> blunt because the message is just not getting through:
>
> I don't get to decide these things. Stop implying that I do. Stop
> blaming me for other people's decisions. And stop thinking that I have
> *anything whatsoever to do with the keyservers*. I don't. I understand
> them but I am not a developer on them. I don't even run a keyserver.
> And if you knew the first thing about the keyservers you would know this
> without needing me to tell you.
>
> So please forgive me for not wanting to have a conversation with you. I
> am getting very tired of people confusing "Rob understands the current
> mess" with "so I'm going to impugn his competence".
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Robert J. Hansen]

> Your third point is actually why I suggested this. Maybe I'm just
> twisted, but what if some dickhead goes after certs that would break
> stuff for millions of people? One might, for example, block Linux kernel
> maintenance and development. Maybe just before using some 0-day.

For whatever it's worth, as soon as I heard word there were poisoned
certificates in the strong set I spoke to a friend who's well-connected
in the kernel community and made sure to pass on the warning and the
mitigation.

I am not worried about the kernel hackers being hit.  They're
technically savvy, close-knit, and largely self-sufficient technologically.

I'm very worried about people who lack technical skills (for many
people, just editing a config file is beyond them), who are in loose
contact with the GnuPG/keyserver community (people who might check in
once a year to see if there's any major updates), who are dependent on
others for their communications ("I don't know how this works, my IT
department sets it up for me").

Those people are -very- vulnerable to this.  They're going to get hit hard.

> It would stop when certs can no longer be poisoned.

Please show me how we can prevent certs from being poisoned.  This is a
phenomenally hard problem.  You are handwaving away a huge amount of
difficulty.

What you are saying here is, "it would never end."

> I don't see that as "doing the bad guys’ work for them". I see it as
> preventing bad guys escalating from hurting a few people to doing
> serious damage. That's not "punishing the victim".

"Look, this one guy who just got mugged?  Clearly the street gang
doesn't like him.  So if we just, you know, don't help him, then the
gang won't also go after us.  We're not 'punishing the victim'.  We're
just saying, the needs of the many outweigh the needs of the few.  I
mean, it's too bad, what's happening to him.  And it's too bad the gang
is making us turn our backs and walk away.

I bet that once we're a block away we're not going to be able to hear
him screaming.

Come on, let's walk faster."

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Andrew Gallagher]

On 2019/06/30 11:49, Mirimir via Gnupg-users wrote:
> It would stop when certs can no longer be poisoned. And I don't see the
> downside. I mean, what good does it do to have people downloading keys
> that break their stuff?
> 
> I don't see that as "doing the bad guys’ work for them". I see it as
> preventing bad guys escalating from hurting a few people to doing
> serious damage. That's not "punishing the victim".

It prevents escalation, yes. But at the expense of exiling the targeted
people from the network - which may well be the attacker's real intent.

Any "solution" that turns a general problem into a problem for a small
number of *specific individuals* is not a solution, it's a lynching. I'm
sure those specific individuals will be thankful that they've been
thrown under the bus for the greater good. I'm sure nobody else will be
looking over their shoulder wondering whether they'll be next.

We solve this issue for *everyone*, or we all go home.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Robert J. Hansen]

> I guess that’s one way to look at it, but if your end users are
> dissidents and journalists communicating in happy fun places or
> developers signing critical software, then surely you’d want the
> product to be resilient against 10 year old trivial attacks from your
> users’ adversaries.

I feel like I am screaming into the void here.  I'm going to be quite
blunt because the message is just not getting through:

I don't get to decide these things.  Stop implying that I do.  Stop
blaming me for other people's decisions.  And stop thinking that I have
*anything whatsoever to do with the keyservers*.  I don't.  I understand
them but I am not a developer on them.  I don't even run a keyserver.
And if you knew the first thing about the keyservers you would know this
without needing me to tell you.

So please forgive me for not wanting to have a conversation with you.  I
am getting very tired of people confusing "Rob understands the current
mess" with "so I'm going to impugn his competence".

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Ryan McGinnis via Gnupg-users]

I guess that’s one way to look at it, but if your end users are dissidents and 
journalists communicating in happy fun places or developers signing critical 
software, then surely you’d want the product to be resilient against 10 year 
old trivial attacks from your users’ adversaries.  I do understand the “with 
what resources” argument; I imagine there is no way of getting around that.  
But if that is the end response to stuff like this then it seems more an 
argument that people should not be using this software system for important, 
serious applications.  For the secure communications functionality I suspect 
this has been the target end users’ perception for quite some time, and a whole 
slew of arguably better secure communications systems have risen to fill that 
need - but GPG is still used heavily in signing important files.

-Ryan McGinnis
http://bigstormpicture.com
PGP: 486ED7AD
Sent with ProtonMail Secure Email

On Sun, Jun 30, 2019 at 07:44, Robert J. Hansen  wrote:

>> What would have prevented a state level actor from activating this
>> exploit on a wide level during a time when it would have been most
>> effective for them?
>
> A nation-state with a professional intelligence service probably isn't
> very interested in taking down the keyserver network. Why should they
> take down something that's not a big priority for them, especially if
> it'll cost them a lot of international goodwill if it gets attributed to
> them?
>
> This has all the hallmarks of a child playing with matches and clapping
> with glee as the house catches fire.
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Robert J. Hansen]

> What would have prevented a state level actor from activating this
> exploit on a wide level during a time when it would have been most
> effective for them?

A nation-state with a professional intelligence service probably isn't
very interested in taking down the keyserver network.  Why should they
take down something that's not a big priority for them, especially if
it'll cost them a lot of international goodwill if it gets attributed to
them?

This has all the hallmarks of a child playing with matches and clapping
with glee as the house catches fire.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Ryan McGinnis via Gnupg-users]

What would have prevented a state level actor from activating this exploit on a 
wide level during a time when it would have been most effective for them?  I 
have to believe that the fine folks who can put an APT in your air-gapped 
computer’s video card bios have been aware of this attack for quite some time 
and probably have an entire laundry list of other similarly devastating attacks.

-Ryan McGinnis
http://bigstormpicture.com
PGP: 486ED7AD
Sent with ProtonMail Secure Email

On Sun, Jun 30, 2019 at 03:19, Robert J. Hansen  wrote:

>> How bad could this get?
>
> (I am sputteringly angry over this entire thing: please understand this
> and give a charitable read to what I write. I appreciate it.)
>
> Hard to say.
>
> One of the big problems we have is the size of the existing codebase.
> Once people have GnuPG installed people overwhelmingly like to leave it
> alone. We still get people coming onto this list asking for support
> with GnuPG *1.2*. So for these installations, these "we're going to
> install it and forget it"s?
>
> They're screwed. Sooner or later they'll import a poisoned certificate,
> GnuPG will get wedged, and it will appear as if GnuPG just stopped
> working. It might happen tomorrow or it might happen in five years. We
> don't know, but it will happen.
>
> There are other groups that run human networks in dangerous places.
> (There are many of them: Medicins Sans Frontiers, Reuters, and more.)
> The people who are running around Syria treating casualties or doing
> political news reporting from Gaza are overwhelmingly not computer
> nerds. They know they're supposed to run "gpg --refresh-keys" from time
> to time to get the latest revocations. They do it this time, and GnuPG
> breaks horribly. Odds are good they'll say "sod this, I can't trust
> this crap" and throw it away.
>
> There are a ton of tiny little poorly-maintained systems in
> out-of-the-way places that get completely overlooked until things break.
> Those, too, have good odds of getting wedged the first time they
> encounter a poisoned certificate.
>
> The next version of Enigmail will no longer use the SKS network by
> default. Great! But what about existing Enigmail users? They'll see a
> signature, click "Import Key", and ... bam. They're likely not going to
> think that someone's performing a malicious attack by poisoning
> certificates: they're going to think "this is crap" and walk away.
>
> Right now only three certificates are known to be affected: mine, dkg's,
> and Kristian's. I expect that number to rise, either due to the
> original jerk figuring this is fun, or due to copycats getting in on the
> action.
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[U'll Be King of the Stars]

On 30/06/2019 09:19, Robert J. Hansen wrote:
> Right now only three certificates are known to be affected: mine, dkg's,
> and Kristian's.

I must have missed the memo describing the exact nature of the problem.
 Could you please provide a link to something (email message, web page)
that explains what is going on?  Thanks!

Kind regards,

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Mirimir via Gnupg-users]

On 06/30/2019 03:10 AM, Robert J. Hansen wrote:
>> Because a) it’s enumerating badness [1] but more importantly b) it’s
>> punishing the victim. Protecting the ecosystem by banning RJH and DKG’s
>> keys from the keyservers entirely is doing the bad guys’ work for them.

Currently, we know that three keys are bad. How soon do you think that
bad keys will outnumber good ones? Weeks? Months? Years?

> There's an important c):
> 
> c) what happens when they go after more certificates?
> 
> If you're willing to blackhole two certs, great.  Where does it stop?
> How many certs can the strong set stand to lose?

Your third point is actually why I suggested this. Maybe I'm just
twisted, but what if some dickhead goes after certs that would break
stuff for millions of people? One might, for example, block Linux kernel
maintenance and development. Maybe just before using some 0-day.

It would stop when certs can no longer be poisoned. And I don't see the
downside. I mean, what good does it do to have people downloading keys
that break their stuff?

I don't see that as "doing the bad guys’ work for them". I see it as
preventing bad guys escalating from hurting a few people to doing
serious damage. That's not "punishing the victim".

Also, I presume that key owners could temporarily disable signature
checking, delete malicious signatures, and put their keys on secure
keyservers. But until secure keyservers exist at requisite scale,
blackholing seems like the simplest option. If it's doable, anyway.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Robert J. Hansen]

> Because a) it’s enumerating badness [1] but more importantly b) it’s
> punishing the victim. Protecting the ecosystem by banning RJH and DKG’s
> keys from the keyservers entirely is doing the bad guys’ work for them.

There's an important c):

c) what happens when they go after more certificates?

If you're willing to blackhole two certs, great.  Where does it stop?
How many certs can the strong set stand to lose?

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Andrew Gallagher]

> On 30 Jun 2019, at 11:01, Vincent Breitmoser  wrote:
> 
> The single biggest issue is
> importing keys that don't have identity info on them. I submitted a patch to
> GnuPG to fix this issue, but for some reason that is beyond me there seems to 
> be
> resistance to merging it:

Unfortunately even if that patch were merged it doesn’t solve the issue, which 
is compatibility with the existing client base. 

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Andrew Gallagher]

> On 30 Jun 2019, at 10:21, Mirimir via Gnupg-users  
> wrote:
> 
> This is undoubtedly a naive question. But anyway, would it be feasible
> to test keys by importing them, and seeing which ones break OpenPGP?
> Maybe do it in minimal Docker containers? And then somehow block access
> to those keys?

Because a) it’s enumerating badness [1] but more importantly b) it’s punishing 
the victim. Protecting the ecosystem by banning RJH and DKG’s keys from the 
keyservers entirely is doing the bad guys’ work for them.

A

[1] https://www.ranum.com/security/computer_security/editorials/dumb/___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Vincent Breitmoser via Gnupg-users]

> 3. interoperability. The replacement service would need to be fully compatible
> with all existing clients.

Depending on what you mean by "fully compatible". The single biggest issue is
importing keys that don't have identity info on them. I submitted a patch to
GnuPG to fix this issue, but for some reason that is beyond me there seems to be
resistance to merging it: https://dev.gnupg.org/T4393

 - V


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Stefan Claas via Gnupg-users]

Robert J. Hansen wrote:

> > Can someone please explain to me why the GnuPG flag for key servers
> > --no-modify is in GnuPG and why the authors of key server software
> > did not implemented this feature?
> 
> It's pretty unreasonable to think a piece of software from 2003, meant
> as a drop-in replacement for software written in 1993, would implement a
> feature that first appeared in GnuPG around 2013.[1]

> [1] That "around 2013" is a guess: I don't know off the top of my head
> when that was first added to GnuPG.

Thanks for the info.

Regards
Stefan


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Robert J. Hansen]

> Can someone please explain to me why the GnuPG flag for key servers
> --no-modify is in GnuPG and why the authors of key server software
> did not implemented this feature?

It's pretty unreasonable to think a piece of software from 2003, meant
as a drop-in replacement for software written in 1993, would implement a
feature that first appeared in GnuPG around 2013.[1]

If your next question is, "well, why doesn't SKS get modernized?", the
answer is "with what personnel and what budget?"  SKS doesn't even have
a maintainer, for God's sake.



[1] That "around 2013" is a guess: I don't know off the top of my head
when that was first added to GnuPG.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Stefan Claas via Gnupg-users]

Andrew Gallagher wrote:

> 
> > On 30 Jun 2019, at 09:19, Robert J. Hansen  wrote:
> > 
> > The next version of Enigmail will no longer use the SKS network by
> > default.  Great!  But what about existing Enigmail users?  They'll see a
> > signature, click "Import Key", and ... bam.  They're likely not going to
> > think that someone's performing a malicious attack by poisoning
> > certificates: they're going to think "this is crap" and walk away.
> 
> Thankfully there is a practical - if drastic - solution for all OpenPGP users
> everywhere. Point pool.sks-keyservers.net (and its various aliases) somewhere
> else. The question is where to and how soon.

Can someone please explain to me why the GnuPG flag for key servers --no-modify
is in GnuPG and why the authors of key server software did not implemented this
feature?

Regards
Stefan


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Mirimir via Gnupg-users]

On 06/30/2019 01:34 AM, Andrew Gallagher wrote:
> 
>> On 30 Jun 2019, at 09:19, Robert J. Hansen  wrote:
>>
>> The next version of Enigmail will no longer use the SKS network by
>> default.  Great!  But what about existing Enigmail users?  They'll see a
>> signature, click "Import Key", and ... bam.  They're likely not going to
>> think that someone's performing a malicious attack by poisoning
>> certificates: they're going to think "this is crap" and walk away.
> 
> Thankfully there is a practical - if drastic - solution for all OpenPGP users 
> everywhere. Point pool.sks-keyservers.net (and its various aliases) somewhere 
> else. The question is where to and how soon.
> 
> A

This is undoubtedly a naive question. But anyway, would it be feasible
to test keys by importing them, and seeing which ones break OpenPGP?
Maybe do it in minimal Docker containers? And then somehow block access
to those keys?

Or is blocking just as impossible as deleting?

I know that wouldn't help people whose keys had been poisoned. But at
least it would help protect complex systems that rely on OpenPGP.

And if resource requirements would be impossible, what about focusing on
the most important keys? For key packages, say.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Robert J. Hansen]

> Thankfully there is a practical - if drastic - solution for all
> OpenPGP users everywhere. Point pool.sks-keyservers.net (and its
> various aliases) somewhere else. The question is where to and how
> soon.

(I am certain Andrew has already considered this: I am making explicit
what I think Andrew considered to be implicit.)

The obvious choice there is hkps://keys.openpgp.org.  The problem there
is keys.openpgp.org is not a drop-in replacement for SKS, and there's a
tremendous chance of breaking workflows in unpredictable places.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Andrew Gallagher]

>> Thankfully there is a practical - if drastic - solution for all
>> OpenPGP users everywhere. Point pool.sks-keyservers.net (and its
>> various aliases) somewhere else. The question is where to and how
>> soon.
> 
> (I am certain Andrew has already considered this: I am making explicit
> what I think Andrew considered to be implicit.)
> 
> The obvious choice there is hkps://keys.openpgp.org.  The problem there
> is keys.openpgp.org is not a drop-in replacement for SKS, and there's a
> tremendous chance of breaking workflows in unpredictable places.
> 

Yes, this is the “how soon”. We are *nowhere near* prepared enough to take that 
step now. But a solution exists (at least in principle) that does not require 
end users to take any action. The big obstacles are:

1. scalability. A non-distributed key service could potentially collapse if 
global hkp(s) traffic was redirected to it. 
2. reliability. There would need to be enough failover capacity in the new 
system to withstand individual server failure. 
3. interoperability. The replacement service would need to be fully compatible 
with all existing clients. DKG’s internet draft shows how hard this will be to 
ensure in practice without simply replicating the problems of the existing 
network. 

We’ve known this day was coming for some time. We’ve just got a fire lit under 
our collective backsides. 

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Andrew Gallagher]

> On 30 Jun 2019, at 09:19, Robert J. Hansen  wrote:
> 
> The next version of Enigmail will no longer use the SKS network by
> default.  Great!  But what about existing Enigmail users?  They'll see a
> signature, click "Import Key", and ... bam.  They're likely not going to
> think that someone's performing a malicious attack by poisoning
> certificates: they're going to think "this is crap" and walk away.

Thankfully there is a practical - if drastic - solution for all OpenPGP users 
everywhere. Point pool.sks-keyservers.net (and its various aliases) somewhere 
else. The question is where to and how soon.

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Robert J. Hansen]

> How bad could this get?

(I am sputteringly angry over this entire thing: please understand this
and give a charitable read to what I write.  I appreciate it.)

Hard to say.

One of the big problems we have is the size of the existing codebase.
Once people have GnuPG installed people overwhelmingly like to leave it
alone.  We still get people coming onto this list asking for support
with GnuPG *1.2*.  So for these installations, these "we're going to
install it and forget it"s?

They're screwed.  Sooner or later they'll import a poisoned certificate,
GnuPG will get wedged, and it will appear as if GnuPG just stopped
working.  It might happen tomorrow or it might happen in five years.  We
don't know, but it will happen.

There are other groups that run human networks in dangerous places.
(There are many of them: Medicins Sans Frontiers, Reuters, and more.)
The people who are running around Syria treating casualties or doing
political news reporting from Gaza are overwhelmingly not computer
nerds.  They know they're supposed to run "gpg --refresh-keys" from time
to time to get the latest revocations.  They do it this time, and GnuPG
breaks horribly.  Odds are good they'll say "sod this, I can't trust
this crap" and throw it away.

There are a ton of tiny little poorly-maintained systems in
out-of-the-way places that get completely overlooked until things break.
 Those, too, have good odds of getting wedged the first time they
encounter a poisoned certificate.

The next version of Enigmail will no longer use the SKS network by
default.  Great!  But what about existing Enigmail users?  They'll see a
signature, click "Import Key", and ... bam.  They're likely not going to
think that someone's performing a malicious attack by poisoning
certificates: they're going to think "this is crap" and walk away.

Right now only three certificates are known to be affected: mine, dkg's,
and Kristian's.  I expect that number to rise, either due to the
original jerk figuring this is fun, or due to copycats getting in on the
action.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Mirimir via Gnupg-users]

On 06/29/2019 11:26 PM, Robert J. Hansen wrote:
>> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
> 
> I stand by what I wrote.
> 
> As usual, don't read the comments unless you want to despair for humanity.

It sounds like SKS is dead meat. And hagrid is coming. And you advise:

| High-risk users should stop using the keyserver network immediately.

So OK, I can purge requests to SKS keyservers from my machines. But what
about upstream impacts? As I understand it, GnuPG authentication is
pervasive. And I suspect that getting missing keys from SKS is common.
As an error trap, if nothing else.

How bad could this get?

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Robert J. Hansen]

> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

I stand by what I wrote.

As usual, don't read the comments unless you want to despair for humanity.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Ryan McGinnis via Gnupg-users]

Interesting discussion thread on this over at HN:

https://news.ycombinator.com/item?id=20312826

-Ryan McGinnis
http://bigstormpicture.com
PGP: 486ED7AD
Sent with ProtonMail Secure Email

On Sat, Jun 29, 2019 at 12:51, Ryan McGinnis  wrote:

> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
>
> -Ryan McGinnis
> http://bigstormpicture.com
> PGP: 486ED7AD
> Sent with ProtonMail Secure Email___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Stefan Claas via Gnupg-users]

Ryan McGinnis via Gnupg-users wrote:

> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
> 
> -Ryan McGinnis
> http://bigstormpicture.com
> PGP: 486ED7AD
> Sent with ProtonMail Secure Email

No problen, we now have super modern GDPR compliant hagrid, WKD, keybase
and good old pgp.com key server. :-)

New version of Enigmail will default to hagrid. :-)

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

SKS Keyserver Network Under Attack

[Ryan McGinnis via Gnupg-users]

https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

-Ryan McGinnis
http://bigstormpicture.com
PGP: 486ED7AD
Sent with ProtonMail Secure Email___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users