A brief recap

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

A brief recap

Robert J. Hansen-3
To spare us all diving through list archives:

The keyserver network is in a lot of ways like a blockchain.  In both
cases they are distributed ledgers where any change to the ledger is
propagated through to everyone with a copy of the ledger.  (Blockchain
differs by adding more cryptographic verification, but in the broad
strokes they're very similar.)

Why did keyservers evolve in such a way?  Because in the early 1990s it
seemed like a good idea.  The idea was the distributed redundant ledger
of cryptographic certificates would make it impossible for a corrupt
government to force the removal of a dissident's certificates.  During
the Clinton-era crypto wars this was a very real concern.

It has also never happened in practice.  To the best of my knowledge --
and I've been watching keyserver operations for literally more than a
quarter-century -- no keyserver operator anywhere has ever been coerced
by a government to even try to remove a certificate.  The attack we were
concerned about never materialized.  It's reasonable to ask if, a
quarter-century later, it's time to stop defending against it.

Further: in the intervening time we've learned that append-only
world-writable distributed databases are inherently unstable.  Trolls,
hooligans, and criminals will poison it with information which is
irrelevant to the database's purpose (spam), offensive to many of the
maintainers (hardcore pornography), or flat out criminal (child
pornography).

So we have a few basic choices: *which condition do we waive?* being
foremost.

* Append-only?  Reconciliation just got unspeakably harder.
* World-writable?  This means restricting keyservers to vetted users.
* Distributed?  Then there is no more keyserver network.

Waiving the "distributed" is technically easiest but it ends the era of
keyserver networks.  Keyservers become completely balkanized.  Waiving
the "append-only" criterion sounds nice, because if we can figure out
how to do that then we get to keep the keyserver network while gaining
GDPR compliance and ending spam and porn in the network.  Unfortunately,
we have basically fuck-all zero idea of how to actually do it: the
engineering challenges are significant.


_______________________________________________
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: A brief recap

Daniel Roesler
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I disagree that we have to do a trade off, mostly for technical
reasons.

The append-only database and gossip protocol only cares about
public key data, not additional key packet data (e.g. emails,
signatures, photos, etc.). So, it's entirely possible to
participate in the pool and keep in sync with your public key
database, but also not serve up key packet material when
requested.

For example, I'm envisioning a keyserver that has a local
blacklist of data packets hashes (e.g. the spam/troll data),
that is just silently dropped when gossiping/syncing with other
keyservers. That way, the public keys keep in sync (so they
won't be dropped out of the pool), but when a user requests that
key from their specific server (either through the DNS round
robin, or directly through their web interface), the server only
sends the non-blacklisted packets.

This of course raises the risk of censorship for key packets,
but again these blacklists are server-specific, so it's entirely
possible to create multiple pools of troll-resistent keyservers
and free-as-in-freedom keyservers that still stay in sync with
each other because they PTree database and gossip only cares
about the public key content.

So, I think it's totally possible to keep the append-only,
global-write, distributed syncing of public keys. The only thing
that's needed is software features to be able to locally
blacklist key packets.

Daniel

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

iQEcBAEBCgAGBQJcW385AAoJEMtwcDcM6wt6wlcH/jozUV/bzu1Q74X8hhq5OzYK
m2XvFNQRQdsUc5MRqwqs0zacJIqnxEDTUJsk976mivAJQMiTlB4m75CRTPCAul5H
MaBMm2G7Cv1kiARRFhG17V57Re3wBxDGALqNrJZBsLlVXt1dHa8+OVeAb93gGe31
2eJiMdUD8MLt8Ed6BbZ+4CAV47nXE2Tyy5mMH6yshp39MnGtzBZ7aMLk165Iz8Rc
TK1Rjl7oCl2qu04fabG+Q2ul81h9uYd/4ceCAXggRYp80JBAe4qzogwUTXYrir6d
Mkx2pILof5Ua+2dws3Tun9VjHvzMCRL2CI6S7S/TY+HTchdlgc/DDAGWn6BPngY=
=YYjt
-----END PGP SIGNATURE-----


On Wed, Feb 6, 2019 at 6:19 PM Robert J. Hansen <[hidden email]> wrote:

>
> To spare us all diving through list archives:
>
> The keyserver network is in a lot of ways like a blockchain.  In both
> cases they are distributed ledgers where any change to the ledger is
> propagated through to everyone with a copy of the ledger.  (Blockchain
> differs by adding more cryptographic verification, but in the broad
> strokes they're very similar.)
>
> Why did keyservers evolve in such a way?  Because in the early 1990s it
> seemed like a good idea.  The idea was the distributed redundant ledger
> of cryptographic certificates would make it impossible for a corrupt
> government to force the removal of a dissident's certificates.  During
> the Clinton-era crypto wars this was a very real concern.
>
> It has also never happened in practice.  To the best of my knowledge --
> and I've been watching keyserver operations for literally more than a
> quarter-century -- no keyserver operator anywhere has ever been coerced
> by a government to even try to remove a certificate.  The attack we were
> concerned about never materialized.  It's reasonable to ask if, a
> quarter-century later, it's time to stop defending against it.
>
> Further: in the intervening time we've learned that append-only
> world-writable distributed databases are inherently unstable.  Trolls,
> hooligans, and criminals will poison it with information which is
> irrelevant to the database's purpose (spam), offensive to many of the
> maintainers (hardcore pornography), or flat out criminal (child
> pornography).
>
> So we have a few basic choices: *which condition do we waive?* being
> foremost.
>
> * Append-only?  Reconciliation just got unspeakably harder.
> * World-writable?  This means restricting keyservers to vetted users.
> * Distributed?  Then there is no more keyserver network.
>
> Waiving the "distributed" is technically easiest but it ends the era of
> keyserver networks.  Keyservers become completely balkanized.  Waiving
> the "append-only" criterion sounds nice, because if we can figure out
> how to do that then we get to keep the keyserver network while gaining
> GDPR compliance and ending spam and porn in the network.  Unfortunately,
> we have basically fuck-all zero idea of how to actually do it: the
> engineering challenges are significant.
>
> _______________________________________________
> 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: A brief recap

Robert J. Hansen-3
> I disagree that we have to do a trade off, mostly for technical
> reasons.

Let's call forbidden information 'kryptonite'.  Kryptonite is bad stuff.
 We don't want it on moral grounds or legal grounds.  We would rather
shut down keyservers than have kryptonite on our systems.  We then have
three choices:

* Keep it from entering the system (vetted users, approved submitters)
* Find a way to purge it from the system (ending append-only)
* Shut down keyservers

Saying "we can use blacklists to avoid serving up data" leaves you still
in possession of the data.  This has bad consequences for certain kinds
of kryptonite.  And the moment you say, "well, if you're not going to
serve it up then you don't need to store it, either" you've just agreed
to waive the append-only property.


_______________________________________________
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: A brief recap

Tobias Frei
Additional note: Even when restricting append-only mode to the email field, someone could upload keys for [hidden email] to permanently store the word "kryptonite" in the database. Also, one could use the first characters of key IDs to store information, linking the keys together as signatures or by alphabetical sorting.

00D... 
01E... 
02A... 
03D... 
04B...
05E... 
06E...
07F...

You couldn't even blacklist them without storing the information in your blacklist. 

Best regards 
Tobias Frei 

On Thu, Feb 7, 2019, 01:58 Robert J. Hansen <[hidden email]> wrote:
> I disagree that we have to do a trade off, mostly for technical
> reasons.

Let's call forbidden information 'kryptonite'.  Kryptonite is bad stuff.
 We don't want it on moral grounds or legal grounds.  We would rather
shut down keyservers than have kryptonite on our systems.  We then have
three choices:

* Keep it from entering the system (vetted users, approved submitters)
* Find a way to purge it from the system (ending append-only)
* Shut down keyservers

Saying "we can use blacklists to avoid serving up data" leaves you still
in possession of the data.  This has bad consequences for certain kinds
of kryptonite.  And the moment you say, "well, if you're not going to
serve it up then you don't need to store it, either" you've just agreed
to waive the append-only property.

_______________________________________________
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