Mailing List Archive

recommendation for key servers
Hi, we heard that sks-keyservers.net will be depreciated
so we were wondering what service we should use in the application default
settings
We I mean TDE devs

where do we go from here?

thank you in advance
BR
Re: recommendation for key servers [ In reply to ]
Hi BR,

Am Freitag, den 25.06.2021, 00:12 +0200 schrieb deloptes via Gnupg-
devel:
> Hi, we heard that sks-keyservers.net will be depreciated
> so we were wondering what service we should use in the application
> default
> settings
> We I mean TDE devs

most PGP tools default to keys.openpgp.org these days.

Cheers,
Jan


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: recommendation for key servers [ In reply to ]
On Fri, 25 Jun 2021 08:00, Jan Girlich said:

> most PGP tools default to keys.openpgp.org these days.

Which unfortunately is a non-OpenPGP compliant keyserver and not syncing
with other keyservers. It has the same problems as the PGP.com keyserver
from the early 2000 years. I would suggest not to use keyservers for key
discovery but install a web key directory or an internal LDAP server or
use the AD.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: recommendation for key servers [ In reply to ]
On 25/06/2021 11:08, Werner Koch via Gnupg-devel wrote:
> On Fri, 25 Jun 2021 08:00, Jan Girlich said:
>
>> most PGP tools default to keys.openpgp.org these days.
>
> Which unfortunately is a non-OpenPGP compliant keyserver and not syncing
> with other keyservers. It has the same problems as the PGP.com keyserver
> from the early 2000 years. I would suggest not to use keyservers for key
> discovery but install a web key directory or an internal LDAP server or
> use the AD.

I agree, WKD should be the first choice method to publish your own key,
so long as you or someone PGP-friendly is in charge of your email domain
(it's no use for gmail addresses, for example). But implementing WKD
yourself does not help you discover other people's keys, unless you both
belong to the same organisation (same applies to AD, LDAP etc).

Most modern software will check WKD regardless of your keyserver
settings, so if it is in use by your correspondent's email domain, it
should Just Work. But for the majority of users, you still have to fall
back to another discovery method.

The keystore trilemma is not yet solved. You can have two out of three
of decentralisation, universality, and abuse-resistance. WKD is
decentralised and abuse-resistant but is not universal. keys.openpgp.org
is universal and abuse-resistant but highly centralised (and
functionally limited). Synchronising keyservers (SKS and Hockeypuck) are
decentralised and universal but abuse-prone.

Signature attestations will help tackle many of the abuse (and
functional limitation) issues, if we can get them standardised in a
future openpgp update (rfc4880tris?). But we will probably have to live
with more than one system for the foreseeable future, given the
different compromises required.

--
Andrew Gallagher
Re: recommendation for key servers [ In reply to ]
Hi and thank you for your responses!

On Fri, Jun 25, 2021 at 4:03 PM Andrew Gallagher via Gnupg-devel <
gnupg-devel@gnupg.org> wrote:

> On 25/06/2021 11:08, Werner Koch via Gnupg-devel wrote:
> > On Fri, 25 Jun 2021 08:00, Jan Girlich said:
> >
> >> most PGP tools default to keys.openpgp.org these days.
> >
> > Which unfortunately is a non-OpenPGP compliant keyserver and not syncing
> > with other keyservers. It has the same problems as the PGP.com keyserver
> > from the early 2000 years. I would suggest not to use keyservers for key
> > discovery but install a web key directory or an internal LDAP server or
> > use the AD.
>
> I agree, WKD should be the first choice method to publish your own key,
> so long as you or someone PGP-friendly is in charge of your email domain
> (it's no use for gmail addresses, for example). But implementing WKD
> yourself does not help you discover other people's keys, unless you both
> belong to the same organisation (same applies to AD, LDAP etc).
>
> Most modern software will check WKD regardless of your keyserver
> settings, so if it is in use by your correspondent's email domain, it
> should Just Work. But for the majority of users, you still have to fall
> back to another discovery method.
>
>
Our GPG Client (actually many of you may know the old KGpg client) has the
option to search for keys on a specific server by default.
From what I hear, we can conclude that this is good by option and we have
to replace with something, but we still do not know with what :/

I would not consider it as modern software :D at least no one has the time
to work on the client and add features. So this is why I am asking here
what to do, so that the very small developers team on TDE could take the
right decision and not burn resources in vain.


> The keystore trilemma is not yet solved. You can have two out of three
> of decentralisation, universality, and abuse-resistance. WKD is
> decentralised and abuse-resistant but is not universal. keys.openpgp.org
> is universal and abuse-resistant but highly centralised (and
> functionally limited). Synchronising keyservers (SKS and Hockeypuck) are
> decentralised and universal but abuse-prone.
>
> Signature attestations will help tackle many of the abuse (and
> functional limitation) issues, if we can get them standardised in a
> future openpgp update (rfc4880tris?). But we will probably have to live
> with more than one system for the foreseeable future, given the
> different compromises required.
>
>
So to put it short in the future there will be no openpgp server(s) because
of the GDRP?
I was wondering who is objecting the existence of the SKS server. In the
mail thread (from 2018) and the message from this month, it says only about
more and more complains.
Could it be potential attack on the opengpg community - I could not follow
until the end. Can you summarize who and how took the decision to take this
server down?
Couple of years ago, I thought finally someone took care of GPG and did the
right thing, so that one can have a single server, to look for and upload
keys - now it seems it is over

thank you in advance

BR
Re: recommendation for key servers [ In reply to ]
Andrew Gallagher via Gnupg-devel <gnupg-devel@gnupg.org> writes:

> Signature attestations will help tackle many of the abuse (and
> functional limitation) issues, if we can get them standardised in a
> future openpgp update (rfc4880tris?).

First-party attested third-party certifications (1pa3pc) as described by
Werner, Vincent, and dkg in RFC4880bis-10 are implemented in DKGPG,
PGPy, and Sequoia. Command-line frontends for DKGPG and Sequoia can be
used to attest to certifications.

As of Thursday, keys.openpgp.org serves attested third-party
certifications in accordance with the principle of primary key
sovereignty.

I'm happy to answer any questions related to this.

Justus
Re: recommendation for key servers [ In reply to ]
> Which unfortunately is a non-OpenPGP compliant keyserver

This phrasing understates the contention that exists around this point.

For those who want to read up on it and form their own opinion, a lot of
discussion happened on the GnuPG issue tracker: https://dev.gnupg.org/T4393

- V


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: recommendation for key servers [ In reply to ]
On Sat, 26 Jun 2021 19:31, Vincent Breitmoser said:

> This phrasing understates the contention that exists around this point.

I can only repeat that stripping the User-ID from a key is Bad Thing and
more of a willfully created tombstone for OpenPGP. The pleaded GDPR
issue is artificial and entirely ignores the fact that the key or its
fingerprint is as well personal data (“any information which [is]
related to an identified or identifiable natural person”) and thus
subject to the GDPR rules.

But that is all no problem if the user consented to store the data on a
public server (for example by means of a warning dialog). There are
other exceptions as well, for example the legal requirement to protect
the communication can be be viewed as an exception for an explicit
consent. This is why some mail providers only allow the mail address as
user ID in a key because that is the only technically required part of
the user id (see the long standing German principle of
Datensparsamkeit).


Shalom-Salam,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: recommendation for key servers [ In reply to ]
Am 27.06.2021 um 13:04 schrieb Werner Koch via Gnupg-devel:
> But that is all no problem if the user consented to store the data
> on a public server (for example by means of a warning dialog).

Actually right now, you can upload any public-key from anyone, at least
on https://keys.openpgp.org/upload and https://pgp.mit.edu/ (without a
GPDR message, just some terms of use or FAQ).

So maybe sign the contenting process using the private key in future?

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: recommendation for key servers [ In reply to ]
Hi Werner,

> I can only repeat that stripping the User-ID from a key is Bad Thing

I've actually never seen this argument in full. I just checked T4393 again, the
only explanation you give is "to avoid problems we had with PGP2". Would you
care to elaborate?

> The pleaded GDPR issue is artificial

IIRC Kristian very much doesn't believe in the GDPR, and yet he *just*
discontinued the pool because it caused him too much GDPR legal trouble, which
is a direct consequence of SKS publishing email addresses without explicit
consent. Perhaps I'm misunderstanding what you are describing as "artificial"?

> and entirely ignores the fact that the key or its fingerprint is as well
> personal data (“any information which [is] related to an identified or
> identifiable natural person”) and thus subject to the GDPR rules.

I'm inclined to agree on this one, actually. :) Maybe I'll rephrase the privacy
policy of keys.o.o one of these days, but so far it worked out ok.

- V


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: recommendation for key servers [ In reply to ]
There are still SKS servers running, but several are unsynchronized, including, apparently, pgp.mit.edu. Of course, they have the same key import/poisoning problems already mentioned on these lists…

Here are the hockeypuck servers I could find, all synchronizing properly and apparently exchanging data (minus the unwanted packets) with the SKS servers that are synchronized:
http://keys.andreas-puls.de/pks/lookup?op=stats
http://keys2.andreas-puls.de/pks/lookup?op=stats
http://keys3.andreas-puls.de/pks/lookup?op=stats
http://pgp.cyberbits.eu/pks/lookup?op=stats
http://pgp.re:11371/pks/lookup?op=stats
https://pgpkeys.eu/pks/lookup?op=stats
https://keybath.trifence.ch/pks/lookup?op=stats
https://keyserver.trifence.ch/pks/lookup?op=stats
HTH. (Please excuse the HTML.)

Sent from my iPad

> On Jun 24, 2021, at 7:19 PM, deloptes via Gnupg-devel <gnupg-devel@gnupg.org> wrote:
>
> ?
> Hi, we heard that sks-keyservers.net will be depreciated
> so we were wondering what service we should use in the application default settings
> We I mean TDE devs
>
> where do we go from here?
>
> thank you in advance
> BR
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: recommendation for key servers [ In reply to ]
On 28/06/2021 00:41, Jason Harris via Gnupg-devel wrote:
>
> Here are the hockeypuck servers I could find, all synchronizing properly
> and apparently exchanging data (minus the unwanted packets) with the SKS
> servers that are synchronized:
>
> * http://keys.andreas-puls.de/pks/lookup?op=stats
> * http://keys2.andreas-puls.de/pks/lookup?op=stats
> * http://keys3.andreas-puls.de/pks/lookup?op=stats
> * http://pgp.cyberbits.eu/pks/lookup?op=stats
> * http://pgp.re:11371/pks/lookup?op=stats
> * https://pgpkeys.eu/pks/lookup?op=stats
> * https://keybath.trifence.ch/pks/lookup?op=stats
> * https://keyserver.trifence.ch/pks/lookup?op=stats

To these you can add:

* https://east.keyserver.us (stats page is misleading; it does sync)
* https://west.keyserver.us
* https://keyserver.dobrev.eu (down right now, but is normally reliable)
* https://openpgp.circl.lu (stats page is misleading; it does sync)
* https://keyserver.snt.utwente.nl

> HTH.  (Please excuse the HTML.)

De-HTMLified. ;-)

--
Andrew Gallagher
Re: recommendation for key servers [ In reply to ]
On 25/06/2021 16:29, deloptes via Gnupg-devel wrote:
>
> So to put it short in the future there will be no openpgp server(s)
> because of the GDRP?

I wouldn't go that far, but GDPR does pose technical challenges - many
of which were already known.

> I was wondering who is objecting the existence of the SKS server. In the
> mail thread (from 2018) and the message from this month, it says only
> about more and more complains.
Anyone making a data deletion request under GDPR should not have their
email address widely shared, so we do not (and should not) know the
details of who has been contacting Kristian directly.

> Could it be potential attack on the opengpg community - I could not
> follow until the end. Can you summarize who and how took the decision to
> take this server down?

Kristian has been running sks-keyservers.net by himself for quite some
time as a service to the community. Progressively more software is using
keys.openpgp.org by default, so the cost/benefit ratio of keeping
sks-keyservers.net alive has changed. There have been sabotage attempts
against the keyserver network (malicious or misguided, it's not clear)
but we should not assume that people exercising their rights under data
protection law are in any way associated with those.

> Couple of years ago, I thought finally someone took care of GPG and did

> the right thing, so that one can have a single server, to look for and
> upload keys - now it seems it is over

You are probably thinking of keys.openpgp.org. It isn't the final answer
either, it just weighs its compromises differently...

--
Andrew Gallagher
Re: recommendation for key servers [ In reply to ]
"Hell is paved with good intention."

GDPR came from the laudable intention of limiting the power of GAFAMs
and other data brokers, inside our private lives.

But the text maintains a confusion between personal data and private
data. Some personal data is not and should not be private. Email could
be one of them, if everyone used a web of trust, which would allow us to
know more precisely who is the sender, and to fight more effectively
against SPAM.

(NB: In addition, the text annoys small organizations more than large
groups which have the means to circumvent it, via internationalization
and lobbying)

I have a public email, and i would like to have a email service or
client which may delete automatically unsigned messages, and give me the
feature to order received email depending from a "proximity" regarding
the WOT, or a "confidence" regarding my trustdb.

About the keystore, I imagined 9 years ago that a key server receiving a
certificate update, not signed by its owner, could send a message to the
owner (by default 1 time per day), in order to ask it to validate, or
not, the modifications, before synchronizing the updated certificate,
signed by its owner, on other key servers.

So I had to write a draft and start implementing a new MIME type for
HTTP for these purposes, to upgrade HKP protocol :

https://github.com/Open-UDC/open-udc/blob/master/docs/rfc/HTTP_OpenPGP_Authentication.draft.txt

https://github.com/Open-UDC/thttpgpd

But unfortunately I was perhaps too shy to talk about these ideas on an
international mailing list, and they received little echo in my French
environment :

https://linuxfr.org/users/jbar/journaux/thttpgpd-ou-comment-openudc-a-ressuscite-le-bon-vieux-thttpd


Today WKD / WKS seems to me a good compromise for the trilemma keystore,
and probably the best way to get the last version of
"first-party-attested" certificates, which fresh uid / sub-keys updates
and revocations.

But it's only today that I discovered your git repository
https://gitlab.com/openpgp-wg/rfc4880bis and your idea of
??"first-party-attested third-party certifications" (1pa3pc).

I therefore apologize if I do not add anything new or interesting to the
debate today.

----
Jean-Jacques B.


Le 28/06/2021 à 01:41, Jason Harris via Gnupg-devel a écrit :
>
> There are still SKS servers running, but several are unsynchronized,
> including, apparently, pgp.mit.edu.  Of course, they have the same key
> import/poisoning problems already mentioned on these lists…
>
> Here are the hockeypuck servers I could find, all synchronizing
> properly and apparently exchanging data (minus the unwanted packets)
> with the SKS servers that are synchronized:
>
> * http://keys.andreas-puls.de/pks/lookup?op=stats
> * http://keys2.andreas-puls.de/pks/lookup?op=stats
> * http://keys3.andreas-puls.de/pks/lookup?op=stats
> * http://pgp.cyberbits.eu/pks/lookup?op=stats
> * http://pgp.re:11371/pks/lookup?op=stats
> * https://pgpkeys.eu/pks/lookup?op=stats
> * https://keybath.trifence.ch/pks/lookup?op=stats
> * https://keyserver.trifence.ch/pks/lookup?op=stats
>
> HTH.  (Please excuse the HTML.)
>
> Sent from my iPad
>
>> On Jun 24, 2021, at 7:19 PM, deloptes via Gnupg-devel
>> <gnupg-devel@gnupg.org> wrote:
>>
>> ?
>> Hi, we heard that sks-keyservers.net <http://sks-keyservers.net> will
>> be depreciated
>> so we were wondering what service we should use in the application
>> default settings
>> We I mean TDE devs
>>
>> where do we go from here?
>>
>> thank you in advance
>> BR
>> _______________________________________________
>> Gnupg-devel mailing list
>> Gnupg-devel@gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: recommendation for key servers [ In reply to ]
Am Freitag 25 Juni 2021 16:00:45 schrieb Andrew Gallagher via Gnupg-devel:
> Synchronising keyservers (SKS and Hockeypuck) are
> decentralised and universal but abuse-prone.

It seems possible to get the abuse-potential of synchronising keyservers unter
control. (While the abuse-potential of central and validating keyservers is
also there, but in a different are.)

I've outlined the concepts how this could be done here:
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

Preserving third party signatures distribution [Reiter 2019-07 b]
https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034394.html

Overall there has not been enough efforts going into preserving
the decentral network of public keyservers.

> Signature attestations will help tackle many of the abuse (and
> functional limitation) issues, if we can get them standardised

That is a possible puzzle piece of the solution.
(While I am not usre if it depends on standardisation.)

Best Regards,
Bernhard

--
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
Re: recommendation for key servers [ In reply to ]
On Sun, 27 Jun 2021 13:20, Tobias Wendorff said:

> So maybe sign the contenting process using the private key in future?

Casey Marshall wrote in the Hockeypuck 2.1 announcement [1]:

- Authenticated key management. This adds a couple of extra endpoints
which allow a key owner to replace and delete their key,
authenticated by signing the armored key in the request. This allows
a key owner to still update their own key once it has been inflated
beyond the key length limit.

Blacklists and auth key management may also be of interest to keyserver
operators subject to GDPR-related requests.

However there was not much followup on this. If there is something in
GnuPG we can do to support these features, we should do that sooner than
later.

In the meantime I will release 2.2.29 with the default keyserver changed
from the sks pool to the Ubuntu keyserver. I considered to use the
classic pgp.surfnet.nl server but that one would again require a
dedicated certificate which does not seem to be appropriate for
intermediate change of the default. I also considered several other
Hockeypuck servers but most of them return garbled OpenPGP keyblocks
which can't be used by GnuPG.


Shalom-Salam,

Werner


[1]
https://lists.gnupg.org/pipermail/gnupg-users/2020-December/064434.html
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: recommendation for key servers [ In reply to ]
On 29/06/2021 18:27, Werner Koch via Gnupg-devel wrote:
> I also considered several other
> Hockeypuck servers but most of them return garbled OpenPGP keyblocks
> which can't be used by GnuPG.

Hi, Werner.

Can you be more specific? Is this all keys on some keyservers, specific
keys on all servers? Is it reproducible?

--
Andrew Gallagher
Re: recommendation for key servers [ In reply to ]
Werner Koch via Gnupg-devel <gnupg-devel@gnupg.org> writes:

> On Sun, 27 Jun 2021 13:20, Tobias Wendorff said:
>
>> So maybe sign the contenting process using the private key in future?
>
> Casey Marshall wrote in the Hockeypuck 2.1 announcement [1]:
>
> - Authenticated key management. This adds a couple of extra endpoints
> which allow a key owner to replace and delete their key,
> authenticated by signing the armored key in the request. This allows
> a key owner to still update their own key once it has been inflated
> beyond the key length limit.
>
> Blacklists and auth key management may also be of interest to keyserver
> operators subject to GDPR-related requests.
>
> However there was not much followup on this. If there is something in
> GnuPG we can do to support these features, we should do that sooner than
> later.

I fear that the mechanism has not been very well designed. In short, I
believe it is not complete, not functional, and dangerous:

https://github.com/hockeypuck/hockeypuck/issues/136

Justus
Re: recommendation for key servers [ In reply to ]
On 29/06/2021 18:27, Werner Koch via Gnupg-devel wrote:
> In the meantime I will release 2.2.29 with the default keyserver changed
> from the sks pool to the Ubuntu keyserver.

I think a large part of the problem is having to decide on *the* default
keyserver. If it was possible to supply a list of preferred keyservers,
it would remove a single point of failure from the system.

--
Andrew Gallagher
Re: recommendation for key servers [ In reply to ]
On 29/06/2021 14:16, Bernhard Reiter wrote:
>
> It seems possible to get the abuse-potential of synchronising keyservers unter
> control. (While the abuse-potential of central and validating keyservers is
> also there, but in a different are.)
>
> I've outlined the concepts how this could be done here:
> 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

I think you meant to link to the previous message... ;-)

https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034388.html

The "permission-recording keyserver" as described here requires the
various keyserver operators to trust each other to validate these
permissions correctly. Technically, this could be done if the validating
keyserver signs the user IDs that it has personally checked, and each of
its peers verifies this third-party sig against their own trusted
keyservers list. But how this interplays with the sync process,
particularly with the subjectivity of trust relationships, gets tricky.

The use of arbitrary data in IDs is problematic; even IDs that validate
as "correct" email addresses can still be abused. I don't think we need
to solve all of these issues straight away, but some of the low hanging
fruit (e.g. UATs containing abusive images) could be eliminated very
quickly if we collectively agreed.

Deletion due to either RTBF or abusive behaviour is possible through
blacklisting, as implemented now in Hockeypuck. This has knock-on
effects on sync (again due to subjectivity) but they are manageable for now.

I think the best way to approach user IDs is to think of keystores
(including keyservers, but also WKD, DANE etc) as performing two
separate functions: discovery and refresh. Discovery is a
human-to-machine operation that finds key material and certifications
based on the user ID, and refresh is a purely machine (and preferably
automated) operation that finds key material and certifications based on
the fingerprint.

The main reason we are having GDPR problems now is that the original
design of the PGP public key did not properly separate these functions.
At no point in any reasonable scenario do we need to find all user IDs
of a key based solely on knowing the fingerprint, nor do we ever need to
find a third-party sig made by a key that we do not already have or
trust. But the design encourages (and in some cases forces) us to bundle
all of this data together, effectively as a blob.

We need to unpick this, and work with much smaller atoms of key
material, bigger than packets but smaller than entire "public keys"
(such unfortunate terminology that we're now stuck with), so we can be
more selective about what we distribute in a given context.

> Preserving third party signatures distribution [Reiter 2019-07 b]
> https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034394.html

I think the third-party sig issues raised in this post are best tackled
with attestations, as discussed already. The trick is to get the
end-user workflow cleaned up and into as many clients as possible.

> Overall there has not been enough efforts going into preserving
> the decentral network of public keyservers.

I agree. I think hockeypuck and hagrid are approaching the same problem
from opposite ends - the optimum is somewhere in the middle, if we can
find it.

>> Signature attestations will help tackle many of the abuse (and
>> functional limitation) issues, if we can get them standardised
>
> That is a possible puzzle piece of the solution.
> (While I am not usre if it depends on standardisation.)

Wide adoption is the goal, and while I think standardisation can help
with that, it is not strictly necessary of course.

--
Andrew Gallagher
Re: recommendation for key servers [ In reply to ]
On Wed, 30 Jun 2021 12:18, Justus Winter said:

> I fear that the mechanism has not been very well designed. In short, I
> believe it is not complete, not functional, and dangerous:
>
> https://github.com/hockeypuck/hockeypuck/issues/136

Find below a copy of Justus' comment


Salam-Shalom,

Werner


===
teythoon commented 8 hours ago

I have grave concerns regarding the authenticated key replacement
mechanism as proposed by HIP-1 and implemented in current hockeypuck
versions. I believe it to be not complete, not functional, and
dangerous.

First, because it uses OpenPGP's detached signature mechanism, it
requires a signing-capable (sub)key. Therefore, the mechanism fails to
protect OpenPGP certificates without signing-capable (sub)key. The
solution is not complete.

Second, after a key has been replaced with a clean version, presumably
to get rid of a flood of certifications, an attacker can simply re-add
the certifications. The replacement mechanism does not assure
sovereignty, only a momentarily relief. Therefore, the solution is not
functional.

I haven't looked into how gossiping plays into that, but if gossiping
uses the same policy as updates using hkp, then gossiping will also
re-add any third party certifications.

Third, the pair of keytext and keysig are a capability to reset the copy
of the certificate on the server to keytext. If a malicious party ever
gets hold of such a pair, then they have the ability to remove updates
from the certificate stored on the server. Undoing an update that
extends the validity period of a certificate leads to an DoS because the
certificate can no longer be used (e.g. for encryption). Undoing an
update that revokes a key leads to a certificate being used even though
it shouldn't, compromising authenticity and confidentiality. Therefore,
I conclude that the mechanism is dangerous.


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: recommendation for key servers [ In reply to ]
On 27/06/2021 12:20, Tobias Wendorff wrote:
> So maybe sign the contenting process using the private key in future?

But this just states that the person in control of the private key
consents. This is not necessarily the person whose information is
contained in the UID.

--
Andrew Gallagher
Re: recommendation for key servers [ In reply to ]
Am Mittwoch 30 Juni 2021 19:35:25 schrieb Andrew Gallagher via Gnupg-devel:
> The "permission-recording keyserver" as described here requires the
> various keyserver operators to trust each other to validate these
> permissions correctly.

Not quite.
It is designed the other way around without "mandatory validation":
it allows for later opt-out or finding the party that publishes
unwanted information. So it can work at first try.

And email servers also do not trust each other fully, they just delegate
and assume some initial trust.

> Technically, this could be done if the validating
> keyserver signs the user IDs that it has personally checked, and each of
> its peers verifies this third-party sig against their own trusted
> keyservers list.

This comes with too much power for the "validating keyserver" to me.
My feeling is that this is unneeded.

Best Regards,
Bernhard

--
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
Re: recommendation for key servers [ In reply to ]
> On 13 Jul 2021, at 09:43, Bernhard Reiter <bernhard@intevation.de> wrote:
>
> ?Am Mittwoch 30 Juni 2021 19:35:25 schrieb Andrew Gallagher via Gnupg-devel:
>> The "permission-recording keyserver" as described here requires the
>> various keyserver operators to trust each other to validate these
>> permissions correctly.
>
> Not quite.
> It is designed the other way around without "mandatory validation":
> it allows for later opt-out or finding the party that publishes
> unwanted information. So it can work at first try.

If there is no cryptographic verification, then Mallory can trivially fake the recorded permissions, rendering the entire proposal pointless.

> And email servers also do not trust each other fully, they just delegate
> and assume some initial trust.

Yes, and this opened the spam floodgates, which is why DKIM had to be invented.

Speaking of which, perhaps we could piggyback the provenance verification on DKIM, since most public keyserver operators would presumably be admins of their own domains. That way we wouldn’t need to have a pre-approved list of “good” keyservers.

>> Technically, this could be done if the validating
>> keyserver signs the user IDs that it has personally checked, and each of
>> its peers verifies this third-party sig against their own trusted
>> keyservers list.
>
> This comes with too much power for the "validating keyserver" to me.
> My feeling is that this is unneeded.

Some form of spam prevention is needed, and I don’t see how that is possible without cryptographic verification of provenance. What form that takes is debatable.

A
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: recommendation for key servers [ In reply to ]
Am Mittwoch 14 Juli 2021 18:48:51 schrieb Andrew Gallagher via Gnupg-devel:
> If there is no cryptographic verification, then Mallory can trivially fake
> the recorded permissions, rendering the entire proposal pointless.

If one keyserver K has recorded permissions and you get a pubkey from this
server via TLS, then there is cryptographic verification that you've got this
permission from K. If someone comes running at you with justified or
unjustified legal claim, you can point them to K.

If you believe that the claim is legitimate, you may yourself record a
barring or permission and give that to other servers.

The decentral point here is: Your server has good reason to believe that users
have a change to get their right uphold, but if there are any legal
difference, which there will be between global spheres, you can live with it.

> > And email servers also do not trust each other fully, they just delegate
> > and assume some initial trust.

> Yes, and this opened the spam floodgates, which is why DKIM had to be
> invented.

I'll have to look this up further, but my understanding was that this is bound
to PKIX and domain records, it would verify a server not a single email
sender. Of course in a decentral world with pubkey-servers, those would
exchange pubkeys cryptographically secured, so you cannot fake that you've
gotten that pubkey (and its permission) from a different server.

Best Regards,
Bernhard

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