Re: [Sks-devel] sks.daylightpirates.org is staying...again

[Yegor Timoshenko]

> 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.

This is where I think most of disagreement down the message stems
from: you want a tool for GPG key distribution, I want people to
have safe, end-to-end encrypted comms and developers to be able
to authenticate themselves. Since this ecosystem increasingly
requires wizardly skills to do either safely, regularly has
fallouts like these, and does not promptly fix critical flaws,
maybe they should pick something else.

I'm sorry that sounds so heavy-handed and inflammatory, provoking
is not my intention. I'm trying to communicate solutions that
involve different toolchain are also valid solutions.

> 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:
> https://github.com/firstlookmedia/gpgsync
> <https://github.com/firstlookmedia/gpgsync>

Yeah, GPG Sync has great UI!

> 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.

Sure. However, since this particular outcome was not intended,
there was no way I would have wanted 3 nodes if I were to set up
an isolated test environment. Realistically, I think this
particular issue would have ended up being unknown.

> 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.

This could've easily ended up with some user trying to attach
several photos of themselves to their key which might've lead to
a similar result. Or a malicious entity taking down the whole SKS
network on purpose. In both cases, we would know less about the
attack vector than we do now.

This sentence is intended to emphasize how easy it is for someone
to damage the whole network, so much so that they could've done
that by accident. These were not some intricate planned attacks
which, after reading archives, seemed to be how most operators
viewed it.

> 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.

Much of the point I was making is that you can't trust it to be
available worldwide. Keyservers are still being presented to
users as being a good tool in a very high-threat security model:
that government can't silence you if they want to. That was never
true.

> > 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.

I meant users, not operators :-)

I believe that the vast majority of GnuPG users are not
tech-savvy enough to be protected from non-verified packets being
displayed as trustworthy on SKS web interface. I certainly wasn't
until I read that Bitbucket issue.

I believe most won't know what to do if their key is blocked from
recon via key poisoning technique. That could easily end up being
a life-threatening situation: imagine Alice compromised her key
to Eve and wants to tell Bob about it so that he doesn't send
messages encrypted for that key. In this case, Eve can block
Alice from ever uploading a revocation certificate.

I consider this to be a way worse outcome if that happens to any
single person than if the whole SKS network goes down. There are
alternative key distribution methods and encryption tools, but
there's no going back once adversary has someone's plain text.

It's great that you understand shortcomings of SKS, but most
people don't. I think those kinds of users are the kind that
should be protected the most. I don't believe SKS does good job
at that.

Source code of everything I've found is public as per full
disclosure. I think withholding those PoCs will harm the users
that need encryption the most, by tricking them into thinking
that they are safe, which they aren't and never were.

Unfortunately, this has a side effect: anyone can take down
keyservers or individual keys with very limited knowledge and
zero resources.

I truly don't want to break SKS for you or anyone else fond of
GnuPG ecosystem, but the alternative (withholding PoC attack
source code, testing only in isolation, limited disclosure, etc.)
is exactly what has been done during the last decade, i.e.
operators and developers talked about it, no one did anything,
users were never informed about attacks.

And so we ended up with a lot of users who use SKS keyservers and
consider them to be reliable (as in availability) and trustworthy
(as in, output can be trusted).

> 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.

Sure! No offense taken :-)

I understand these messages are edgy enough to guarantee me
getting flak, but I believe I wasn't communicating enough about
those issues, so I'm making up for it.