"SKS is effectively running as end-of-life software at this point"?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

"SKS is effectively running as end-of-life software at this point"?

Steffen Kaiser
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I picked up this sentence here on the list in a thread about poison
key(s):

"> Any chance that sks will be fixed some day?

"Short answer, no. SKS is effectively running as end-of-life software at
this point. It gets emergency bugfixes but little else. The improvements
you are talking about would require an enormous refactoring of the
codebase, likely requiring migration to a different database engine.
Given that there are fundamental design flaws (poison keys) that aren't
getting fixed, performance issues just aren't on the radar. Sorry."

Is it meant litterally? The current SKS project is end of life and,
effectively, we have to look into another direction? Other software, new
fork with rewrite?

Kind regards,

- --
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBXFrc6iOjcd6avHZPAQI8iAgAhMVSiTvPdMARX20Kqkt7BQAIFwcnqi/K
GncegVdHZqf6PkyogVwXxMDxExOm+dJmkyJDD8IOsc6SQW+Tx7YDOcTynLsvFPQ9
NjehfxC6+O0Himxr1AAm75HZ3oU82e9GMteebbbyLc2pr0ggx7BNtIf81YjCwzxy
clLLCLZOCb8HAuXBYGi0X7z0iD9511nWQ6vbbpNEuTdz4rv/Fsvgre6SMQ8blYS6
mYlCsSv8AoL3vFux3E+8gsDUn/uOFzdvL+W6Ei5ETMd4zt4OVfyuGX/P1SBEGl+5
7Wfo3ev7F7ZaY7cJy1aOfF9lTKNF8Fuweq+wvBCnhL1B3dLuZ8Gqjw==
=Id3h
-----END PGP SIGNATURE-----

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

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

Tobias Frei
Hi, 

Isn't Mozilla Thunderbird in a similar state? I'm still happily using it *because* it has reached a point where further updates are rarely needed. 

Best regards
Tobias Frei

On Wed, Feb 6, 2019, 14:22 Steffen Kaiser <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I picked up this sentence here on the list in a thread about poison
key(s):

"> Any chance that sks will be fixed some day?

"Short answer, no. SKS is effectively running as end-of-life software at
this point. It gets emergency bugfixes but little else. The improvements
you are talking about would require an enormous refactoring of the
codebase, likely requiring migration to a different database engine.
Given that there are fundamental design flaws (poison keys) that aren't
getting fixed, performance issues just aren't on the radar. Sorry."

Is it meant litterally? The current SKS project is end of life and,
effectively, we have to look into another direction? Other software, new
fork with rewrite?

Kind regards,

- --
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBXFrc6iOjcd6avHZPAQI8iAgAhMVSiTvPdMARX20Kqkt7BQAIFwcnqi/K
GncegVdHZqf6PkyogVwXxMDxExOm+dJmkyJDD8IOsc6SQW+Tx7YDOcTynLsvFPQ9
NjehfxC6+O0Himxr1AAm75HZ3oU82e9GMteebbbyLc2pr0ggx7BNtIf81YjCwzxy
clLLCLZOCb8HAuXBYGi0X7z0iD9511nWQ6vbbpNEuTdz4rv/Fsvgre6SMQ8blYS6
mYlCsSv8AoL3vFux3E+8gsDUn/uOFzdvL+W6Ei5ETMd4zt4OVfyuGX/P1SBEGl+5
7Wfo3ev7F7ZaY7cJy1aOfF9lTKNF8Fuweq+wvBCnhL1B3dLuZ8Gqjw==
=Id3h
-----END PGP SIGNATURE-----

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

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

Andrew Gallagher
In reply to this post by Steffen Kaiser
On 06/02/2019 13:11, Steffen Kaiser wrote:
> Is it meant litterally? The current SKS project is end of life and,
> effectively, we have to look into another direction? Other software, new
> fork with rewrite?

I said "effectively", not literally. And I was in a grumpy mood that
day. But I stand by my point about design flaws not getting the
attention they deserve. You don't need to fork the codebase to make
improvements, but you do need to redesign the protocol to be
abuse-resistant, which is a Very Hard Problem. If we had some consensus
on the way forward it would be a good start.

--
Andrew Gallagher


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jeremy T. Bouse
On 2/6/2019 11:26 AM, Andrew Gallagher wrote:

> On 06/02/2019 13:11, Steffen Kaiser wrote:
>> Is it meant litterally? The current SKS project is end of life and,
>> effectively, we have to look into another direction? Other software, new
>> fork with rewrite?
> I said "effectively", not literally. And I was in a grumpy mood that
> day. But I stand by my point about design flaws not getting the
> attention they deserve. You don't need to fork the codebase to make
> improvements, but you do need to redesign the protocol to be
> abuse-resistant, which is a Very Hard Problem. If we had some consensus
> on the way forward it would be a good start.

If only it were open-source software and individuals with the extra time
and talent to work on those design flaws were able to do so. Wouldn't
that be a great world to live in?


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

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

Robert J. Hansen-3
> If only it were open-source software and individuals with the extra time
> and talent to work on those design flaws were able to do so. Wouldn't
> that be a great world to live in?

Wouldn't it be great if people were to think before snarking?

There are a handful of people with the background and skills to write a
next-generation keyserver.  I looked into it a dozen years ago and wrote
up a whitepaper on it.  I know Phil Pennock has put a lot of thought
into it.  Andrew, likewise.  There are easily five or six people on this
list who have the time and ability.

What we don't have is *consensus* -- not only among ourselves, but in
the larger community.

Let's say I decide to implement my whitepaper from 2007.  It would take,
oh, call it 200 hours of work to implement.  So I write it, put it out
there, and nothing happens because there's no consensus my idea is the
direction we should go.

The problem here is not a lack of manpower or skill.

It's a lack of community consensus on what a redesign should look like.



_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (837 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Matthew Walster-2


On Wed, 6 Feb 2019, 20:28 Robert J. Hansen <[hidden email] wrote:

It's a lack of community consensus on what a redesign should look like.

And, might I add, the desire for our efforts not to be ruined by others "proving a point" rather than actors actually seeking malicious intent.

I've abandoned my keyserver, and only advertise my keys as a pointer in DNS to download it via http.

M

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

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

robots.txt fan
In reply to this post by Robert J. Hansen-3
On Wednesday, February 6, 2019 8:28 PM, Robert J. Hansen <[hidden email]> wrote:
> It's a lack of community consensus on what a redesign should look like.

That can be changed. I do not know anything about the source code of this project, so forgive my naivety.

Is it possible to develop a keyserver thar uses the same interface as the current one? Meaning that GnuPG-Clients don't need to change and current keyservers can recon with the new keyservers (since they are not all upgraded simultaniously)?

Of course, that while also being able to not accept large keys. A first step might be limiting UIDs to a certain size, but then one could just generate lots of UIDs, or if you also limit the number of UIDs per key, they could generate lots of keys.

Furthermore, what would be nice if content could be deleted. I'm thinking about GDPR requests from people who do not want their data online anymore, or illegal content coded into UIDs or User Attribute Packets. Perhaps this can be implemented through a blacklist of fingerprints that synchronises.

Are there any more problems that need to be fixed? Like seriously, everyone please write the problems they have with SKS.

To answer my first question, I guess that it is possible to implement a keyserver with the same interface for GPG users that can still recon with older servers. The older servers might try to send them keys that are on the blacklist or are large, but the new server can reject those keys of course.

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

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

Andrew Gallagher

> On 6 Feb 2019, at 23:15, robots.txt fan <[hidden email]> wrote:
>
> To answer my first question, I guess that it is possible to implement a keyserver with the same interface for GPG users that can still recon with older servers. The older servers might try to send them keys that are on the blacklist or are large, but the new server can reject those keys of course.

Easier said than done. There is plenty of discussion in the archives about how difficult this would be technically. Because you can reject a key, but then what happens is it just keeps trying to come back. Pretty soon there are so many rejected keys floating around that the network stops reconciling. Also, what happens if I reject certain keys and you don’t, but your only connection to the rest of the network is through me? Once nodes start implementing different policies you can go split-brain surprisingly easily.

It’s not a simple matter of just coding it up.

A

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

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

Martin Dobrev
In reply to this post by Robert J. Hansen-3

Hi

On 06/02/2019 19:28, Robert J. Hansen wrote:
If only it were open-source software and individuals with the extra time
and talent to work on those design flaws were able to do so. Wouldn't
that be a great world to live in?
Wouldn't it be great if people were to think before snarking?

There are a handful of people with the background and skills to write a
next-generation keyserver.  I looked into it a dozen years ago and wrote
up a whitepaper on it.  I know Phil Pennock has put a lot of thought
into it.  Andrew, likewise.  There are easily five or six people on this
list who have the time and ability.
I'm glad to see from server operator perspective that there is a will to invest time in developing the server.

What we don't have is *consensus* -- not only among ourselves, but in
the larger community.

Let's say I decide to implement my whitepaper from 2007.  It would take,
oh, call it 200 hours of work to implement.  So I write it, put it out
there, and nothing happens because there's no consensus my idea is the
direction we should go.

The problem here is not a lack of manpower or skill.

It's a lack of community consensus on what a redesign should look like.

Is there a place where white-papers and draft proposals can be found? I remember seeing proposals to change the backend database with something that supports transactions, the likes of postgresql or mysql. Without it multi-threaded server is not possible. If I had the knowledge of OCAML I'd start like immediately a fork and implement it in order to save disk space and more important cut on redundant Iops. Nearly 21K keys have been added for the past month. Looking at the graph again I don't see a single plunge just steady growth. As it stands I'm running two physical servers with four Docker containers each that take approximately 95GB. Even with a single-thread server implementation I can still run multiple containers with a shared database, isn't it?

I agree redesign is inevitable if we want to address legislation changes like GDPR for example. A lot of servers in Europe ceased operation because of it. Today I read the news that criminals are using block-chain network to upload child abuse photos. According to UK law hosting such content can lead to large convictions. I don't want to be forced to stop my clusters if criminals exploit the photo field in the protocol. In my opinion there must be a way to remove content that's not legal from the network.

The way I see this happening is by introducing blacklists that a) prevent a key from being fetched during recon and b) delete the local copy of it. Is this a censorship?! For what I know some of us are already using blacklists to mitigate the poison key issues, the very least I am.

Building upon the previous suggestion I'm actually envisioning different types of blacklists in terms of legislation framework they comply with. Subdomains like <blacklist>.pool.sks-keyservers.net can be introduced as well. Then individual keyserver operators can configure what blacklists to use. A public register will keep the audit trail justifying every blacklist entry and used as a seed for the servers in the network. And before you ask who's going to be responsible for keeping that register up-to-date and accurate I have an answer for you - the very same law enforcement agencies that in the very first place demanded that we remove content from the network.

That being said I believe these changes will make the network a safer place not just for the operators but the users as well. That's something, I think, we as community can easily achieve consensus upon.

Sadly I don't have a  solution for the recent poison key issues that opened this thread in first place. We eventually need a brand new RFC that will define the next-gen server architecture.



_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Robert J. Hansen-3
In reply to this post by robots.txt fan
> Is it possible to develop a keyserver thar uses the same interface as
> the current one?

Sort of.

> Meaning that GnuPG-Clients don't need to change

Yes.

> and current keyservers can recon with the new keyservers (since they
> are not all upgraded simultaniously)?

No.  Keyserver reconciliation is 90% of the problem.  Fixing this would
make it impossible for older keyservers to reconcile with a next-gen design.

> Are there any more problems that need to be fixed? Like seriously,
> everyone please write the problems they have with SKS.

Please, *don't*.  We have had this discussion so many times over the
past ~15 years that I can't stand to go through it again.  Go through
the list archives, read those past discussions, and then if you come up
with anything new post it to the list.

> To answer my first question, I guess that it is possible to implement
> a keyserver with the same interface for GPG users that can still
> recon with older servers.

Let's not make this situation worse by guessing.


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (837 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Gabor Kiss
In reply to this post by Robert J. Hansen-3
> There are a handful of people with the background and skills to write a
> next-generation keyserver.  I looked into it a dozen years ago and wrote
> up a whitepaper on it.  I know Phil Pennock has put a lot of thought
> into it.  Andrew, likewise.  There are easily five or six people on this
> list who have the time and ability.
>
> What we don't have is *consensus* -- not only among ourselves, but in
> the larger community.
>
> Let's say I decide to implement my whitepaper from 2007.  It would take,
> oh, call it 200 hours of work to implement.  So I write it, put it out
> there, and nothing happens because there's no consensus my idea is the
> direction we should go.
>
> The problem here is not a lack of manpower or skill.
>
> It's a lack of community consensus on what a redesign should look like.

My 2 cents:
It is no use to wait a great consensus.

The working model of open source development is:

10 publishing a formal protocol description[1]
20 some peoples implement it
30 collecting experiments
40 years later other peoples write a different implemantation that
  is compatible with the original
50 GOTO 30

[1]: The famous paper describes the _algorithm_. A protocol description
writes bit-by-bit what is transferred on the wire, what to in case
of any errors, what must to do and what is optional etc. See RFCs.

If there would be _competing_ implementations operators could choose
which one they run. This is an evolution.
Remember Sendmail. 30-40 years ago it was virtually the only (non proprietary)
mail transfer agent (MTA). Eric Allman did a great job. But later other guys
had different ideas. Now there is a dozen MTAs on the market and almost
nobody uses Sendmail. But some do.
And all these programs can talk each to other due to RFC 821 (1982).

Gabor

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

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

Robert J. Hansen-3
> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (837 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

robots.txt fan
In reply to this post by Andrew Gallagher
On Thursday, February 7, 2019 12:37 AM, Andrew Gallagher <[hidden email]> wrote:
> Because you can reject a key, but then what happens is it just keeps trying to come back. Pretty soon there are so many rejected keys floating around that the network stops reconciling. Also, what happens if I reject certain keys and you don’t, but your only connection to the rest of the network is through me? Once nodes start implementing different policies you can go split-brain surprisingly easily.

I shouldn't have written "reject". If you already have this key in your blacklist, just tell the other keyserver that you already have it, but do not store it. Store only the hash.

Of course it might still be possible to code information into the hashes like Tobias wrote, but at least generating exactly the right hash is extremely expensive (if not impossible) from the attacker's perspective so I do not think it is feasible for them at all. Storing hashes of kryptonite should be okay.

> It’s not a simple matter of just coding it up.

Of course not, and I wouldn't dare claiming that. I agree with Martin in that I also am glad to see that there is a will to invest time in developing a new server. The Synchronising Key Servers should not vanish from earth.

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

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

Tom at FlowCrypt
In reply to this post by Robert J. Hansen-3
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 <[hidden email] wrote:
> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

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

Martin Dobrev
In reply to this post by robots.txt fan

On 07/02/2019 08:02, robots.txt fan wrote:
> On Thursday, February 7, 2019 12:37 AM, Andrew Gallagher <[hidden email]> wrote:
>> Because you can reject a key, but then what happens is it just keeps trying to come back. Pretty soon there are so many rejected keys floating around that the network stops reconciling. Also, what happens if I reject certain keys and you don’t, but your only connection to the rest of the network is through me? Once nodes start implementing different policies you can go split-brain surprisingly easily.
> I shouldn't have written "reject". If you already have this key in your blacklist, just tell the other keyserver that you already have it, but do not store it. Store only the hash.
>
> Of course it might still be possible to code information into the hashes like Tobias wrote, but at least generating exactly the right hash is extremely expensive (if not impossible) from the attacker's perspective so I do not think it is feasible for them at all. Storing hashes of kryptonite should be okay.

My idea for blacklists is in a sense similar - during recon process
consolidate hashes from the blacklists with whatever is in the live
database and report this to peers. This way it won't trigger continuous
*recon/fetch/drop due to blacklist* loops. There is only the risk that
downstream servers that don't use blacklists will keep asking not just
for the hash but the key too. This is something that can be mitigated in
the next-gen gossip protocol: server A asks for a key belonging to a
hash, it gets a response that server B is not actually having it due to
blacklist flag. Server A can ask another member from the membership pool
to provide the key. If all peers flag it as blacklisted set a flag and
give up retries until membership file changes.

Is this going to work? Most probably yes. Is it going to cause some
issues (see above) due to backwards compatibility in the short term -
yes, but then operators will be keen to upgrade to next-gen server
implementation and the problem gets solved in the long run.

>> It’s not a simple matter of just coding it up.
> Of course not, and I wouldn't dare claiming that. I agree with Martin in that I also am glad to see that there is a will to invest time in developing a new server. The Synchronising Key Servers should not vanish from earth.
>
> _______________________________________________
> Sks-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

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

Andrew Gallagher
In reply to this post by Robert J. Hansen-3
On 2019/02/06 23:51, Robert J. Hansen wrote:
> No.  Keyserver reconciliation is 90% of the problem.  Fixing this would
> make it impossible for older keyservers to reconcile with a next-gen design.

I have had a long think about this problem, and I reckon that the
biggest bar to progress is the assumption that arbitrary members of the
pool will upgrade to the new software at random, and that we need to
ensure that all nodes stay synchronised with each other no matter what
version they run, in a single mixed-version network.

We can simplify this problem considerably.

Instead of an operator upgrading their sks server to "new-sks" and
expecting to still be able to peer with traditional sks servers, they
should install the "new-sks" software *in parallel* with the traditional
one (on the same or a different machine, doesn't matter) and this
"new-sks" node should only be able to peer with other "new-sks" nodes.
This means that our new recon protocol can be efficient, because it
doesn't have to keep a record of blacklisted hashes.

If we further assume that key material does not flow back from the
"new-sks" network to the old one, then we can write a relatively simple
cron job that finds updated keys on an old-style sks server (by parsing
its logs, for example) and copies them (suitably censored) to the
corresponding "new-sks" server. At some point, when the "new-sks"
network is sufficiently stable, the pools are redefined and the old sks
network becomes irrelevant.

The above allows us to ignore broad categories of problematic material
by policy, simply by defining a narrow set of allowed packets in the new
protocol. Any compliant "new-sks" server will simply not be capable of
processing packets of unapproved types, e.g. image IDs, 3rd party
signatures, and keys with invalid self-sigs. Also, any peer that tries
to serve too many unapproved packets via recon can be twitted.

What the above will not do is allow individual operators to blacklist
arbitrary packets by hash, not without either some central authority
defining a shared blacklist, or a fake-recon process that maintains
local blacklist caches and runs the risk of split-brain. So the threat
of shutdown by court order is not completely removed.

I still think this may be enough to be getting started with.

A


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Andrew Gallagher
In reply to this post by Gabor Kiss
On 2019/02/07 05:35, Gabor Kiss wrote:
> And all these programs can talk each to other due to RFC 821 (1982).

Well, yes. A good protocol is everything. The implementation is
relatively easy. Ensuring that the protocol doesn't result in a cascade
failure is the Really Hard Problem. We're still trying to mitigate the
unintended side-effects of RFC821, 37 years after the fact... :-)

A


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Andrew Gallagher
In reply to this post by Martin Dobrev
On 2019/02/07 11:01, Martin Dobrev wrote:
> My idea for blacklists is in a sense similar - during recon process
> consolidate hashes from the blacklists with whatever is in the live
> database and report this to peers. This way it won't trigger continuous
> *recon/fetch/drop due to blacklist* loops.

I wrote a doorstop post on blacklist mechanisms some time back on this
list. The implementation planning is a rabbit-hole, and that's before
you even start thinking about higher-level problems like split-brain.
Eventual consistency is a harsh mistress. :-)

A


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Kristian Fiskerstrand-6
In reply to this post by Robert J. Hansen-3
On 2/6/19 8:28 PM, Robert J. Hansen wrote:
> What we don't have is *consensus* -- not only among ourselves, but in
> the larger community.

The current discussions we're having (e.g during OpenPGP email summit in
brussels in october and lately on FOSDEM last weekend) is eventually not
storing UIDs at all on the keyservers, but require the user to do key
discovery through WKD, directly on a website or the like. This still
allows using keyservers to distribute revocation certificates and
updates to subkeys etc, but not as a discovery mechanism.

Pool-wise it'd be setting up a separate keyserver network that  will
gossip with the existing network for a time, with separate pool for the
with-uid and without-uid servers, before the full switch is done...

The new network would be running on software replacing SKS, using more
suited database backend that and multi-threaded implementation. The
current disagreement are really with regards to whether this should be
"validating keyservers" or not, and how such servers could interact with
non-validating ones.

--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"A committee is a group that keeps minutes and loses hours."
(Milton Berle)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Kahn Gillmor-7
On Thu 2019-02-07 23:15:18 +0100, Kristian Fiskerstrand wrote:
> The current discussions we're having (e.g during OpenPGP email summit in
> brussels in october and lately on FOSDEM last weekend) is eventually not
> storing UIDs at all on the keyservers, but require the user to do key
> discovery through WKD, directly on a website or the like. This still
> allows using keyservers to distribute revocation certificates and
> updates to subkeys etc, but not as a discovery mechanism.

thanks for this summary, kristian.  it roughly matches my recollection
of these discussions as well.

It's conceivable that such a constrained updates-only-keyserver network
could also host self-signed user IDs, with reasonable constraints
(e.g. valid UTF-8 only, no more than 512 octets), but no third-party
certifications.  This would permit keyserver-based updates of
expirations, since primary key expiration timestamps are currently
stored in the self-signatures over the User IDs.

Alternately, we could encourage OpenPGP implementations to issue primary
key expiration timestamps as direct-key signatures, not involving a user
ID at all.

Critically, though, this updates-only keyserver network would *only*
permit retreival of keys by fingerprint, and would not provide a
web-based tool for browsing based on User ID, to avoid the usability
failures that we've seen attributed to SKS in the past.

Each node in this proposed updates-only network would also need to be
able to cryptographically verify the OpenPGP packets that it
synchronizes, and should reject packet that cannot be cryptographically
verified.

> Pool-wise it'd be setting up a separate keyserver network that  will
> gossip with the existing network for a time, with separate pool for the
> with-uid and without-uid servers, before the full switch is done...

Figuring out how to do the partial-sync for a limited time sounds
difficult to me, and i wonder whether it might be better/faster/cheaper
to just deploy such an update-only network, and don't bother with the
partial sync.

> The new network would be running on software replacing SKS, using more
> suited database backend that and multi-threaded implementation. The
> current disagreement are really with regards to whether this should be
> "validating keyservers" or not, and how such servers could interact with
> non-validating ones.

"validating keyservers" form an entirely distinct interaction model,
since they are focused on User IDs.  They should not be conflated with
this updates-only proposal.  There's no need to coordinate their
development.

        --dkg

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
12