Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
> On 7 Nov 2018, at 16:43, Yegor Timoshenko wrote: > > It's not just storage, it's also immutable and distributed. In the keyservers, removing immutable content is a Very Hard Problem, but it is theoretically possible. With blockchain, it is impossible by design. A ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
> Free storage to upload arbitrary data is easily available (e.g. > p2p, free mail accounts). Having a searchable index to that > data is more challenging. Thus removing the search capability > from the keyservers will render its free-as-in-beer storage > feature mostly useless. It's not just storage, it's also immutable and distributed. It's very different from P2P in that operators will have to host that content less than voluntary, and it's different from mail account in that it's public. For how problematic that might be, see https://fc18.ifca.ai/preproceedings/6.pdf.___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
On Wed, 7 Nov 2018 11:50, andr...@andrewg.com said: > significantly affecting legitimate use. It may stop people uploading > warez but it can’t prevent cheap vandalism. Free storage to upload arbitrary data is easily available (e.g. p2p, free mail accounts). Having a searchable index to that data is more challenging. Thus removing the search capability from the keyservers will render its free-as-in-beer storage feature mostly useless. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp7R_T8qQmZw.pgp Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
On 07.11.2018 11:50, Andrew Gallagher wrote: > >> On 7 Nov 2018, at 10:16, Yegor Timoshenko wrote: >> >> World-writable storage is problematic even if there is no search. >> Proof of work and some operator-controllable data removal >> mechanism (like opt-in key blacklists) can help limit this attack >> vector. >> >> Storing immutable data, distributed recon, proof of work, that >> sounds like something a blockchain should do to me. > > More evidence that blockchain is a solution in search of a problem! :-) > > Proof of work verification provides little benefit over cryptographic > verification. If you have already generated a valid signature, that is in > itself a proof of work. The only reason you would also use hashcash is if you > wanted to increase the difficulty of the work beyond what the cryptography > itself provides. But hashcash only works if it is possible to find a > difficulty level that impedes abuse while not significantly affecting > legitimate use. It may stop people uploading warez but it can’t prevent cheap > vandalism. Blockchain can be used to timestamp data in a way that is evident to a broad audience. If cryptographic verification was enough for X.509 there wouldn't be Certificate Transparency (that uses similar primitives) and CT is required for all issued "SSL certificates" today [0]. For OpenPGP that would mean keeping the keyservers accountable: not letting them return different responses for different people, or omitting some data (e.g. revocations). There are already projects that tackle this very problem: - https://coniks.cs.princeton.edu/about.html - https://security.googleblog.com/2017/01/security-through-transparency.html - https://blog.okturtles.org/2017/02/coniks-vs-key-transparency-vs-certificate-transparency-vs-blockchains/ (For the record I'm not advocating for using blockchain, but even a buzzword tech should be evaluated purely on its merits) Kind regards, Wiktor [0]: https://www.thesslstore.com/blog/certificate-transparency-april-30-2018/ -- https://metacode.biz/@wiktor ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
> On 7 Nov 2018, at 10:16, Yegor Timoshenko wrote: > > World-writable storage is problematic even if there is no search. > Proof of work and some operator-controllable data removal > mechanism (like opt-in key blacklists) can help limit this attack > vector. > > Storing immutable data, distributed recon, proof of work, that > sounds like something a blockchain should do to me. More evidence that blockchain is a solution in search of a problem! :-) Proof of work verification provides little benefit over cryptographic verification. If you have already generated a valid signature, that is in itself a proof of work. The only reason you would also use hashcash is if you wanted to increase the difficulty of the work beyond what the cryptography itself provides. But hashcash only works if it is possible to find a difficulty level that impedes abuse while not significantly affecting legitimate use. It may stop people uploading warez but it can’t prevent cheap vandalism. A ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
> Purpose 4, distribution of key signatures, worked as long as > people didn't used the key listings of the server or tools for > more or less funny messages. Uploading key signature should be > possible only by the holder of the key. However, to enforce > this the keyservers need to employ real crypto and won't be a > lean service anymore. I think the distribution of keyservers, > for those who still want to use the WoT, can be replaced by > sending the signed keys only back to owner. In fact tools like > caff suggest this use case. Storing and distributing signatures with issuing keys (instead of keys that are being signed) should limit abuse potential while still allowing for WoT. > Purpose 5 is not relevant for OpenPGP key distribution and > actually the reason why the keyserver network has more or less > broken down. World-writable storage is problematic even if there is no search. Proof of work and some operator-controllable data removal mechanism (like opt-in key blacklists) can help limit this attack vector. Storing immutable data, distributed recon, proof of work, that sounds like something a blockchain should do to me.___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
> Purpose 4, distribution of key signatures, worked as long as > people didn't used the key listings of the server or tools for > more or less funny messages. Uploading key signature should be > possible only by the holder of the key. However, to enforce > this the keyservers need to employ real crypto and won't be a > lean service anymore. I think the distribution of keyservers, > for those who still want to use the WoT, can be replaced by > sending the signed keys only back to owner. In fact tools like > caff suggest this use case. Storing signatures with issuing keys (instead of keys that are being signed) should limit abuse potential while still allowing for WoT. > Purpose 5 is not relevant for OpenPGP key distribution and > actually the reason why the keyserver network has more or less > broken down. World-writable storage is still a problem: even if no search is present, at the very least means arbitrary writes. Proof of work can both help limit this misuse vector. Storing immutable data, distributed recon, proof of work, that sounds like something a blockchain should do to me.___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
So it seems like the usual response is to ignore the fatal issues that could affect this network. 6 months on from the first set of PoC's and no one has stepped forward to fix them - they have only attempted to defend the network through pride. How is anyone meant to trust infrastructure run by people who avoid problems like this? As usual, people keep burying their heads in the sand with nothing more than excuses. Something as simple and small as a Raspberry Pi could down the entire network. "Resilient against governments"? I don't think so! These servers no longer provide the function they once promised, and this needs to be addressed by the leading figures of the community with direct and clear responses, not excuses! I believe that Kristian is the main spokesperson? He has never once stepped forward and commented on any of the issues. Kind Regards Yakamo On Wed, 07 Nov 2018 10:13:06 +0100 Werner Koch wrote: > On Tue, 6 Nov 2018 17:27, a...@datenreisen.de said: > > > I do roughly recal that such a verification process has been discussed for > > the SKS keyservers at one of the pgp-summit before, but i wonder what > > happened to the idea. However, if it that is “good enough” to be compliant > > This requires that there are no rogue keyservers in the network and that > in turn means that they are under the control of a single entity. Or > in short, let Google take care of it. > > Such verification will be a single point of failure and it would be > trivial for governments or corporations to take down a key. > > > Shalom-Salam, > >Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- me ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
On Tue, 6 Nov 2018 17:27, a...@datenreisen.de said: > I do roughly recal that such a verification process has been discussed for > the SKS keyservers at one of the pgp-summit before, but i wonder what > happened to the idea. However, if it that is “good enough” to be compliant This requires that there are no rogue keyservers in the network and that in turn means that they are under the control of a single entity. Or in short, let Google take care of it. Such verification will be a single point of failure and it would be trivial for governments or corporations to take down a key. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgph8cN4ApmO7.pgp Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
On Tue, 6 Nov 2018 17:57, v...@pep-project.org said:
> I'm not of the opinion that key servers are a good idea at all. It's
> a pity that people still follow this wrong idea.
Keyservers are used for several purposes:
1. Search for keys based on the fingerprint ("gpg --recv-key FPR")
2. Search for key recovations ("gpg --refresh-key")
3. Search for keys based on the user id. (e.g. "gpg --search-key")
4. As a distribution medium for key signatures.
5. As a distributed and searchable storage.
The first two purposes are quite useful because they allow to verify
signatures made by yet unknown keys. Retrieving the keys is no data
privacy problem because by signing and sending a mail the sender has
already provided all these information. There is nothing which can
replace these purposes because a key does not necessary need to have a
mail address and even if so, any mail address based lookup can fail
after the mail address is not longer in use, the account has been
disabled, etc. Fingerprints are are globally unique and need not be
associated with a mail address.
Purpose 3 is what we call key discovery and indeed keyservers are the
wrong way to do this. In most cases we want to map a mail address to a
key and have some kind of reliable mapping. Keyservers which are just a
pile of keys don't allow for this. Back then when encryption was young
and the internet was a friendly place search for keys worked in most
cases. But the times have changed and the bona fide search is useless.
Purpose 4, distribution of key signatures, worked as long as people
didn't used the key listings of the server or tools for more or less
funny messages. Uploading key signature should be possible only by the
holder of the key. However, to enforce this the keyservers need to
employ real crypto and won't be a lean service anymore. I think the
distribution of keyservers, for those who still want to use the WoT,
can be replaced by sending the signed keys only back to owner. In fact
tools like caff suggest this use case.
Purpose 5 is not relevant for OpenPGP key distribution and actually the
reason why the keyserver network has more or less broken down.
My suggestion is limit the keyservers to the purposes 1 and 2. This
can in practice easily be done by removing the search by user-id
interface form the keyservers and, on the client site, by discovering
keys using other methods (e.g. Web Key Directory). Having no searchable
interface to the keyservers make them less attractive for abuse (as in
purpose 5) and avoid some privacy issues (white pages without user
consent).
It is likely that gpg will eventually change its --search-key command to
do the equivalent of --locate-key but without checking the local
keyring.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgpi2JV0sKsp_.pgp
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
> On 6 Nov 2018, at 20:09, Mike wrote: > > I don't think "resilient" can be used any more in relation to sks-keyservers > as they drop offline on and off and even one malicious individual could take > the whole network down if motivated enough. Individual servers drop on and offline but the network as a whole is more robust. It is easy to take down the entire network of course, but this is very noisy. It is very hard to selectively prevent only a particular revocation from being served by the keyservers. Most other methods of distributing keys allow for selective blocking of one domain or even one address. A ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
I don't think "resilient" can be used any more in relation to sks-keyservers as they drop offline on and off and even one malicious individual could take the whole network down if motivated enough. On Tue, 6 Nov 2018 18:34:49 + Andrew Gallagher wrote: > > > On 6 Nov 2018, at 16:57, Volker Birk wrote: > > > > I'm not of the opinion that key servers are a good idea at all. It's > > a pity that people still follow this wrong idea. > > There are other methods for discovery that don’t suffer from the same > weaknesses, but there is no equally resilient method of distributing > revocations. > > A > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel -- me ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
I don't think "resilient" can be used any more in relation to sks-keyservers as they drop offline on and off and even one malicious individual could take the whole network down if motivated enough. On Tue, 6 Nov 2018 18:34:49 + Andrew Gallagher wrote: > > > On 6 Nov 2018, at 16:57, Volker Birk wrote: > > > > I'm not of the opinion that key servers are a good idea at all. It's > > a pity that people still follow this wrong idea. > > There are other methods for discovery that don’t suffer from the same > weaknesses, but there is no equally resilient method of distributing > revocations. > > A > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel -- me ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
On Tue, Nov 06, 2018 at 17:57 +0100, Volker Birk wrote: > On Tue, Nov 06, 2018 at 05:27:14PM +0100, Andy Mueller-Maguhn wrote: > > I do roughly recal that such a verification process has been discussed for > > the SKS keyservers at one of the pgp-summit before, but i wonder what > > happened to the idea. However, if it that is “good enough” to be compliant > > with the GDPR i can´t say, but this sounds like a good idea in any case. > > I'm not of the opinion that key servers are a good idea at all. It's > a pity that people still follow this wrong idea. I happen to be similarly skeptical of key servers and don't want to spend much effort with helping to evolve the concept. I might be wrong, though, and there are good uses that solve real security issues for people. When i say "real security issues" i mean those who otherwise are oppressed and imprisoned for real, not in some potentiality. It's about real outcomes for people and not some security ideal. Some folks certainly think key servers are useful and i respect them. And also, who knows, i might be missing something. I admit that so far the arguments pro key servers (eg revocation) have not made me lean more towards going for it. holger signature.asc Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
On Tue, Nov 06, 2018 at 05:27:14PM +0100, Andy Mueller-Maguhn wrote: > I do roughly recal that such a verification process has been discussed for > the SKS keyservers at one of the pgp-summit before, but i wonder what > happened to the idea. However, if it that is “good enough” to be compliant > with the GDPR i can´t say, but this sounds like a good idea in any case. I'm not of the opinion that key servers are a good idea at all. It's a pity that people still follow this wrong idea. Yours, VB. -- Volker Birk, p≡p project mailto:v...@pep-project.org https://pep.software signature.asc Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
On 23 May 2018, at 11:07, Patrick Brunschwig wrote: > There are actually two different types of keyservers, which should be > clearly distinguished. > > 1. the pool of SKS keyservers: as anyone can upload anybody's key, and > as it does not allow to delete keys, it's IMHO by not compatible with GDPR. > > 2. other types of keyservers like the run by Mailvelope (and possibly > others that I don't know of), that verify the keys they receive and > allow to delete keys, are compatible with GDPR, or can be made > compatible easily. I don´t know what Mailvelope uses (as they seem to integrate everything in their webfrontend), but adding a verification procedure when uploading a key (through the email-address of the key) into the SKS keyservers seems to me like long overdue, as it also would solve to an larger extend the problem mentioned by Gabor with fake-keys uploaded in $other persons name. I do roughly recal that such a verification process has been discussed for the SKS keyservers at one of the pgp-summit before, but i wonder what happened to the idea. However, if it that is “good enough” to be compliant with the GDPR i can´t say, but this sounds like a good idea in any case. best, A. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
