Re: “Keyservers are actually useless these days and I wish they could go away”

2019-07-21 Thread Dmitry Alexandrov
Werner Koch  wrote:
> On Wed, 17 Jul 2019 14:44, 321...@gmail.com said:
>> Werner Koch  wrote:
>>> Keyservers are actually useless these days and I wish they could go
away.
>>
>> An advocate of the ‘Web of Trust’ hardly agrees with that.  I am not the 
>> one, however I’m really intrigued — what do you suggest to use instead.
>
> If the goal is to make end-to-end encryption a standard on the Internet we 
> need to get away from geeky things like the WoT which is too complicated to 
> explain it to hackers in a few words.

I am not quite sure, why do you believe that a social network is a ‘geeky 
thing’, but in any case ‘to get away from something’ does not mean ‘to kill 
it’, does it?

> For the geek factor I really like it and it is quite possible that we will 
> develop ideas on how to keep it alive despite of the too obvious DoS attacks 
> on the keyservers.

I’m really glad to hear it, even though am have not been fan of it (as well as 
social networks in general).

>> What might the substitute [for keyservers]?  Bittorrent?  Blockchain?
>
> I propose the use of the Web Key Directory (WKD), which is a lookup of keys 
> from the webserver matching the domain of the mail address.

Yes, that is a means of publishing keys, that is normally controlled by one of 
the two possible attackers, is not it?

> The advantage is that you the entity assigning mail addresses also vouchs for 
> the matching key.

And the disadvantage is the same.  So even a proprietary service like 
keys.openpgp.org looks better from the security terms than WKD.

> This is already the default in GnuPG if you specify a recipient by mail 
> address.

And that is to my perplexity.  Why?!

> For those mail provider which will never implement that due to their business 
> model there is fallback solution: On the first contact a signed (but not 
> encrypted) mail is sent.  The recipient then gets the information for the key 
> from that signature and can may retrieve the key directly from the mail, or 
> via fingerprint from a keyserver, or via the mail address from the WKD.  Thus 
> the reply will already be encrypted and initial trust has been established.  
> We call this auto-key-retrieve.  This obviously needs support from the MUA.

Hm, what’s wrong with Autocrypt?

> Both schemes are implemented in Enigmail but are meanwhile hidden benhind the 
> other key discovery schemes.

And with transitioning to PEP-mode, they are both (along with Autocrypt) are 
obsoleted, as far as I see.

>>> Looking up key at a keyserver does not give you any indication that the key 
>>> belongs to the claimed mail address.
>>
>> But they was never intended to do so, was they?
>
> Right.  But in practise people assumed tha this is the case and complained 
> when a faked address was on the keyserver.

Indeed, some are.  But is following wrong expectations is the right thing to 
do?  This is the Internet after all: it’s full of fakes.  People should be 
sceptic there.

And to repeat it again, ability to verify any info (and email in particularly) 
does not require passing the full control of the data to a central authority, 
as verification is about appending the data, not removing it.  If no one have 
done this till today, maybe the problem is not so prominent in fact?

> The WoT does not scale

Pardon?  I hope, I can understand, how _SKS keyserver_, a software, does not 
scale well, but how could WoT per se, a concept of a social network, scale or 
not scale?

>> They are means to reliably _publish_ your key, and they have been doing 
>> their job fairly well, as far as I can tell.
>
> Nope.  We need keyservers only for key revocation and best also for lookup of 
> the basic key via fingerprint.

That is, my initial gladness was premature?  You _are_ going to kill keyservers 
as they exist now?

I have to admit, that this proposition looks really weird to me: to create one 
of the world first social networks, that have been shown a stable growth in 
userbase all those years despite being abandoned by developers and hardly 
usable, and finally, in 2019, declare that nobody needs it?

>> I suppose, few would have anything against a default server that also 
>> optionally performs an email / SIP / GNU Social / whatever check, as long 
>> it’s not a walled garden like keys.opengpg.org, that is that is detached 
>> from the de-facto standard network (that was SKS) and therefore breaks 
>> seamless compatibility between various GPG frontends and GPG-compatible 
>> clients.
>
> I would not call that small project...

Small?  It has been there for about a month, has not get its full strength yet 
(Enigmail will start uploading all keys there when Thunderbird 68 releases), 
though already has above 5 000 users.

> I would not call that small project a walled-garden and I even don't think 
> that it ever will be.

Okay, as you prefer it.  That’s after all only a metaphor, not a well-defined 
term, so it’s hard to assert that I’m using it appropriately.  I can only 

Re: “Keyservers are actually useless these days and I wish they could go away”

2019-07-18 Thread Werner Koch
On Wed, 17 Jul 2019 14:44, 321...@gmail.com said:

> An advocate of the ‘Web of Trust’ hardly agrees with that.  I am not
> the one, however I’m really intrigued — what do you suggest to use
> instead.

If the goal is to make end-to-end encryption a standard on the Internet
we need to get away from geeky things like the WoT which is too
complicated to explain it to hackers in a few words.  For the geek
factor I really like it and it is quite possible that we will develop
ideas on how to keep it alive despite of the too obvious DoS attacks on
the keyservers.  The basic idea is to allow uploads only by the key
owner.  OpenPGP has a flag for this and GnuPG has always set this flag.
However, due to lack of support in keyservers this has always been
ignored.  What we need is to have keyservers which are able to check
the self-signatures on a key to act upon it.  With that we can quickly
had a feature to authenticate uploads.

I propose the use of the Web Key Directory (WKD), which is a lookup of
keys from the webserver matching the domain of the mail address.  We
have all for this in place for a few years but need the support of the
large mail providers.  The advantage is that you the entity assigning
mail addresses also vouchs for the matching key.  This is already the
default in GnuPG if you specify a recipient by mail address.  Most MUAs
however first get a key listing from gpg and then select by fingerprint,
thus changes to the MUAs are needed.

For those mail provider which will never implement that due to their
business model there is fallback solution: On the first contact a signed
(but not encrypted) mail is sent.  The recipient then gets the
information for the key from that signature and can may retrieve the key
directly from the mail, or via fingerprint from a keyserver, or via the
mail address from the WKD.  Thus the reply will already be encrypted and
initial trust has been established.  We call this auto-key-retrieve.
This obviously needs support from the MUA.

Both schemes are implemented in Enigmail but are meanwhile hidden
benhind the other key discovery schemes.  It is implemeted in Kmail and
also in our tools for Windows.

>> Looking up key at a keyserver does not give you any indication that
>> the key belongs to the claimed mail address.
>
> But they was never intended to do so, was they?  They are mean to

Right.  But in practise people assumed tha this is the case and
complained when a faked address was on the keyserver.

> reliably _publish_ your key, and they have been doing their job fairly
> well, as far as I can tell.  What might the substitute?  Bittorrent?
> Blockchain?

Nope.  We need keyservers only for key revocation and best also for
lookup of the basic key via fingerprint.  This still works with the SKS
servers but there are too less of them left so that we hesitate to
re-enable the auto-key-retrieve feature by default in the major MUAs.

> I believe, nobody opposes to running a proprietary service for
> distributing keys, verifying or not, gratis or paid (yes, why not?).
> Setting it as a default is what I see as a dubious act.

If you want get something in use you need to have it has default.
Virtually nobody changes options. 

> Moreover, I suppose, few would have anything against a default server
> that also optionally performs an email / SIP / GNU Social / whatever
> check, as long it’s not a walled garden like keys.opengpg.org, that is

I would not call that small project a walled-garden and I even don't
think that it ever will be.  There is no business model behind it and I
can't see one.  PGP Inc did the same thing and they failed; otehrs
laucnhed such services too in the last 20 years and they faile as well.
No network effect, no success.  Thus the defaults matter.

What would you think about changing the control of that very
"walled-garden" from a single person to another legal entity?  For
example we have the charitable GnuPG e.V.[1] with members being people from
seeveral OpenPGP projects.  In fact that club has sufficent financial
resources to run several servers.  It would be quite similar to what Tor
is doing.

> Actually, if I am not mistaken, before the SKS-based WoT practically
> went out of operation after the DoS-attack, doing that did not require
> any changes neither in SKS, nor in GPG: a server could check the email
> and sign a key, and a frontend check its signature — that’s all.  Or
> am I mistaken?

The SKS keyserver software is not maintained and there are no hackers
brave enough to touch the code.  And worse there is no crypto support at
all.  Aside from SKS there is a couple of other software for keyservers
which could be extended to verify self-signature and implement require
features.  The Hagrid software might actually be the best choice right
now if they, or someone else, would change some of the policies
implemented in the code.

> But that does not, so long as no one is forbidden to run yet another
> verifier, connected to the common WoT.


Re: “Keyservers are actually useless these days and I wish they could go away”

2019-07-17 Thread Dmitry Alexandrov
Werner Koch  wrote:
> Keyservers are actually useless these days and I wish they could go away.

An advocate of the ‘Web of Trust’ hardly agrees with that.  I am not the one, 
however I’m really intrigued — what do you suggest to use instead.

> Looking up key at a keyserver does not give you any indication that the key 
> belongs to the claimed mail address.

But they was never intended to do so, was they?  They are mean to reliably 
_publish_ your key, and they have been doing their job fairly well, as far as I 
can tell.  What might the substitute?  Bittorrent?  Blockchain?

> A validating key server tries to fix this by claiming authority to check the 
> mail.

That’s an interesting sociotechnical task, but the topical issue is not about 
verifying vs non-verifying.

I believe, nobody opposes to running a proprietary service for distributing 
keys, verifying or not, gratis or paid (yes, why not?).  Setting it as a 
default is what I see as a dubious act.

Moreover, I suppose, few would have anything against a default server that also 
optionally performs an email / SIP / GNU Social / whatever check, as long it’s 
not a walled garden like keys.opengpg.org, that is detached from the de-facto 
standard network (that was SKS) and therefore breaks seamless compatibility 
between various GPG frontends and GPG-compatible clients.


Actually, if I am not mistaken, before the SKS-based WoT practically went out 
of operation after the DoS-attack, doing that did not require any changes 
neither in SKS, nor in GPG: a server could check the email and sign a key, and 
a frontend check its signature — that’s all.  Or am I mistaken?

> However, this gets us back into the X.509 centralized world.

But that does not, so long as no one is forbidden to run yet another verifier, 
connected to the common WoT.


signature.asc
Description: PGP signature
___
gnu-misc-discuss mailing list
gnu-misc-discuss@gnu.org
https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss