Re: [Sks-devel] Launching a new keyserver on keys.openpgp.org!

[Tom at FlowCrypt]

Thanks for the effort. I see keys can be retrieved as follows:
https://keys.openpgp.org/vks/v1/by-email/look@my.amazin.horse
https://keys.openpgp.org/vks/v1/by-fingerprint/D4AB192964F76A7F8F8A9B357BD18320DEADFA11

Are you also planning to add SKS-compatible endpoints over http? Eg:
https://keys.openpgp.org/pks/lookup?search=look@my.amazin.horse

Similar for uploading (after which you send your email verification). It
may help some users transition.

Is there any counter to see roughly how many keys are available?


On Wed, Jun 12, 2019 at 5:16 PM Vincent Breitmoser 
wrote:

>
> Hey sks-devel folks,
>
> the Hagrid team is pleased to announce the launch of our new keyserver,
> running
> at keys.openpgp.org!
>
> https://keys.openpgp.org
>
> Here's the short story:
>
> * Fast and reliable. No wait times, no downtimes, no inconsistencies.
> * Precise. Searches return only a single key, which allows for easy key
> discovery.
> * Validating. Identities are only published with consent, while
> non-identity information is freely distributed.
> * Deletable. Users can delete personal information with a simple e-mail
> confirmation.
> * Built on Rust, powered by Sequoia PGP - free and open source, running
> AGPLv3.
>
> Full news announcement:
> https://keys.openpgp.org/about/news#2019-06-12-launch
>
> Our primary motivation was to have a place where OpenPGP clients can
> reliably
> and quickly obtain updates to key material (subkeys, revocations, ...),
> and that
> also has as a simple and useful way of key discovery.
>
> Some of the things we do are a bit experimental. For some things we found
> that
> there is no good mechanism at this point, so we decided to drop them for
> now.
> Most notably this includes third party signatures on keys, because they in
> their
> current form the difficulties wrt privacy and spam outweigh their
> usefulness.
>
> The server implementation Hagrid (as in, "keeper of keys") is developed
> here:
> https://gitlab.com/sequoia-pgp/hagrid
> Feel free to file issues if you find anything out of place. Please read
> our FAQ
> first ;)
>
> Huge thanks to Kai for the initial implementation, Justus and Neal for
> creating
> Sequoia and working with me on this, dkg and Paul for testing and tons of
> feedback, Phil for providing us with the domain, and of course everyone who
> helped us test and polish this thing!
>
> Happy to hear your feedback!
>
>  - V
>
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

[Tom at FlowCrypt]

Robert,

No doubt it's risky to implement things that there is no consensus on. But
the device I'm writing this on was invented by *not a consensus*, and a
consensus to design it would not have emerged on this list nor elsewhere.

The risk may be lowered:

1) on behalf of our company I'm excited to run whatever not-sks testnode
you prototype

2) fwiw there's Hockeypuck written in a popular language and popular db.
The sks recon is separated into a module, and could be swapped out. All the
other bells and whistles of a ks are there.

3) find one more person and we can call it a test network

As an alternative to Hockeypuck, we also use a keyserver on the backend
written in Node/TypeScript and postgres that I'd be happy to strip/clean up
and contribute. It has no sync nor consensus built in. Based on OpenPGP.js.
I wrote it purely out of my frustration with sks.

I think this list needs resolute action, not consensus. Resolute action is
risky, sure.

My company will issue a modest grant to get a ball rolling on whatever is
not-sks, implemented by a person with a brain (you're overqualified!).

Cheers,
Tom


On Thu, 7 Feb 2019, 08:46 Robert J. Hansen  > It is no use to wait a great consensus.
>
> Without exception, I have never met someone who was reluctant to
> volunteer someone else's time.  I think this is unfortunate.  I'd rather
> we were as reluctant to urge other people to commit their time and
> effort to a project as we are to commit our own.
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

[Tom at FlowCrypt]

> Does anyone in the pool run hockeypuck? How compatible is its recon with
others running sks-keyserver?

Yes, here is one: http://keyserver.snt.utwente.nl

(see https://sks-keyservers.net/status/ and
http://keyserver.snt.utwente.nl:11371/pks/lookup?op=stats )

However, it was kicked out of the pool because "SKS version < 1.1.6" as per
https://sks-keyservers.net/status/ks-status.php?server=keyserver.snt.utwente.nl

It does seem to be syncing well - key diff 1,385 looks great to me even
compared to servers that are in the pool.

I'm adding Robert in copy in case he's able to share his experience running
the Hockeypuck server. Robert, if this email can reach you, We'd be
interested to know how is the server coping with recent issues that were
affecting the SKS network? How stable do you find Hockeypuck overall, how
much dev-ops do you need to do?




On Sun, Jul 15, 2018 at 1:21 AM, Haw Loeung 
wrote:

> On Sun, Jul 15, 2018 at 11:17:20AM +1000, Haw Loeung wrote:
> > On Fri, Jul 13, 2018 at 07:53:01PM +0100, Andrew Gallagher wrote:
> > > I am still willing to help with possible upgrades and/or
> > > replacements for the SKS network. At this point I have come to
> > > believe that a minimal network containing only key material, SBINDs
> > > and revocations (no id packets, no third party sigs) is the absolute
> > > maximum functionality we can hope to sustain in the long term. And
> > > for this to be bulletproof, all such material must be
> > > cryptographically verified (otherwise people could just create
> > > “random” key material containing arbitrary data).
> >
> > If it helps others, we have a patched SKS packaged to exclude the bad
> > key (one of them at least)[1]. A couple of others in my team did all
> > the work so I can't comment on the details.
> >
>
> I should also add, you'll then need to drop the key from the DB with:
>
> $ sks drop 8C070D00D81E934B3C79247175E6B4BC
>
>
> Regards,
>
> Haw
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Tom at FlowCrypt]

> How do you propose to validate the email address?

I'm using a library to parse the uid as email, name and a comment. For the
email, I'm using a very, very long regex. Of the 5M keys available in SKS
dumps, very few uids are miscategorized.

It may be hard to do with 100% accuracy, but it's unsurprisingly easy do
well enough.


On Sat, Jul 14, 2018, 18:37 Robert J. Hansen  wrote:

> > Then let's drop keys that don't contain a valid email address in the key
> id.
>
> How do you propose to validate the email address?
>
> (Hint: this is a surprisingly hard problem.)
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Tom at FlowCrypt]

> Is it possible without facing a user revolt?  No.

SKS does do key parsing though, and we could surely figure out just how big
the photo-id is in bytes. I suggest to impose a limit. Does it really need
to be any bigger than 10kB? My suggestion:

- impose a 10kB image size limit
- max one image per key
- max 20 uids per key
- max 1kb length per uid



On Sat, Jul 14, 2018 at 3:37 AM, Robert J. Hansen 
wrote:

> > IMHO Photo-ID should be dropped entirely, I see no point and its just
> > ripe for abuse like this..
>
> Unfortunately, we really can't.  They've been part of OpenPGP
> certificates for just about twenty years now.  They are an expected part
> of the certificate.  Users already scream bloody murder about GnuPG and
> Enigmail dropping support for SE packets and those have been deprecated
> since 2003.  The idea of just waving a wand and getting rid of a
> non-deprecated part of a public key is just ... no.
>
> Is it technically possible?  Yes.  But it would require a significant
> amount of redesign: we'd have to parse out the key, recognize images,
> drop them, etc.  Right now SKS does *zero* cryptographic verification of
> the key data; we'd need to change SKS to introduce at least some crypto
> support.
>
> Is it possible without facing a user revolt?  No.
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Tom at FlowCrypt]

> that would probably be an incomplete mitigation:

Sounds better than no solution!

> -people can use the photo id field instead

Size limit can be enforced.

> -people can use valid e-mail addresses under an own domain ("catch-all")

As long as it can validate, seems fine to me. Better than no verification.

> -your keyserver suddenly can be abused for email spamming

Any online service that allows registrations can be abused for email
spamming, if you consider registration emails an "email spam".



Another limitation: you cannot apply the email verification process to the
recon algo, because the user would get flooded with verification emails.
That means you could have a malicious SKS implementation flooding others
with non-verified emails. Again, not perfect, but a good start.



On Sat, Jul 14, 2018 at 2:50 AM, Tobias Frei 
wrote:

> Hi Ryan,
>
> that would probably be an incomplete mitigation:
>
> -people can use the photo id field instead
> -people can use valid e-mail addresses under an own domain ("catch-all")
> -your keyserver suddenly can be abused for email spamming
>
> Best regards
> Tobias Frei
>
>
>
> Am 14.07.2018 um 02:57 schrieb Ryan Hunt:
>
>> Could this be mitigated by validating email addresses as they come in?
>> Like sending an encrypted mail to the said address with a return token, If
>> the token is not provided the key is never put into the SKS rotation?
>>
>> I think a solution like this would be much more effective, and if there
>> was some desire to conform to GDPR at some point it would be pretty much
>> required first step because I cannot see how we could possibly remove keys
>> without a command signed by that key, and putting this in place would make
>> that ‘no more difficult to remove than it was to add’..
>>
>> Regards,
>> -Ryan Hunt
>>
>> On Jul 13, 2018, at 11:20 AM, Phil Pennock 
>>> wrote:
>>>
>>> Signed PGP part
>>> Heads-up:
>>>
>>> https://medium.com/@mdrahony/are-pgp-key-servers-breaking-th
>>> e-law-under-the-gdpr-a81ddd709d3e
>>> https://github.com/yakamok/keyserver-fs
>>> https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under
>>>
>>> This `keyserver-fs` is software to attack SKS, using it as a filesystem,
>>> in
>>> what appears to be a deliberate attack on the viability of continuing to
>>> run a keyserver.
>>>
>>> The author is upset that there's no deletion, so is pissing in the pool.
>>>
>>> -Phil
>>>
>>>
>>>
>>
>> ___
>> Sks-devel mailing list
>> Sks-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>>
>>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

[Tom at FlowCrypt]

I would have loved to write an alternative SKS implementation that
addresses the issues we were seeing recently. However, this:

   - Set Reconciliation with Nearly Optimal Communication Complexity
   
   - Practical Set Reconciliation
   


is preventing me from doing so. I'm a software engineer, not a
mathematician, and I have little willingness to attempt implementing an
algorithm nobody understands.

I wish the title said "simple" and "resilient" rather than "with nearly
optimal communication complexity", and the contents matched the title.

The pool of engineers willing and able to get us out of this mess would be
much larger.

On Fri, Jul 13, 2018 at 11:23 PM, Andrew Gallagher 
wrote:

>
> > On 13 Jul 2018, at 22:43, Moritz Wirth  wrote:
> >
> > FWIW, has anybody even started working on a fix for any of the bugs?
>
> There has been a fair bit of discussion, but no consensus has been
> reached, apart from a general agreement that major changes to the recon
> model will be required, and that these will be necessarily
> backwards-incompatible. That’s generally where the discussion dries up.
>
> I get the impression that everyone is holding fire until there is some
> sign that one particular form of breakage will be more broadly acceptable
> than the others.
>
> A
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] disk full, keys.niif.hu crashed

[Tom at FlowCrypt]

I should have added, DB_LOG_AUTOREMOVE should probably be a default, too.

Whatever makes the servers more likely to survive out in the wild.

On Sat, Jun 16, 2018 at 6:34 PM, Tom at FlowCrypt  wrote:

> I think there should be a default setting on all installations with a
> clear max key size.
>
> 8M is a good start, 1M is even better. 1MB well generous enough for a
> public key.
>
> As a user, I shouldn't need to do download megabytes of fluff for every
> person I want to message.
>
> I propose that we set and enforce max size by default.
>
> On Sat, Jun 16, 2018 at 4:32 PM, Paul Furley  wrote:
>
>> Alternatively, we can view this as a great opportunity to improve the
>> resilience of this critical infrastructure.
>>
>> This is a serious, serious flaw... I'm grateful to the individual for
>> taking the time to research and highlight this issue. Sure, not ideal that
>> the network is struggling as a result, but at least we'll have to find a
>> way to fix it!
>>
>> Paul
>>
>>
>>   Original Message
>> From: andr...@andrewg.com
>> Sent: 16 June 2018 4:02 pm
>> To: sks-devel@nongnu.org
>> Subject: Re: [Sks-devel] disk full, keys.niif.hu crashed
>>
>> On 2018/06/15 22:42, tiker wrote:
>> > Well, it turns out that the cause of our issues, the method to re-create
>> > these keys and make things worse is already posted publicly.
>>
>> There are two main ways in which critical internet infrastructure goes
>> on fire: a government TLA takes it down for nefarious purposes, or some
>> random gobshite sets it ablaze as an experiment.
>>
>> The history of the internet shows that it is almost always the latter.
>>
>> A
>> ___
>> Sks-devel mailing list
>> Sks-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>> ___
>> Sks-devel mailing list
>> Sks-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>>
>
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] disk full, keys.niif.hu crashed

[Tom at FlowCrypt]

I think there should be a default setting on all installations with a clear
max key size.

8M is a good start, 1M is even better. 1MB well generous enough for a
public key.

As a user, I shouldn't need to do download megabytes of fluff for every
person I want to message.

I propose that we set and enforce max size by default.

On Sat, Jun 16, 2018 at 4:32 PM, Paul Furley  wrote:

> Alternatively, we can view this as a great opportunity to improve the
> resilience of this critical infrastructure.
>
> This is a serious, serious flaw... I'm grateful to the individual for
> taking the time to research and highlight this issue. Sure, not ideal that
> the network is struggling as a result, but at least we'll have to find a
> way to fix it!
>
> Paul
>
>
>   Original Message
> From: andr...@andrewg.com
> Sent: 16 June 2018 4:02 pm
> To: sks-devel@nongnu.org
> Subject: Re: [Sks-devel] disk full, keys.niif.hu crashed
>
> On 2018/06/15 22:42, tiker wrote:
> > Well, it turns out that the cause of our issues, the method to re-create
> > these keys and make things worse is already posted publicly.
>
> There are two main ways in which critical internet infrastructure goes
> on fire: a government TLA takes it down for nefarious purposes, or some
> random gobshite sets it ablaze as an experiment.
>
> The history of the internet shows that it is almost always the latter.
>
> A
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel