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: Your Thoughts

[Robert J. Hansen]

> This list will be long. 

Yes.  And frankly, it's a bigger subject than just GnuPG: to be
effective we'd need to get buy-in from OpenPGP.js and Sequoia, for starters.

Optimistically, we'd be looking at two years of work, maybe more.

One of the things I'm beginning to consider, though, is that it might be
a good idea to make the Implementation-Future group invitation-only.
Over the last few years I have *really* lost faith in the idea of open
and unmoderated groups.  The gist I posted where I outlined the
poisoned-certificates attack took all of three messages before someone
started accusing me of being a bigot on account of my belief that child
pornography is a moral evil...

https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f#gistcomment-2957390

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

Re: Your Thoughts

[Andrew Gallagher]

> On 1 Jul 2019, at 00:36, Robert J. Hansen  wrote:
> 
> Would this be painful?  Sure.  But it doesn't involve throwing out
> the OpenPGP spec, just overhauling how we implement it and the
> supporting software ecosystem.  That would be *hard*, don't get me
> wrong, and I am *in no way* saying this would be easy.

Is it worth drawing up a work program for the ecosystem, some sort of priority 
list of what needs fixed, how urgent each is, and what dependencies there are 
between different components? For example, say we want to make it possible to 
work without any IDs. How many things need changed? How urgent is it compared 
to, say, getting Hagrid up to spec as an sks replacement? Where should we 
concentrate our efforts?

This list will be long. 

A

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

Re: Your Thoughts

[Robert J. Hansen]

> I think the article is five years old, has not aged well (e.g. MUA
> integration has improved), and that nothing better than PGP has come
> along in the meantime.
I think Matthew Green is a very sharp fellow and his criticisms are
thoroughly on-point.  My biggest complaint about that article is that he
doesn't draw a clean distinction among the OpenPGP specification, how
software packages like GnuPG choose to implement the specification, and
the supporting ecosystem that is neither OpenPGP nor implementation.

The OpenPGP spec says surprisingly little about what the format of a key
should be, for instance.  If you look at GnuPG's key export format, it
was chosen in the late '90s to be interoperable with PGP Security's PGP
5.0 offering (which was, at the time, pretty much cutting-edge).

Well -- nowadays GnuPG is the big mover in that space.  There's a strong
argument to be made that GnuPG should be more of an innovator.  There's
no reason anymore to retain the old and inefficient PGP 5 format.  We
can change it and still be compliant with the spec: maybe we should.  I
think we should.

And hey, if we fix the key exchange format, that's one massive section
of his objections gone.  That set of objections isn't to OpenPGP, it's
purely about how we implement it.

Another major complaint of his is the keyserver network, which we've
known for years was inadequate.  It was also the only game in town and
there was neither the money nor the manpower to do a better job.  Now
we've got Autocrypt, WKD, and Hagrid: of these Autocrypt is probably the
most mature and the easiest for email users.  We've got three at least
arguably better ways of distributing certificates: if we can actually
persuade people to start using them, we can fix this and wipe another
set of complaints off his list.  His set of objections here is not to
either OpenPGP or an implementation of it, but rather the support ecosystem.

(Note to anyone who thinks I'm saying "it's kinda good that this Great
Unpleasantness is happening because it's making people migrate": no.
Absolutely not.  The people behind this deserve to be shunned by our
community and exiled from our mailing lists.  They are not our friends.)

About the only actual protocol-level complaints Professor Green has are:

1.  OpenPGP has no forward secrecy.  (Correct!  I'd love to see the
OpenPGP Working Group tackle this.  I'm not sure it can be done for
offline asynchronous communications, but it would be good to at least
investigate the possibilities.)

2.  OpenPGP has no AE/AEAD mode.  (Incorrect!  The MDC is a form of
authenticated encryption.  It predates modern AE/AEAD and looks kind of
baroque to modern eyes, but it's AE.  The fact some mail clients
*ignore* the AE is a different [and very serious!] matter.  Further, the
latest RFC4880bis spec -- which was written after Professor Green's
blogpost -- explicitly incorporates modern AE/AEAD.)

My complaint about Professor Green's blogpost is that he treats PGP as a
single monolithic block, instead of as different plants in a garden that
all grow interdependently.  The OpenPGP protocol is solid.  But we can,
and I think we need to, do a serious modernization pass on how we choose
to *implement* that protocol.

If I were to set priorities for GnuPG?

1.  Set a flag day.  Past a certain date, old-and-busted certificates
and data formats will simply not be supported.  They won't be written,
they won't be read, they won't be processed, GnuPG will simply say
"nope, that might be legit old-school RFC4880 traffic but I'm not going
to play that game."

2.  Overhaul the key format.

3.  Do away with user IDs.  Only use key IDs.  If a user wants to
associate a key with an email address, let them: but user IDs originally
existed *mostly* to support the email use case, and with the advent of
Autocrypt that's not such an issue any more.  (Note that a lot of thorny
problems suddenly just *go away* if you stop using userIDs.)

4.  Require a limited subset of the RFC4880bis standard to be used.
Keep support for adding ciphers to the spec -- algorithm agility is a
wonderful thing -- but by default only use one specific ECC algorithm in
one specific key length, with AES256 as a symmetric cipher, and SHA512
for a hash.  GnuPG's ability to support arbitrary preferences and
algorithms is neat technically but I have literally *never* seen it be
necessary in field usage, and I have seen people accidentally degrade
their security literally *hundreds* of times.  (If your cipher
preferences are 3DES AES128 AES256, for instance?  Say hello to 3DES:
you will literally never use AES256.)

5.  If we're going to continue to have a keyserver network the only way
forward is to burn it down and build something newer and better.  There
are no other realistic options.

6.  Develop a well-defined output format.  Werner & co. like to say the
output of --with-colons is well-defined.  It's not.  Unless there's
something like a DTD or a BNF specification and the output can 

Re: Your Thoughts

[Robert J. Hansen]

> Does anyone know what PGP’s peak adoption rate was?

We're living in it.  OpenPGP is used on a scale the protocol designers
never dreamed, mostly for verifying operating system packages.

Peak _email_ adoption rate?  It's never been any kind of serious player
in that space.  I've seen it used productively in nonpermissive
environments where other tools simply could not suffice.  I do not
recommend it as a casual tool: but when nothing else will do, well...
nothing else will do.


___
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: Your Thoughts

[Ryan McGinnis via Gnupg-users]

It’s not so much that nothing better has come along, it’s that no single one of 
those things does all the things PGP sets out to do.  For secure communications 
there are much better options than PGP - some of them in very heavy use by 
actual normal, non tech people.  For symmetric encryption of files there much 
better options out there.  For signing files there are other options (though 
perhaps not better).  


Does anyone know what PGP’s peak adoption rate was?  I always loved it in 
concept but very very rarely saw people actually trying to use it in the wild, 
outside of the types of people who read this list.  


-Ryan McGinnis
https://bigstormpicture.com
PGP: 486ED7AD
Sent with ProtonMail

‐‐‐ Original Message ‐‐‐
On Sunday, June 30, 2019 3:01 PM, Ralph Seichter  wrote:

> * da...@gbenet.com:
> 

> > Your Thoughts :)
> 

> I think the article is five years old, has not aged well (e.g. MUA
> integration has improved), and that nothing better than PGP has come
> along in the meantime.
> 

> Next. ;-)
> 

> -Ralph
> 

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


publickey - ryan@digicana.com - 0x5C738727.asc
Description: application/pgp-keys


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

Re: Your Thoughts

[Ralph Seichter]

* da...@gbenet.com:

> Your Thoughts :)

I think the article is five years old, has not aged well (e.g. MUA
integration has improved), and that nothing better than PGP has come
along in the meantime.

Next. ;-)

-Ralph

___
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

Your Thoughts

[David]

Your Thoughts :)

https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/

-- 
People Should Not Be Afraid Of Their Government - Their Government
Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION
Becomes A DUTY! Join the Rebellion Today! https://gbenet.com

___
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: New keyserver at keys.openpgp.org - what's your take?

[Daniel Kahn Gillmor via Gnupg-users]

On Sun 2019-06-30 00:33:22 +0100, Andrew Gallagher wrote:
> Indeed, c) was exactly the killer use case I had in mind.

so, how do we get there?

> On the other hand, b) is also quite useful in the short to medium
> term, until all mail providers decide to support WKD etc.

WKD is mighty nice, but it is not necessary.  For example, if you don't
care about first-contact, Autocrypt is a totally reasonable key
discovery mechanism.  It also has a significantly reduced metadata
footprint compared to WKD or DANE OPENPGPKEY, since all messaging is
in-band.

It has other problems, of course, but it can be used directly today (not
just "short to medium term").

> And considering that some companies still don’t fully support PGP/MIME
> after nearly twenty years of being the preferred standard (I’m looking
> at you, Apple), “short to medium” effectively means “indefinitely”.

If you know something specific about Apple failing PGP/MIME in some
capacity i hope you'll be more explicit about it, because i don't know
what you're talking about.

> So maybe we shouldn’t think of keyservers as storage repositories, but
> rather as search engines. The keyservers should not be authoritative,
> but they should be a best effort directory of where the authoritative
> locations are, combined with a cache of the non-identity cryptographic
> material in case the authoritative locations get DOSed.

Of course they're both search engines and storage rpositories, and they
are not and have never been authoritative.  Anyone who claimed
keyservers were authoritative in the past was either confused or
misleading you.

> If the authoritative location is not on a keyserver, then we do not
> need to sync arbitrary data between keyservers, just a list of
> location hints. The keyservers would then fetch from the authoritative
> locations and decide for themselves how much of the content to cache.

i'd be curious to read any specific guidance about how you think a
sensible keyserver would make those decisions.  If you want to propose
changes to
https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore
i'd be happy to incorporate them too.

--dkg


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

[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