Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]
On 13/06/18 14:43, Daniel Kahn Gillmor wrote: > the proposed revocation distribution network wouldn't allow any user IDs > or third-party certifications, so most of the "trollwot" would not be > relevant. As I see it, the keyservers perform two related but distinct functions - finding unknown keys by UID, and finding updates to known keys by fingerprint. All the current issues are related to the first function, but the first function has several alternative solutions available (DNS, WKD, Keybase, attaching pubkeys to every email...). If this first function were to fail overnight, it would be an inconvenience but not a disaster. But there is no known alternative to the second function, which is the distribution of key updates, including revocations. Therefore I believe the immediate priority should be to protect update distribution. How to prevent abuse of a distributed, unauthenticated store of arbitrary data remains an unsolved problem (see: usenet). If the keyservers are to remain unauthenticated and distributed, then the only option is to prohibit arbitrary data. That means no arbitrary data fields (i.e. no UIDs) and no arbitrary data in structured data fields (i.e. validity checks on self-sigs). This will shrink the size of the database significantly, but impose some processing cost. There are two ways forward: a new network of key-material-only servers, or restricting the existing network to key material only. In the first case, we would still need a means to propagate keys between the old and new networks during the transition. And in the second case, we would need to handle an intermediate state where only some servers have been upgraded to the new version. So no matter what we do, we will still need to have some method of doing fake recon with legacy sks instances. The question is how to arrive at this state most efficiently. I would suggest that since recon is at the root of the problems, we should concentrate on the recon process itself. If uploading a bad key takes down one server then fine, we can lose one server. But the badness must not infect other servers automatically. -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]
On Wed 2018-01-17 08:57:12 +0100, Kristian Fiskerstrand wrote: > On 01/17/2018 01:20 AM, Daniel Kahn Gillmor wrote: >> On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote: >>> thanks for this post Daniel, my primary question would be what advantage >>> is gained by this verification being done by an arbitrary third party >>> rather by a trusted client running locally, which is the current modus >>> operandus. Any keyserver action doing this would just shift >>> responsibilities to a third party for something better served (and >>> already happens) locally. >> >> the advantage is spam-abatement -- the keyservers have to keep track of >> what is attached to each blob they transport/persist. if all signatures >> that they transport for a given blob are cryptographically certified, >> then only the original uploader of that blob can make assertions about >> it; other people can't spam the blob to make it untransportable. > > All the certificates used in trollwot are technically correct. You can > still use the same mechanisms as you control the other key material, and > can use intentionally weak key material if wanting to speed things up. sorry for the blast from the past here, but in re-reading this thread, i thought i'd follow up on this. the proposed revocation distribution network wouldn't allow any user IDs or third-party certifications, so most of the "trollwot" would not be relevant. if someone wants to upload their own key and make it unfetchable by appending garbage to it, that's probably OK (at least, it's a strict improvement than the current situation, which is that they can append garbage to *any* key). and if they use weak key material (or publish the secret someplace), then sure it's a noisy blob that anyone can append to. But no one will care, because they aren't likely to be relying on that key. does that make sense as to why this proposal is potentially useful? --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]
On 01/17/2018 01:20 AM, Daniel Kahn Gillmor wrote: > On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote: >> thanks for this post Daniel, my primary question would be what advantage >> is gained by this verification being done by an arbitrary third party >> rather by a trusted client running locally, which is the current modus >> operandus. Any keyserver action doing this would just shift >> responsibilities to a third party for something better served (and >> already happens) locally. > > the advantage is spam-abatement -- the keyservers have to keep track of > what is attached to each blob they transport/persist. if all signatures > that they transport for a given blob are cryptographically certified, > then only the original uploader of that blob can make assertions about > it; other people can't spam the blob to make it untransportable. All the certificates used in trollwot are technically correct. You can still use the same mechanisms as you control the other key material, and can use intentionally weak key material if wanting to speed things up. -- 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 "We all die. The goal isn't to live forever, the goal is to create something that will." (Chuck Palahniuk) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]
On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote: > thanks for this post Daniel, my primary question would be what advantage > is gained by this verification being done by an arbitrary third party > rather by a trusted client running locally, which is the current modus > operandus. Any keyserver action doing this would just shift > responsibilities to a third party for something better served (and > already happens) locally. the advantage is spam-abatement -- the keyservers have to keep track of what is attached to each blob they transport/persist. if all signatures that they transport for a given blob are cryptographically certified, then only the original uploader of that blob can make assertions about it; other people can't spam the blob to make it untransportable. --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]
> On 16 Jan 2018, at 22:26, Leo Gaspard wrote: > > It could also help limit the impact of the nightmare scenario RJH has > described, by making sure all the data is “cryptographically valid and > matching”, thus making it harder to just propagate arbitrary data down > the network. It would make it *very* slightly more computationally expensive to pull off, but would not limit the impact one bit. A ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]
On 01/16/2018 10:56 PM, Kristian Fiskerstrand wrote: > On 01/16/2018 07:40 PM, Daniel Kahn Gillmor wrote: > >> The keyserver network (or some future variant of it) can of course play >> a role in parallel to any or all of these. for example, keyservers are >> particularly well-situated to offer key revocation, updates to expiry, >> and subkey rotation, none of which would necessarily involve names or >> e-mail addresses. >> >> It would be interesting to see a network of keyserver operators that: >> >> (a) did cryptographic verification, and rejected packets that could not >> be verified (also: required cryptographic verifications of >> cross-signatures for signing-capable subkeys) >> >> (b) rejected all User IDs and User Attributes and certifications over >> those components >> >> (c) rejected all third-party certifications -- so data attached to a >> given primary key is only accepted when certified by that primary >> key. >> > > thanks for this post Daniel, my primary question would be what advantage > is gained by this verification being done by an arbitrary third party > rather by a trusted client running locally, which is the current modus > operandus. Any keyserver action doing this would just shift > responsibilities to a third party for something better served (and > already happens) locally. I guess one argument could be “when lazy people use the keyserver network, they likely get not-too-bad data”. I seem to remember that when a keyserver returned multiple keys to GnuPG, GnuPG imported both, even when searching for a fingerprint and the fingerprint didn't match, at some point in the last few years? If even GnuPG can fail at properly sanitizing the data received by keyservers (and I hope I'm not mistaken in this memory), I guess having such keyservers only serve curated data when used in their “nominal” use could help a bit. It could also help limit the impact of the nightmare scenario RJH has described, by making sure all the data is “cryptographically valid and matching”, thus making it harder to just propagate arbitrary data down the network. Then I don't have the structure of an OpenPGP key in mind, so maybe this would not work due to fields in the key that could be set to arbitrary data anyways ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]
On 01/16/2018 07:40 PM, Daniel Kahn Gillmor wrote: > The keyserver network (or some future variant of it) can of course play > a role in parallel to any or all of these. for example, keyservers are > particularly well-situated to offer key revocation, updates to expiry, > and subkey rotation, none of which would necessarily involve names or > e-mail addresses. > > It would be interesting to see a network of keyserver operators that: > > (a) did cryptographic verification, and rejected packets that could not > be verified (also: required cryptographic verifications of > cross-signatures for signing-capable subkeys) > > (b) rejected all User IDs and User Attributes and certifications over > those components > > (c) rejected all third-party certifications -- so data attached to a > given primary key is only accepted when certified by that primary > key. > thanks for this post Daniel, my primary question would be what advantage is gained by this verification being done by an arbitrary third party rather by a trusted client running locally, which is the current modus operandus. Any keyserver action doing this would just shift responsibilities to a third party for something better served (and already happens) locally. -- 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 Bene diagnoscitur, bene curatur Something that is well diagnosed can be cured well signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]
On Tue 2018-01-16 01:02:11 +, listo factor via Gnupg-users wrote: > Burning it down is not what I was advocating. I am advocating orderly > evacuation and replacement of a system that has clearly outlived its > usefulnesses. If it is not replaced in time, it will, at some point, > burn ignited by forces we have no control over. ~Then~ it will have > to be abandoned in rather more painful manner - just as you are > alluding to. While i think we disagree on "has outlived its usefulnesses", i would agree that planning and preparing for catastrophic keyserver network failure is a good idea. What i haven't seen in this thread is a list of the variety of proposals for OpenPGP key distribution that do *not* require the global append-only keyserver network. So in the hopes of making this a productive discussion, i'll list a few. Already briefly mentioned are: * Web Key Directory (WKD) Mail provider publishes public keys of users via https to a well-known location. https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-05 * Keybase social media and other avenues for key publication, identification, and corroboration. https://keybase.io A few other approaches are: * DNS OPENPGPKEY records DNS lookups of public keys (or hashes of public keys for confirmation) https://tools.ietf.org/html/rfc7929 * Autocrypt In-band key exchange (in every e-mail message) removes the need for external distribution mechanisms for all messages but the first. https://autocrypt.org/ * VVV DNS (SRV) discovery of HKP service operated by the mail provider. https://keys4all.de/media/beschreibung-vvv-loesung.pdf I'm sure i've missed some other distribution/verification/update mechanism, and would be happy to see constructive pointers. Of the above, i'm most leaning toward Autocrypt today, because it does not require involvement of any third party -- as long as both sides of the e-mail use an autocrypt-capable client, there is no additional information leakage. Note that the different schemes have different properties in terms of: * information leakage * cryptographic verification * third-party control * censorship * ... The keyserver network (or some future variant of it) can of course play a role in parallel to any or all of these. for example, keyservers are particularly well-situated to offer key revocation, updates to expiry, and subkey rotation, none of which would necessarily involve names or e-mail addresses. It would be interesting to see a network of keyserver operators that: (a) did cryptographic verification, and rejected packets that could not be verified (also: required cryptographic verifications of cross-signatures for signing-capable subkeys) (b) rejected all User IDs and User Attributes and certifications over those components (c) rejected all third-party certifications -- so data attached to a given primary key is only accepted when certified by that primary key. This would basically be a network that facilitates update/revocation/key-rotation, without exposing any names or e-mail addresses to the public by default; it could be run in parallel with the existing keyserver network. i don't know how well we could bridge the two networks, though and it'd be a shame to have to upload updated keys to both networks manually. :/ anyway, hopefully this gives some concrete, positive next steps that folks who want the keyserver network to go away can take, rather than trying to burn it all down :) --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users