Mailing List Archive

How do you handle the gradual degradation of sync as different operators
implement divergent blacklists?

A

On 10/12/2020 17:07, Casey Marshall wrote:
> I've released Hockeypuck 2.1.0
> <https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0> [0], which
> contains several new features that may be useful to mitigate
> spamming/flooding/DoS [1] attacks on GnuPG and keyservers. See the
> release link for details, but here's the highlights:
>
> * Configurable key length and packet size limits, with sensible
> defaults to limit keyserver resource consumption (1MB and 8K
> respectively).
> * Configurable blacklist of primary key fingerprints.
> * 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.
>
>
> -Casey
>
>
> [0] https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0
> <https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0>
>
> [1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
> <https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f>
>


--
Andrew Gallagher

On Thu, 10 Dec 2020 11:07, Casey Marshall said:

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

Finally after more than 20 years waiting for someone to implement such a
feature. Yeah. Where can I find the specs?

Did you consider that an authenticated request to delete a key may not
actually remove the key from the keyserver? Instead the the primary key
should be kept and the server prepared to receive and merge even
unauthenticated revocation certificates. This is important in case of a
lost key (or passphrase forgotten) so that a pre-created revocation
certificate can be uploaded. Also avoids DoS after a key compromise.

> Blacklists and auth key management may also be of interest to keyserver

Still revocation certificates should get through. At least the first
valid revocation certificate needs to be handles before the key can be
set into an eternal non-modifiable state.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On Fri, Dec 11, 2020 at 10:25 AM Werner Koch <wk@gnupg.org> wrote:
>
> On Thu, 10 Dec 2020 11:07, Casey Marshall said:
>
> > - 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
>
> Finally after more than 20 years waiting for someone to implement such a
> feature. Yeah. Where can I find the specs?
>
> Did you consider that an authenticated request to delete a key may not
> actually remove the key from the keyserver? Instead the the primary key
> should be kept and the server prepared to receive and merge even
> unauthenticated revocation certificates. This is important in case of a
> lost key (or passphrase forgotten) so that a pre-created revocation
> certificate can be uploaded. Also avoids DoS after a key compromise.

Hi Werner and Casey,

I have a question for both of you.

When I reported a while ago on GitHub about a fake uat packet on Werner's
key you quickly fixed the issue and the added image of 'Donnie' no longer
showed up at the Ubuntu keyserver. Interestingly now GitHub shows zero
issues as of today, while yesterday still some issues where open and a lot
of them closed.

Now my second question how is/was this done with Werner's key?

SKS still shows Werner's key with signatures, while the Ubuntu keyserver
shows only a very small key now. Before that the Ubuntu key server showed
the sigs too and additionally the fake uat packet (Donnie image).

Does this mean that a GnuPG user can modify his key in such a way
and re-submit it, so that the result is now like Werner's key or can a
Hockerpuck operator do this (on behalf) of the key owner? The key
in question, on the Ubuntu keyserver has also no longer a UID, which
I thought only sequoia-pgp can handle and not GnuPG.

https://keyserver.ubuntu.com/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630&fingerprint=on&op=vindex

http://keys2.andreas-puls.de:11371/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630&fingerprint=on&op=vindex

Regards
Stefan

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

>
> Date: Fri, 11 Dec 2020 17:56:24 +0000
> From: Stefan Claas <spam.trap.mailing.lists@gmail.com>
> To: Casey Marshall via Gnupg-users <gnupg-users@gnupg.org>,
> sks-devel@nongnu.org, Casey Marshall <casey.marshall@gmail.com>
> Subject: Re: [Keyserver] Hockeypuck 2.1.0 released
> Message-ID:
> <
> CAC6FiZ6EPR-eUD0AzMCVz7m4c9Hxga1iSfG7jSC2HXwsOvFmWA@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> On Fri, Dec 11, 2020 at 10:25 AM Werner Koch <wk@gnupg.org> wrote:
> >
> > On Thu, 10 Dec 2020 11:07, Casey Marshall said:
> >
> > > - 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
> >
> > Finally after more than 20 years waiting for someone to implement such a
> > feature. Yeah. Where can I find the specs?
> >
> > Did you consider that an authenticated request to delete a key may not
> > actually remove the key from the keyserver? Instead the the primary key
> > should be kept and the server prepared to receive and merge even
> > unauthenticated revocation certificates. This is important in case of a
> > lost key (or passphrase forgotten) so that a pre-created revocation
> > certificate can be uploaded. Also avoids DoS after a key compromise.
> Hi Werner and Casey,
> I have a question for both of you.
> When I reported a while ago on GitHub about a fake uat packet on Werner's
> key you quickly fixed the issue and the added image of 'Donnie' no longer
> showed up at the Ubuntu keyserver. Interestingly now GitHub shows zero
> issues as of today, while yesterday still some issues where open and a lot
> of them closed.
>

Hockeypuck has several issues still open on Github:
https://github.com/hockeypuck/hockeypuck/issues


> Now my second question how is/was this done with Werner's key?
> SKS still shows Werner's key with signatures, while the Ubuntu keyserver
> shows only a very small key now. Before that the Ubuntu key server showed
> the sigs too and additionally the fake uat packet (Donnie image).
> Does this mean that a GnuPG user can modify his key in such a way
> and re-submit it, so that the result is now like Werner's key or can a
> Hockerpuck operator do this (on behalf) of the key owner? The key
> in question, on the Ubuntu keyserver has also no longer a UID, which
> I thought only sequoia-pgp can handle and not GnuPG.
>
> https://keyserver.ubuntu.com/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630&fingerprint=on&op=vindex
>
> http://keys2.andreas-puls.de:11371/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630&fingerprint=on&op=vindex


The fix to this issue was to have Hockeypuck remove all packets lacking a
currently-valid self-signature from responses. This removes fake packets
(like the uat example) as well as expired identities. The self-signature on
the UID packet in your example expired 2008-12-31, so it (and all of its
third-party signatures) are pruned from the response. Only the public key
packet remains.


> Regards
> Stefan

On Mon, Dec 14, 2020 at 5:24 PM Casey Marshall via Gnupg-users
<gnupg-users@gnupg.org> wrote:
>> [...]

> The fix to this issue was to have Hockeypuck remove all packets lacking a currently-valid self-signature from responses. This removes fake packets (like the uat example) as well as expired identities. The self-signature on the UID packet in your example expired 2008-12-31, so it (and all of its third-party signatures) are pruned from the response. Only the public key packet remains.

Thanks for the information, much appreciated!

Regards
Stefan

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