Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks

From: Christoph Anton Mitterer <[email-masked]>
Date: Sun, 01 Feb 2009 16:03:57 +0100

On Sat, 2009-01-31 at 16:30 -0800, Wim Lewis wrote:
> One of the  
> strengths of the PGP setup, I think, is that you don't have to trust  
> the keyserver;
Well I think you already do this or better said, the whole PKI does it.
It's just not yet secured.

> An end-to-end approach is better, IMHO. (It also protects against the  
> opposite side of the equation: is Mallory secretly stripping the  
> revocation certificate out of your friend's uploads to the keyserver?  
> Also, I don't want to have to make trust/policy decisions based on  
> how much I trust the people running the keyserver, how strong my  
> trust path is to their key, and so on. That way lies X.509...)  
Yeah but again,.. I think you're already doing this, otherwise you'd
have to retrieve all you key updates manually from the key owners (e.g.
every day or so). Even worse, you'd also have to retrieve updates by the
signers to the keys of your keyrings, and their signers and so on..

> Notionally, I want some sort of periodic, signed communication from  
> other keyholders, saying, "The official state of my key-and- 
> subpackets is X. Expect another message before date Y".
But this is very difficult, as it's probably not enough to only get the
official state of the key of your direct contacts (see above)

> However, not  
> all of the subpackets are really important: if I'm missing a  
> signature from someone else,
But what if this signature is part of the trust path?

>  or an alternate user ID, I'm not going  
> to trust you any *more* than if I have it. So this thing only needs  
> to cover packets which reduce trust --- revocations, I guess. (Am I  
> missing a scenario here?)
I think you miss the case of keys, that you didn't sign yourself, but
have some indirect trust path to it.

> But is this actually any different from periodically renewing a set  
> of expiring signatures? (I don't think so, but I could easily be  
> missing stuff.) In which case, OpenPGP already supplies everything  
> needed to prevent this sort of denial-of-key-distribution attack.
How?

> Of course I think securing the keyserver communication is *also*  
> good, as long as the trust model doesn't depend on it. :)
I think it actually DOES depend on it. Even if you'd completely forget
keyservers and imagine that you directly exchange the keys with your
direct contacts (I mean that official most recent state of the key), you
could "loose" their revocation certs when an attacker strips them of.
So even in that case, your direct contact would have to sign the whole
key as if it would be casual data.

Or am I wrong?

Best wishes,
-- 
Christoph Anton Mitterer
Ludwig-Maximilians-Universität München

[email-masked]
[email-masked]

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 01 Feb 2009 16:25:28 -0500

Hi Christoph--

I think the issue you're raising about secured access to keyservers is
important.

In addition to an active attacker modifying the communication, queries
to keyservers are also potentially information leaks -- anyone simply
observing the query knows something about who your contacts are.

On 01/31/2009 05:54 PM, Christoph Anton Mitterer wrote:
> Imagine that my ISP is evil, tracks my connections and always removes
> some revocation signatures when I get the data.
>
> Are there currently working means to prevent this?

Yes there are!  Back in November i set up nginx on
zimmermann.mayfirst.org (a member of the sks-keyservers pool) to provide
an HTTPS link to the keyserver.  Access to that keyserver can then be
done by running hkp over TLS.  While the OpenPGP tool i was using (gpg)
didn't seem to be able to handle such a TLS-wrapped link natively, i was
able to approximate it with a client-side proxy using socat:

  https://lists.riseup.net/www/arc/monkeysphere/2008-11/msg00046.html

Because TLS offers mutual authentication, message integrity, and
privacy, this can potentially defend against every kind of active attack
except for a full DoS (which an active attacker who can modify your
network traffic can execute no matter what anyway) (and could also be
used to limit queries to your keyserver to particular users, if you so
desired).

But wait, you say, I don't want to have to use X.509 certificates along
with TLS!  Well, i don't either.  RFC 5081 provides for TLS to use
OpenPGP certificates for either party in the communication.  This
removes the need for X.509, while retaining all the benefits of TLS.

So: Is this scheme fully implemented and easy-to-use yet?  No.  But the
pieces are there, and it's already been assembled piecemeal with
currently-available tools.  If you are interested, or manage to push it
further, i'd be very happy to hear about your progress.

hth,

	--dkg

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 02 Feb 2009 00:07:07 +0100

Hi Daniel.

> observing the query knows something about who your contacts are.
Excellent point.

>   https://lists.riseup.net/www/arc/monkeysphere/2008-11/msg00046.html
This sounds nice =)

> used to limit queries to your keyserver to particular users, if you so
Of course,...

> removes the need for X.509, while retaining all the benefits of TLS.
Even better :-) Which RFC5018 have you used?

> further, i'd be very happy to hear about your progress.
Well my time's limited ^^...
I had hoped to get somehow in contact with the keyserver software
developers,..

The keyservers should also communicate secured with each other,.. in you
setup there's still the (of course very small) chance that the secure
keyserver (e.g. your's) is already attacked and doesn't get the full
data during its synchronisation with the others,... and I suppose most
people use one of the "big/wellknown" keyservers when submitting their
keys.

And as you've said, one important point would be client support...
The average user probably don't want to set up socat or any similar
proxy.

Best wishes,

---

From: John Clizbe <[email-masked]>
Date: Sun, 01 Feb 2009 19:37:21 -0600

Christoph Anton Mitterer wrote:
>> So: Is this scheme fully implemented and easy-to-use yet?  No.  But
>> the pieces are there, and it's already been assembled piecemeal with
>> currently-available tools.  If you are interested, or manage to push
>> it further, i'd be very happy to hear about your progress.

> I had hoped to get somehow in contact with the keyserver software

sks-devel[AT]nongnu.org

Yaron Minsky did the development work, but doesn't have time for new development
only maintenance.

The other keyserver list, pgp-keyserver-folk[AT]alt.org, seems to have gone missing.

> data during its synchronisation with the others,... 

Under SKS, it will get that data from another keyserver. To forge a key would
require co-opting and taking simultaneous control of all the SKS keyservers.

To fool a keyserver would require being able to fake hashes of the database
contents on-the-fly.

> and I suppose most people use one of the "big/wellknown" keyservers when
> submitting their keys.

Yeah, even when the code the keyserver runs is broken/orphaned.

> The average user probably don't want to set up socat or any similar

No, it would have to be done in the client.

- --
John P. Clizbe                      Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net  or
     mailto:[email-masked]?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 02 Feb 2009 03:44:13 +0100

Hi John.

> Yaron Minsky did the development work, but doesn't have time for new development
Thanks for that info :-)

Hmm,.. what are our main keyserver implementations? sks and pks are the only ones I know about...

> require co-opting and taking simultaneous control of all the SKS keyservers.
Of course,.. I've already that,.. that this part is more a theoretical
point ;-)

> No, it would have to be done in the client.
That's what I meant ;)

Best wishes,

---

From: John Clizbe <[email-masked]>
Date: Sun, 01 Feb 2009 21:19:23 -0600

> Hmm,.. what are our main keyserver implementations? sks and pks are the only

PKS, SKS, LDAP, ONAK, OpenPKSD, CKS are the keyserver implementations I know of.

PKS used to be dominant, but I believe SKS now is. Many of the old PKS servers
have moved to SKS or gone offline.

- --

---

From: David Shaw <[email-masked]>
Date: Sun, 1 Feb 2009 22:33:44 -0500

> the only ones I know about...

PKS is dead at this point.  It more or less works, but cannot handle  
keys with more than one subkey, or are uncommon in some ways.

SKS replaces PKS.  It speaks the same access protocol as PKS (called  
"HKP" - it's basically a subset of HTTP, so you can use any handy HTTP  
software to access a keyserver), so any software written to talk to  
PKS can talk to SKS without changes.

The other protocols that are commonly used are HTTP (just fetching a  
regular file on a regular web server), and LDAP.  LDAP is particularly  
well suited for keyservers, as what is a keyserver if not a  
directory?  The PGP folks developed a LDAP schema that both PGP and  
GPG use when talking to a LDAP server.

There are other ways to store keys.  There is even an RFC (4398) for  
storing OpenPGP keys in DNS.

David

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 02 Feb 2009 13:51:22 +0100

> PKS, SKS, LDAP, ONAK, OpenPKSD, CKS are the keyserver implementations I know of.
Ok I kenw about LDAP and OpenPKSD,... but I thought the later was
dead,... last entry on their website seems to be from 2005.

Regards,

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 02 Feb 2009 13:56:52 +0100

> storing OpenPGP keys in DNS.
Hey this is really nice,... I wasn't aware of it =)

Thanks,

---

From: David Shaw <[email-masked]>
Date: Mon, 2 Feb 2009 09:36:11 -0500

> Hey this is really nice,... I wasn't aware of it =)

It's pretty interesting.  GPG supports it (both in the "PGP" variant  
where the whole key is stored in a very large DNS blob, and in the  
more useful "IPGP" variant where the DNS returns a URL pointing to the  
regular key) but I don't think it gets particularly wide use.  Not all  
that many people control their own DNS, so that's an additional  
barrier on top of all of the usual barriers.

One thing that DNS is very good for is fast, lightweight, queries.   
You could see how building something like a revocation server would be  
ideal over DNS: revocations are small, and the queries over DNS are  
fast and cheap.

David

---

From: Jon Callas <[email-masked]>
Date: Mon, 2 Feb 2009 11:11:38 -0800

On Jan 31, 2009, at 2:54 PM, Christoph Anton Mitterer wrote:

> * PGP Signed by an unverified key: 01/31/2009 at 02:54:48 PM
>
> Hi.
>
> I having the following issue on my OpenPGP "TODO" list for some very
> long time now, and David just remembered me on it.

I do not understand either the problem you're trying to solve or the  
solution.

Let's start with a problem description.

I believe that the problem you're describing is that your connection  
to a keyserver is passing through some evil router that rewrites your  
connection. Am I right?

Why isn't the solution to this "use SSL/TLS"?

	Jon

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Tue, 03 Feb 2009 01:53:46 +0100

> to a keyserver is passing through some evil router that rewrites your  
Correct.

> Why isn't the solution to this "use SSL/TLS"?
Well it is =) ...

I'd just prefer something using OpenPGP for securing the data. It would
be somehow embarrassing to depend on X.509 based SSL/TLS in order to get
OpenPGP keys, wouldn't it ;-)
Of course RFC 5081 is a possible solution.

And I'm not sure if the keyservers (sks) and the OpenPGP clients would
already support SSL/TLS.

Happy wishes,