Re: Preserving public keyserver network (Re: Which keyserver)

[Stefan Claas via Gnupg-users]

If it is a technical challenge and Kristian as head (pool maintainer),
why does he not ask publicity
the hockeypuck author, dkg and the sequoia-team, for help?

As an example, if I would be Kristian I would do so, set-up with my
pool gang a hockeypuck
test-net (bootstrapped with a handful of pub keys) and work with the
programmer(s) on long
standing issues. Secondly I would give my gang a timeframe of a couple
of months to
gracefully shut down their SKS servers.

Would that have any disadvantages for GnuPG users worldwide, while we also have
Mailvelope and Hagrid?

On Sat, Oct 24, 2020 at 1:39 PM Andrew Gallagher  wrote:
>
>
> > On 24 Oct 2020, at 10:41, Stefan Claas via Gnupg-users 
> >  wrote:
> >
> > there can
> > be no consensus achieved between privacy loving EU citizens and (US
> > based) SKS operators
>
> Most SKS operators are (were?) based outside the US. This is primarily a 
> technical challenge, not a political one.

Regards
Stefan

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

Re: Preserving public keyserver network (Re: Which keyserver)

[Andrew Gallagher]

> On 24 Oct 2020, at 10:41, Stefan Claas via Gnupg-users 
>  wrote:
> 
> there can
> be no consensus achieved between privacy loving EU citizens and (US
> based) SKS operators

Most SKS operators are (were?) based outside the US. This is primarily a 
technical challenge, not a political one. 

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

Re: Preserving public keyserver network (Re: Which keyserver)

[Stefan Claas via Gnupg-users]

I can only speak for myself and see that when it comes to SKS that there can
be no consensus achieved between privacy loving EU citizens and (US
based) SKS operators, while Mailvelope and Hagrid respect the users wishes.

With that being said I am out and better let Mr Barr and Mr de Kerchove decide
what the SKS future will bring.

Last but not least I no longer need public SKS key servers.

Best regards
Stefan




On Fri, Oct 23, 2020 at 12:55 PM Bernhard Reiter  wrote:
>
> Am Samstag 19 September 2020 23:34:32 schrieb Stefan Claas:
> > I stand by my points that hockeypuck can solve the issues
>
> To me
> it makes sense to preserve a decentalised network of public keyservers [1].
>
> In my post
>  Preserving non-central and privacy with a "permission recording keyserver"
> [Reiter 2019-07 a]
>  https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034399.html
> there is a concept allowing for compatibility with strong privacy laws.
>
> Some ideas how we could conceptually preserve third party
> signature information on public servers:
>   Preserving third party signatures distribution [Reiter 2019-07 b]
>   https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034394.html
>
> So yes, I also believe that improvements to hockeypuck or a fresh
> implementation could step by step get the public keyserver network up again.
>
>
> Best Regards,
> Bernhard
> ps.: Because I believe funding more qualified dev time is part of the
> solution: You can become a sponsor for hockeypuck development, see
>   https://github.com/sponsors/cmars
> (my company Intevation is one, we also gave a small donation to KF Web running
>  https://sks-keyservers.net/).
>
>
> [1]
>   Web of Trust's usefulness [Reiter 2019-07 c]
>   https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034412.html
>
>   | as additional source of trust and history.
>
>   | Abandoning the web of trust common infrastructure works against usage
>   | models where there is anonymous usage, several identities, non-email use
>   | and offline usage. All those maybe not the majority case, they may even be
>   | niche models, but I think they are important to add diversity and
>   | resiliance against manipulations of mainstream players.
>(spelling improved)
>
> --
> www.intevation.de/~bernhard   +49 541 33 508 3-3
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
> ___
> 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: Preserving public keyserver network (Re: Which keyserver)

[Andrew Gallagher]

On 23/10/2020 13:23, Andrew Gallagher wrote:
> * Hints could take the form of fake preferred-keyserver subpackets, in a
> similar manner to fake "fpr:DEADBEEF" user-id packets that have been
> previously discussed to support UID-less key refresh on legacy systems
> (could both be combined in a single fake BIND sig?).

After a little further thought, such a combined-bind is wrongheaded. The
entire point of fake userids is that userids are (potentially) personal
data and therefore can't sync. ;-) So we'd have to bind the fake
preferred-keyserver subpacket separately.

-- 
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: Preserving public keyserver network (Re: Which keyserver)

[Andrew Gallagher]

On 23/10/2020 10:14, Bernhard Reiter wrote:
> So yes, I also believe that improvements to hockeypuck or a fresh 
> implementation could step by step get the public keyserver network up again.

I've thought about this quite a bit after my previous attempts to
reconcile recon with selective retention. I believe the solution is to
segregate the "recon" part of the process from the "retention" part.

Our current recon model requires that all packets that exist in the
keyserver network be reconned via the same method. This causes problems
when trying to apply retention policies to certain packets and not
others. For example, we almost always want revocation packets to recon,
almost *never* want user-attribute packets, and other packets such as
user-id fall somewhere in between.

If we segregate the recon and retention components, we can recon an
agreed bare minimum of packet types, without needing to apply per-key
filters and thereby avoiding any split-brain or sync-storm failures.
This minimal list of packet types would have to include primary keys and
revocation keys, but little (perhaps nothing?) else.

Along with these packets each keyserver would gossip a list of
associated hints from other keyservers. These hints would declare that
an "authoritative keyserver" exists that is serving the full key,
presumably having performed validation. The full set of packets would
not be advertised for recon, but would be available through hkp(s) as
normal (for the purposes of this section, the existence of an entry in
WKD would count as an "authoritative keyserver"). Other keyservers would
gossip that they have recently been able to download the full key from
one or more authoritative locations. Such hints would not be
cryptographically part of the key in question, so they should have an
expiration date in order to prevent stale info accumulating in the network.

A keyserver that is not willing to retain the full set of packets for a
given key could instead choose to serve them via a caching proxy or an
HTTP redirect to a server that is willing. This would allow for the full
public key to be discovered and refreshed by the usual methods, but
without every keyserver in the network having to retain its own copy.

It would still be advisable for a user to upload their full key to more
than one validating keyserver, in order to guard against service
outages, but even in the case where the only copy of the full key
becomes unavailable indefinitely, primary and revocation packets
associated with it would continue to recon. This model also has the
advantage of significantly reducing the number of packets in the recon
database.

Some other initial ideas:

* The new pool would have to be completely separate from the old pool,
because the deltas would be astronomical.

* Existing validating keyservers could cheaply "join the new pool" by
setting up a separate reconning keyserver in the pool that a) advertises
the appropriate hints on behalf of the validating keyserver and b)
submits any newly-synced packets into the validating keyserver.

* Hints could take the form of fake preferred-keyserver subpackets, in a
similar manner to fake "fpr:DEADBEEF" user-id packets that have been
previously discussed to support UID-less key refresh on legacy systems
(could both be combined in a single fake BIND sig?). These would be
amenable to recon, and naturally come with a timestamp that could be
used to expire them from the cache. Cryptographic non-verification
should ensure that real preferred-keyserver subpackets would override
such hints in client applications.

Thoughts?

-- 
Andrew Gallagher



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

Preserving public keyserver network (Re: Which keyserver)

[Bernhard Reiter]

Am Samstag 19 September 2020 23:34:32 schrieb Stefan Claas:
> I stand by my points that hockeypuck can solve the issues

To me 
it makes sense to preserve a decentalised network of public keyservers [1].

In my post 
 Preserving non-central and privacy with a "permission recording keyserver"
[Reiter 2019-07 a]
 https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034399.html
there is a concept allowing for compatibility with strong privacy laws.

Some ideas how we could conceptually preserve third party 
signature information on public servers:
  Preserving third party signatures distribution [Reiter 2019-07 b]
  https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034394.html

So yes, I also believe that improvements to hockeypuck or a fresh 
implementation could step by step get the public keyserver network up again.


Best Regards,
Bernhard
ps.: Because I believe funding more qualified dev time is part of the 
solution: You can become a sponsor for hockeypuck development, see   
  https://github.com/sponsors/cmars 
(my company Intevation is one, we also gave a small donation to KF Web running
 https://sks-keyservers.net/).


[1]
  Web of Trust's usefulness [Reiter 2019-07 c]
  https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034412.html

  | as additional source of trust and history.

  | Abandoning the web of trust common infrastructure works against usage
  | models where there is anonymous usage, several identities, non-email use
  | and offline usage. All those maybe not the majority case, they may even be
  | niche models, but I think they are important to add diversity and
  | resiliance against manipulations of mainstream players.
   (spelling improved)

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[MFPA via Gnupg-users]

Hi


On Sunday 20 September 2020 at 11:29:07 PM, in
, Mark wrote:-


> I'm the one that asked the original question in
> regards to GPG4Win. I
> know with the latest version the default is
> "hkp://keys.gnupg.net"

Thanks, Mark.

hkp://keys.gnupg.net is an alias for hkps://hkps.pool.sks-keyservers.net, which 
Phil said a couple of days ago was returning zero results. That issue is either 
intermittent or fixed, because I retrieved some keys from 
hkps://hkps.pool.sks-keyservers.net a few hours ago and again a few minutes 
ago. At least, a line of the output said "gpg: data source: 
https://hkps.pool.sks-keyservers.net:443 ". 

-- 
Best regards

MFPA  

Never interrupt me when I'm trying to interrupt you.

pgptemJrvZkD0.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Mark]

I'm the one that asked the original question in regards to GPG4Win. I
know with the latest version the default is "hkp://keys.gnupg.net"

On 9/20/2020 4:58 AM, MFPA via Gnupg-users wrote:
> Hi
>
>
> On Saturday 19 September 2020 at 7:34:13 PM, in
> , Phil
> Pennock via Gnupg-users wrote:-
>
>
>> The original question was:
>> } I use GPG4Win and I've noticed that
>> "hkp://keys.gnupg.net" is not
>> so that's what I answered.
> I asked a different but related question that occurred to me when I read in 
> your post that hkps.pool.sks-keyservers.net "is now returning zero results". 
> I had noticed the GnuPG manual says the default keyserver is 
> hkps.pool.sks-keyservers.net. I was under the impression the default had been 
> changed to the Hagrid keyserver at keys.openpgp.org after the SKS attacks, so 
> I asked the question to this list.
>
>
>> The mapping is in
>> dirmngr/server.c:make_keyserver_item() and the default
>> is found via compile-time configure, which defaults to
>> hkps://hkps.pool.sks-keyservers.net (see configure.ac
>> DIRMNGR_DEFAULT_KEYSERVER).
> So we have a default keyserver that is returning zero results?
>
>
> ___
> 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: Which keyserver

[MFPA via Gnupg-users]

Hi


On Saturday 19 September 2020 at 7:34:13 PM, in
, Phil
Pennock via Gnupg-users wrote:-


> The original question was:
> } I use GPG4Win and I've noticed that
> "hkp://keys.gnupg.net" is not

> so that's what I answered.  

I asked a different but related question that occurred to me when I read in 
your post that hkps.pool.sks-keyservers.net "is now returning zero results". I 
had noticed the GnuPG manual says the default keyserver is 
hkps.pool.sks-keyservers.net. I was under the impression the default had been 
changed to the Hagrid keyserver at keys.openpgp.org after the SKS attacks, so I 
asked the question to this list. 


> The mapping is in
> dirmngr/server.c:make_keyserver_item() and the default
> is found via compile-time configure, which defaults to
> hkps://hkps.pool.sks-keyservers.net (see configure.ac
> DIRMNGR_DEFAULT_KEYSERVER).

So we have a default keyserver that is returning zero results?

-- 
Best regards

MFPA  

The more corrupt the state, the more numerous the laws. (Tacitus)

pgp7t_A9mk5bx.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Neal H. Walfield]

Hi Andrew,

On Sat, 19 Sep 2020 21:38:22 +0200,
Andrew Gallagher wrote:
> Hagrid “solves” the vandalism problem by abandoning
> decentralisation.

This is not strictly true.

When we think about updating keys, there are two types of information
that can be updated:

  - Identity Information (User IDs)
  - Operational Information (Revocations, Subkey Rotations, Metadata
(self-sig) updates, etc.)

Identity information in privacy sensitive, and we think people should
be able to control where their details are published, and have the
ability to retract them, if desired.  This requires some type of
centralization.

Operation Information does not require the same protection, and can
and should be widely published.  It would be possible to create a
network of keyservers that synchronize this type of information in a
similar way to how SKS worked.  But, we know from experience with SKS
that this is not easy (the set of filters needs to be synchronized,
etc., which is a type of centralization).  So far, no one has taken
the time to think through this problem, and implement a solution for
Hagrid.  But, I think that we'd welcome a patch that adds such
functionality.

:) Neal

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

Re: Which keyserver

[Stefan Claas]

Andrew Gallagher wrote:
 
> 
> > On 19 Sep 2020, at 21:06, Stefan Claas  wrote:
> > 
> > *With all due respect*, the problems you mention with the SKS protocol is 
> > IMHO absolutely solvable with hockeypuck if the
> > author implements the same Mailvelope or Hagrid confirmation process for 
> > its users
> 
> If you have not yet read the mega threads from a year or two back over on the 
> sks mailing list discussing how filtering is
> incompatible with open synchronisation, I suggest you do so before opining 
> further. I really don’t have the energy to explain
> it again! ;-) tl;dr: if you don’t have either a central authority or an 
> agreed, future-proof zkp system of verification
> (itself a Very Hard Problem) then your decentralised network goes split brain 
> at the slightest provocation. 
> 
> https://lists.nongnu.org/archive/html/sks-devel/2018-05/msg9.html
> 
> https://lists.nongnu.org/archive/html/sks-devel/2019-02/msg00010.html
> 
> I’d also suggest reading DKG’s proposals for what *is* technically possible, 
> as they are pretty comprehensive: 
> 
> https://lists.nongnu.org/archive/html/sks-devel/2019-04/msg2.html
> 
> Finally, I would suggest continuing any technical discussions on sks-devel 
> rather than here as we are veering off topic.

I am not interested to discuss old SKS issues/proposals further on the SKS 
mailing list
with (former) SKS operators and only wanted to bring my POV to GnuPG users 
attention.

I am aware of dkg's fine draft and his other valuable contributions he made.

I stand by my points that hockeypuck can solve the issues and will respect your
wish to not further discuss technical SKS issues here on the GnuPG Mailing List.

In case dkg is reading this thread, maybe he, as highly respected community 
member and
skilled programmer, can discuss these things with the hockeypuck author on 
GitHub, in
case he has time and is willing to do so. 

Regards
Stefan

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

Re: Which keyserver

[Steffen Nurpmeso]

Stefan Claas wrote in
 <20200919201736.2...@300baud.de>:
 |Robert J. Hansen wrote:
 |>> It is true the attacks were what brought it down, but the amount \
 |>> of effort was not a "sustained
 |>> attack" by any measure. The invested resources are somewhere around \
 |>> "couple hours and $0.00".
 |> 
 |> I'm not sure that's true.
 |
 |[...]
 |
 |I think it does not matter.
 |
 |Professional businesses and their customers can use the mentioned Mailve\
 |lope key server,
 |to protect their keys or use for anonymity purposes Hagrid, in combination \
 |with sequoia
 |pgp, while the geeks can use WKD.
 |
 |The only thing SKS, so it seems, is currently good for is decentralized \
 |file sharing or
 |for chat purposes, when using SKS chat software.

SKS served me very well for many years, and it is a shame that
even national/related agencies with quite some funding, or
universities with that immense pool of students did not stood up
trying to keep this decade old community driven infrastructure
alive.  I guess they all were eating burger, and at that level.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: Which keyserver

[Andrew Gallagher]

> On 19 Sep 2020, at 21:06, Stefan Claas  wrote:
> 
> *With all due respect*, the problems you mention with the SKS protocol is 
> IMHO absolutely solvable with hockeypuck if the author
> implements the same Mailvelope or Hagrid confirmation process for its users

If you have not yet read the mega threads from a year or two back over on the 
sks mailing list discussing how filtering is incompatible with open 
synchronisation, I suggest you do so before opining further. I really don’t 
have the energy to explain it again! ;-) tl;dr: if you don’t have either a 
central authority or an agreed, future-proof zkp system of verification (itself 
a Very Hard Problem) then your decentralised network goes split brain at the 
slightest provocation. 

https://lists.nongnu.org/archive/html/sks-devel/2018-05/msg9.html

https://lists.nongnu.org/archive/html/sks-devel/2019-02/msg00010.html

I’d also suggest reading DKG’s proposals for what *is* technically possible, as 
they are pretty comprehensive: 

https://lists.nongnu.org/archive/html/sks-devel/2019-04/msg2.html

Finally, I would suggest continuing any technical discussions on sks-devel 
rather than here as we are veering off topic.

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

Re: Which keyserver

[Stefan Claas]

Andrew Gallagher wrote:
 
> 
> > On 19 Sep 2020, at 20:05, Stefan Claas  wrote:
> > 
> > Well, there is IMHO a good replacement for SKS available, called
> > hockeypuck and it is written in modern Golang.
> 
> This is beside the point. SKS is both a protocol and an implementation. 
> Hockeypuck is a reimplementation of the same protocol
> and is so is vulnerable to the same poisoning issues. 
> 
> The problem with the SKS *protocol* is very hard to fix, because designing a 
> universal, publicly writable datastore means
> solving a trilemma: censorship resistance, vandalism resistance, and 
> decentralisation. SKS prioritises censorship resistance
> and decentralisation, and so is vulnerable to vandalism. Hagrid “solves” the 
> vandalism problem by abandoning
> decentralisation. WKD steps outside the problem space by abandoning 
> universality. All these are valid alternatives, but none
> can be called a “replacement”.

*With all due respect*, the problems you mention with the SKS protocol is IMHO 
absolutely solvable with hockeypuck if the author
implements the same Mailvelope or Hagrid confirmation process for its users, or 
it would honor the SKS --no-modify flag, Werner
implemented long time ago in GnuPG. And if (former) SKS key server operators 
would be honest this could be solved with
hockeypuck and if not people which are using GnuPG or OpenPGP apps may 
wondering how it comes that a client/server model for
*security/privacy* software is from the SKS server side globally still 
operated, if it can not *protect* their users pub keys
adequately?

I am very sorry to say that but all arguments from former or current SKS 
operators do not convince me nor do they show the
OpenPGP users community willingness or advancements in this area, to be taken 
serious.

Best regards
Stefan
 

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

Re: Which keyserver

[Phil Pennock via Gnupg-users]

On 2020-09-19 at 11:44 +0100, MFPA via Gnupg-users wrote:
> On Friday 18 September 2020 at 4:32:55 PM, in
> , Phil
> Pennock via Gnupg-users wrote:-
> 
> 
> > keys.gnupg.net is a CNAME for
> > hkps.pool.sks-keyservers.net -- which is
> > now returning zero results.
> 
> 
> The GnuPG manual's description [0] of the Dirmngr option "--keyserver name" 
> still ends with "If no keyserver is explicitly configured, dirmngr will use 
> the built-in default of hkps://hkps.pool.sks-keyservers.net." Is this still 
> true, or was the default changed?

The original question was:
} I use GPG4Win and I've noticed that "hkp://keys.gnupg.net" is not

so that's what I answered.  keys.gnupg.net _used to be_ the default, but
it was changed and nowadays there is both a CNAME in DNS and logic in
modern GnuPG to hard-replace the hostname.

The mapping is in dirmngr/server.c:make_keyserver_item() and the default
is found via compile-time configure, which defaults to
hkps://hkps.pool.sks-keyservers.net (see configure.ac
DIRMNGR_DEFAULT_KEYSERVER).

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

Re: Which keyserver

[Andrew Gallagher]

> On 19 Sep 2020, at 20:05, Stefan Claas  wrote:
> 
> Well, there is IMHO a good replacement for SKS available, called
> hockeypuck and it is written in modern Golang.

This is beside the point. SKS is both a protocol and an implementation. 
Hockeypuck is a reimplementation of the same protocol and is so is vulnerable 
to the same poisoning issues. 

The problem with the SKS *protocol* is very hard to fix, because designing a 
universal, publicly writable datastore means solving a trilemma: censorship 
resistance, vandalism resistance, and decentralisation. SKS prioritises 
censorship resistance and decentralisation, and so is vulnerable to vandalism. 
Hagrid “solves” the vandalism problem by abandoning decentralisation. WKD steps 
outside the problem space by abandoning universality. All these are valid 
alternatives, but none can be called a “replacement”.

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

Re: Which keyserver

[Stefan Claas]

Steffen Nurpmeso wrote:
 
> Stefan Claas wrote in
>  <20200919201736.2...@300baud.de>:
>  |Robert J. Hansen wrote:
>  |>> It is true the attacks were what brought it down, but the amount \
>  |>> of effort was not a "sustained
>  |>> attack" by any measure. The invested resources are somewhere around \
>  |>> "couple hours and $0.00".
>  |> 
>  |> I'm not sure that's true.
>  |
>  |[...]
>  |
>  |I think it does not matter.
>  |
>  |Professional businesses and their customers can use the mentioned Mailve\
>  |lope key server,
>  |to protect their keys or use for anonymity purposes Hagrid, in combination \
>  |with sequoia
>  |pgp, while the geeks can use WKD.
>  |
>  |The only thing SKS, so it seems, is currently good for is decentralized \
>  |file sharing or
>  |for chat purposes, when using SKS chat software.
> 
> SKS served me very well for many years, and it is a shame that
> even national/related agencies with quite some funding, or
> universities with that immense pool of students did not stood up
> trying to keep this decade old community driven infrastructure
> alive.  I guess they all were eating burger, and at that level.

Well, there is IMHO a good replacement for SKS available, called
hockeypuck and it is written in modern Golang.

The problem is that those (I don't know what to call these people
publicity) SKS key server operators have no plan.

The hockeypuck author is really fast in responding when it comes
to issues and I guess he would be quite happy to help the SKS operators
with solving issues, or listen to users if they have proposals.

The good thing about the modern programming language Golang is that
*soo* many (young) people are using Golang nowadays, that
it should be easy to assist the author of hockeypuck.

Regards
Stefan


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

Re: Which keyserver

[Stefan Claas]

Robert J. Hansen wrote:
 
> > It is true the attacks were what brought it down, but the amount of effort 
> > was not a "sustained
> > attack" by any measure. The invested resources are somewhere around "couple 
> > hours and $0.00".
> 
> I'm not sure that's true.

[...]

I think it does not matter.

Professional businesses and their customers can use the mentioned Mailvelope 
key server,
to protect their keys or use for anonymity purposes Hagrid, in combination with 
sequoia
pgp, while the geeks can use WKD.

The only thing SKS, so it seems, is currently good for is decentralized file 
sharing or
for chat purposes, when using SKS chat software.

Regards
Stefan

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

Re: Which keyserver

[Robert J. Hansen]

> It is true the attacks were what brought it down, but the amount of effort 
> was not a "sustained
> attack" by any measure. The invested resources are somewhere around "couple 
> hours and $0.00".

I'm not sure that's true.

The keyserver poisoning attack was demonstrated first by EFF's Micah
Lee.  When he published his findings, he also published the Python
scripts necessary to execute the attack.

I don't know who the poisoner was.  However, if I were to do the
poisoning attack I certainly would've begun by downloading Micah's code
and adapting it to the task.  And for that reason I think it's entirely
reasonable to believe the keyserver poisoning attack was bootstrapped by
an EFF-funded research project which inappropriately released attack tools.

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

Re: Which keyserver

[MFPA via Gnupg-users]

Hi


On Friday 18 September 2020 at 4:32:55 PM, in
, Phil
Pennock via Gnupg-users wrote:-


> keys.gnupg.net is a CNAME for
> hkps.pool.sks-keyservers.net -- which is
> now returning zero results.


The GnuPG manual's description [0] of the Dirmngr option "--keyserver name" 
still ends with "If no keyserver is explicitly configured, dirmngr will use the 
built-in default of hkps://hkps.pool.sks-keyservers.net." Is this still true, 
or was the default changed?

[0] 
https://gnupg.org/documentation/manuals/gnupg/Dirmngr-Options.html#Dirmngr-Options

-- 
Best regards

MFPA  

Ballerinas are always on their toes.  We need taller ballerinas!

pgp68dbHVaZmx.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Which keyserver

[Vincent Breitmoser via Gnupg-users]

> keys.gnupg.net is a CNAME for hkps.pool.sks-keyservers.net -- which is
> now returning zero results.

Let me break the prose down into the simple facts:

* the "HKPS" pool is no longer actually a "pool". it is a [single server].

* the "HKP" pool still contains a few servers, but using it means *all 
communication happens in plain text*.

* the newest release of SKS is [1.1.6], from august 2016.

> until it came under sustained attack from people trying to burn it all down

It is true the attacks were what brought it down, but the amount of effort was 
not a "sustained
attack" by any measure. The invested resources are somewhere around "couple 
hours and $0.00".

 - V

[single server]: https://sks-keyservers.net/status/ (hkps column)
[1.1.6]: 
https://github.com/SKS-Keyserver/sks-keyserver/commit/b1725fda5dd89343b304c2126df78ad34bef66a8

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

Re: Which keyserver

[Phil Pennock via Gnupg-users]

On 2020-09-18 at 15:04 +0200, accounts-gn...@holbrook.no wrote:
> Is it possible to define multiple sources of keys with WKD, for example
> with a dns TXT record? The use-case would be if the main server is down,
> alternative places to get it.

The SRV record approach had to be dropped because the people doing
OpenPGP in web-browsers protested hard, since browsers _still_ refuse to
implement SRV lookup.  So we're stuck with an ancient model.

Currently that means "set up openpgpkey.example.org using whatever
loadbalancers and multiple A records across regions you like".

Within a few years we _might_ be able to get SRV-like distribution for
HTTPS with the proposed new `HTTPS` RR-type for DNS:
  https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https
but that's not something you can rely on today.

-Phil

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

Re: Which keyserver

[Mark]

Phil,

Thanks for the explanation on what was happening. I thought something
was just not right as when I hit search it would come back in less than
a second with 0 results. It seemed to me that it didn't actually even
search through the database. Anyway now that you say there is not really
a server anymore to search it makes sense. 

I'm not familiar with the attack on it and by who so will have to google
it and see if I can learn more.

On 9/18/2020 8:32 AM, Phil Pennock wrote:
> On 2020-09-18 at 08:06 -0700, Mark wrote:
>> I use GPG4Win and I've noticed that "hkp://keys.gnupg.net" is not
>> working right. I was not getting any hits back when searching with
>> Kleopatra and then I tried to ping that server which returned host not
>> found.  So I'm also interested if there is a better choice.
> keys.gnupg.net is a CNAME for hkps.pool.sks-keyservers.net -- which is
> now returning zero results.
>
> The pool of  is Very Unhealthy.  The entire keyserver
> system had Known Issues but worked well enough that the volunteers who
> ran it could keep it alive and improving, until it came under sustained
> attack from people trying to burn it all down and push people to use
> "not OpenPGP" instead (some of the funding for attack tool development
> came from an org which is firmly pushing one of the modern alternative
> encrypted communications tools).
>
> There's still some keyservers, but what you see now are the red smoking
> embers of what's left after everything else has been burnt down.  From a
> pool of around 120 servers, almost all routinely working fairly well and
> being able to maintain per-continent pool aliases of servers which were
> health-checked and removed if not doing well, there's now fewer than 20
> servers left, from very few independent sources, and even those in the
> main pool are often not doing well.
>
> Which is why folks are struggling and trying to find something which
> works well enough.  There's nothing which fits all needs, but various
> solutions for some scenarios.  See my first reply in this thread with
> suggestions of particular servers.
>
> -Phil

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

Re: Which keyserver

[Andreas Mattheiss]

Hello,

>Is it possible to define multiple sources of keys with WKD, for example
>with a dns TXT record?

Well, yes, actually. This can be done with both X509 certificates (where it is 
called SMIMEA) and gpg keys. Obtaining a key basically involves quering the 
appropriate TYPE in the DNS record (53 for SMIMEA, 61 for openpgp). An 
additional step is to check the authenticity of this record. All this is 
completely seperate from WKD though.

That's the theory. In practise, alas, bugger all's using it. It's a shame, 
since this would really be a big step forward. The catch here is that it needs 
to be supported by the mail server where the addressee has his account. 
Needless to mention it is hardly deployed; in Germany mail.de has it, as do a 
number of paid email services. Plus, of course: before this goes big, the big 
email clients would have to support it. Of course you can hack something 
together using only command line tools (I've done that), but that's not the cup 
of tea for 99.9% of normal email users.

Vincent Breitmoser described this in this thread eloquently as being used by 
effectively nobody but a rounding error. Sigh.

Andreas

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

Re: Which keyserver

[Phil Pennock via Gnupg-users]

On 2020-09-18 at 08:06 -0700, Mark wrote:
> I use GPG4Win and I've noticed that "hkp://keys.gnupg.net" is not
> working right. I was not getting any hits back when searching with
> Kleopatra and then I tried to ping that server which returned host not
> found.  So I'm also interested if there is a better choice.

keys.gnupg.net is a CNAME for hkps.pool.sks-keyservers.net -- which is
now returning zero results.

The pool of SKS keyservers is Very Unhealthy.  The entire keyserver
system had Known Issues but worked well enough that the volunteers who
ran it could keep it alive and improving, until it came under sustained
attack from people trying to burn it all down and push people to use
"not OpenPGP" instead (some of the funding for attack tool development
came from an org which is firmly pushing one of the modern alternative
encrypted communications tools).

There's still some keyservers, but what you see now are the red smoking
embers of what's left after everything else has been burnt down.  From a
pool of around 120 servers, almost all routinely working fairly well and
being able to maintain per-continent pool aliases of servers which were
health-checked and removed if not doing well, there's now fewer than 20
servers left, from very few independent sources, and even those in the
main pool are often not doing well.

Which is why folks are struggling and trying to find something which
works well enough.  There's nothing which fits all needs, but various
solutions for some scenarios.  See my first reply in this thread with
suggestions of particular servers.

-Phil

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

Re: Which keyserver

[Phil Pennock via Gnupg-users]

On 2020-09-18 at 10:08 +0200, Franck Routier (perso) wrote:
> Le jeudi 17 septembre 2020 à 18:13 -0400, Phil Pennock via Gnupg-users
> a écrit :
> >  If publishing keys, I do recommend setting up WKD for your
> > domain, which helps a little.
> 
> What is the status of WKD now, and is it to superseed centralized key
> servers ?

It's a draft spec, it's spreading a little.  Federated control of your
own namespace is always good.  Ultimately it's just HTTPS with a fixed
well-known layout.

kernel.org, debian.org, gentoo.org, archlinux.org -- it's spreading
amongst the Linux folks who have a central idea of what PGP keys are
supposed to exist in their domain.

Then there's exim.org and a couple of others, but I set those up and so
I can't say that this is proof of its popularity.

I think that any organization which uses PGP, including for signing
software releases, should be setting up WKD.  Non-WKD is for individuals
using PGP on a more ad-hoc basis.

Self-pimping:  has
other/standalone-update-website as a Python tool which can be integrated
into static site builds where something else manages the list of keys (I
have it in a Gulp rule for nats.io site build) and the repo itself is a
framework for managing the keys for one or more domains, so is used for
spodhuis.org, exim.org and pennock-tech.com.  The repo is designed to be
easy to fork and replace the key/domain definitions so that others can
use it.

-Phil

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

Re: Which keyserver

[Mark]

I use GPG4Win and I've noticed that "hkp://keys.gnupg.net" is not
working right. I was not getting any hits back when searching with
Kleopatra and then I tried to ping that server which returned host not
found.  So I'm also interested if there is a better choice.


On 9/17/2020 1:57 PM, Martin wrote:
> Hi list
>
> Which keyserver do you recommend these days?
>
> I have hkps://keys.openpgp.org in gpg.conf - but it seems that there
> are missing a lot of public keys on this server.
>
>
>
> ___
> 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: Which keyserver

[accounts-gnupg]

I wasn't aware of WKD, thanks for the heads up.

Is it possible to define multiple sources of keys with WKD, for example
with a dns TXT record? The use-case would be if the main server is down,
alternative places to get it.


On Fri, Sep 18, 2020 at 12:55:45PM +0200, Vincent Breitmoser via Gnupg-users 
wrote:
> 
> > What is the status of WKD now, and is it to superseed centralized key
> > servers ?
> 
> Not for folks who have their email address at the domain of an email provider,
> or an organization that doesn't support WKD. So statistically, everyone but
> a rounding error.
> 
> That said, for folks who run their own domain, a it seems WKD is gaining some
> ground.  keys.o.o has a (sort of experimental) "[WKD as a Service]" feature, 
> and
> at this point there are more than 100 domains running on it. That's not a huge
> amount, assuming most of those are single-user domains, but it's something :)
> 
>  - V
> 
> [WKD as a Service]: https://keys.openpgp.org/about/usage#wkd-as-a-service
> 
> ___
> 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: Which keyserver

[Vincent Breitmoser via Gnupg-users]

> What is the status of WKD now, and is it to superseed centralized key
> servers ?

Not for folks who have their email address at the domain of an email provider,
or an organization that doesn't support WKD. So statistically, everyone but
a rounding error.

That said, for folks who run their own domain, a it seems WKD is gaining some
ground.  keys.o.o has a (sort of experimental) "[WKD as a Service]" feature, and
at this point there are more than 100 domains running on it. That's not a huge
amount, assuming most of those are single-user domains, but it's something :)

 - V

[WKD as a Service]: https://keys.openpgp.org/about/usage#wkd-as-a-service

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

Re: Which keyserver

[Franck Routier (perso)]

Le jeudi 17 septembre 2020 à 18:13 -0400, Phil Pennock via Gnupg-users
a écrit :
>  If publishing keys, I do recommend setting up WKD for your
> domain, which helps a little.

What is the status of WKD now, and is it to superseed centralized key
servers ?

Franck


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

Re: Which keyserver

[Phil Pennock via Gnupg-users]

On 2020-09-17 at 22:57 +0200, Martin wrote:
> Which keyserver do you recommend these days?

For what purpose?

For receiving updates to previously known keys, of people who care
enough about their keys to distribute their keys across multiple
keyservers instead of just going "I pushed it to the keyservers, that's
it, I don't care", hkps://keys.openpgp.org is probably the most
reasonable choice.

There's no choice for general purpose, and  "running a keysigning party"
or "finding someone's key from their fingerprint" which works well
today.  If publishing keys, I do recommend setting up WKD for your
domain, which helps a little.  And heck, I run a finger daemon written
in Go for a true blast from the past.  :)

 is in the UK, run from the same University bunch of
folks as gave us PuTTY and has been around receiving keys from the SKS
keyservers via email for ages, so tends to be "fairly well populated",
so is where I try next after openpgp.org.

After that I hit old SKS keyservers which usually seem to work, whether
or not these entries are in the pools and _current_, since they'll at
least get me some of a key; the pool hostnames haven't been worth trying
the last several times I checked, too many bad servers.

  hkps://keyserver.ubuntu.com
  hkps://zimmermann.mayfirst.org
  hkp://keys2.kfwebs.net
  hkps://pgp.mit.edu

The kfwebs and pgp.mit.edu servers appear to not be working right now,
which leaves us with Ubuntu's and Dan Gillmor's (DKG's) mayfirst.org
server.

You can still look over https://sks-keyservers.net/status/ to see if
there are any working there, if the pool hostnames are broken for you at
the time you check.  The status list for the servers not in the pools
will show you how far "behind" they are.

-Phil

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

Re: Which keyserver

[Stefan Claas]

Martin wrote:
 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi list
> 
> Which keyserver do you recommend these days?
> 
> I have hkps://keys.openpgp.org in gpg.conf - but it seems that there
> are missing a lot of public keys on this server.

Hi,

good question ... I like https://keys.mailvelope.com/ best, because
it only allows publishing your pub key if you decrypt their reply
with your secret key and as bonus it keeps your collected WoT sigs,
in case you need the classical WoT signatures, or CA sigs, like from
Governikus etc.

Unfortunately gpg.conf, IIRC, allows only defining one key server and
many people still use SKS key servers.

Regards
Stefan

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