[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] is staying...again

From: Todd Fleisher
Subject: Re: [Sks-devel] is staying...again
Date: Wed, 21 Nov 2018 15:42:53 -0800

On Nov 21, 2018, at 12:59 PM, Yegor Timoshenko <address@hidden> wrote:

Do you happen to have a long-term patch also, or just the
hardcoded poison key?

I don't, and most importantly, I don't think a long-term patch is
even possible without completely overhauling SKS.

This may be true, but regardless I think we can all agree that a complete overhaul is not something that will just happen overnight. Furthermore, the SKS network of key servers is currently the best (and maybe only) game in town for mass public distribution of GPG keys so I think I speak for many people when I say let’s try to avoid introducing any more issues that could (and in my opinion should) be handled in isolated and controlled test environments vs. the actual network.

The first and more prominent one is, lack
of validation, closed as WONTFIX. That is also a critical UI flaw
that makes it easy to trick users who use HTTP interface.

I agree this issue (authenticity of data found on the key servers) is one many would like to see solved, but also agree it’s not what the SKS key server pool was designed for. Maybe SKS can be adapted to solve this problem or maybe it will require a new technology. Personally, I’ve solved for this issue on the client side by automating keyring management to some extent by checking for specific authority signatures (per domain) on keys found on the SKS network and then only import those that I deem “authentic". I know Micah (who reported that issue) has done something similar with GPGSync:

It is very easy to test for vulnerabilities if you actually
install sks on your own machine first, and try to also fix it
before publishing/exploiting it. Many have tutorials on this
subject and all you need is a copy of a key dump.

Not really. This particular key poison vulnerability can only be
seen if you have a testing network of at least three keyservers.

Those two sentences appear to be in opposition of each other. It would have just required more effort on the part of the tester to setup at least 3 key servers to test with. 

I didn't know the extent of damage my attacks will have: I was
just poking SKS for basic attack vectors that, at that time, I
was sure would have no effect at the network at large. I haven't
looked at SKS source code while testing any of the attacks

That first sentence really irks me. I personally would appreciate future testers taking heed of a proper testing approach vs. unleashing code/data containing unknown and/or unpredictable results onto the public SKS network that many people rely on every day.

I didn't even know these attacks had any pronounced long-term
effect on the network before ~3 weeks ago when I took a look at
sks-devel@ mailing list and found a huge discussion on the topic.
(I was never approached about this until recently.)

Not to beat a dead horse, but therein lies the problem. If you didn’t know what the impact would be, I feel you should not have injected test data into the SKS network without first doing due diligence in an isolated test environment.

Historically speaking, it would seem as if benevolently attacking
the network was the most effective way to have it evolve. Say,
consider Evil 32, which was an effort that included bruteforcing
a 32-bit fingerprint lookalike to every key in trusted set
( and uploading it to keyservers. By then, the
danger of 32-bit key fingerprints was known for a long time, but
no one did anything about it.

And while that could cause problems for folks using the trusted set of GPG keys and 32-bit fingerprints … I don’t think it caused instability in the SKS network by way of increasing usage of server & network resources - neither of which are “free" for everyone - nor did it compromise nodes on the network when they crashed as a result of the bogus keys being uploaded.

There are other ways of bringing an sks server down, and BDB
might not be the best idea for a server, still the network is
important for both free software and individuals using it.

There are likely other low-effort ways of bringing an SKS server
down :-(

You are right that SKS network is still important to a lot of
people, however I believe that this trust has been misplaced.
Hopefully these attack vectors (and potential mitigations) being
public will bring awareness to the issue and motivate someone to
create a more robust alternative to SKS, and users to prefer less
exploitable ways to share keys (or choose a different encryption
scheme entirely, say one that has forward secrecy, or pursue more
contained tools for signatures such as OpenBSD signify(1) or

I believe the importance of the SKS network to people is mutually exclusive of whether or not said people “trust” it. Like I mentioned earlier, it is of tremendous importance & value to myself and many people I communicate with … but we know the limitations and take additional measures to authenticate the data it provides. Sort of a trust, but verify model if you will. I trust it to be available world-wide for people to query and find GPG keys for the vast majority of people who are capable of receiving GPG email. I think verify the data I download from the network on the client side to make sure it’s authentic. Is it perfect? No. Do I still use it regularly despite it’s faults because it serves an important & useful purpose? Yes. Hopefully we will be able to address some of the issues being discussed, but let’s know trash what we have now because it’s not perfect.

The SKS network is even more important after the recent privacy
incidents that everybody knows about, and I wonder how safe is
PGP done in _javascript_, or sks key generation on Raspberry PI:)
. There were issues for ssh key pairs.

I don't think that SKS in its current state is safe to use.

Then by all means, don’t use it. Just don’t simultaneously ruin it for the rest of us who are still using it.

In closing, this isn’t meant to call out or pick on you specifically. I wanted to provide some color/context on why your responses might rub people the wrong way. Especially some of the people responsible for maintaining the SKS codebase and operating the nodes that make up the network. Your reply is acutely focussed on the shortcomings of the SKS network to the point of drawing conclusions that nobody should “trust” it (which to me reads like nobody should “use” it) and that it should be replaced with something better that addresses everyone’s concerns. But in the absence of such a replacement, many people will continue to rely on it and would appreciate if we could continue to do so until such time as something else is available.


P.S. Happy Thanksgiving to those of you who celebrate it!

Attachment: signature.asc
Description: Message signed with OpenPGP

reply via email to

[Prev in Thread] Current Thread [Next in Thread]