Re: [Sks-devel] SKS apocalypse mitigation
Hi, all. There has been a lot of chatter re possible improvements to SKS on the list lately, and lots of ideas thrown around. So I thought I'd summarise the proposals here, and try to separate them out into digestible chunks. I've ordered them from less to more controversial. My personal preference is for the first two sections (resiliency, type filters) to be implemented, and for the rest to be parked. This has turned out to be a much longer document than I expected. I don't intend to spend any further time or energy on local blacklisting, as its technical complexity increases every time I think about it, and its politics and effectiveness are questionable. A. Concrete proposals == Version 1.X: Resiliency --- These are ideas that fell out of the other discussions, but are applicable independently. If we want to make backwards-incompatible changes, then automatic verification of status, versions etc will probably be necessary to prevent recon failure. ### JSON status A standardised JSON status page could be served by all SKS-speaking services. This would ease fault detection and pool management, and is a prerequisite for reliable sanity callbacks. ### Default initial_stat=true Also a prerequisite for sanity callbacks. Otherwise useful for debugging and fault detection. ### Sanity callbacks Currently, a server has no way to determine if its peers are correctly set up or have key deltas within the recon limit. If each host served a JSON status page, peers could perform a sanity check against it before allowing recon to continue. This would help contain the effects of some of the more common failure modes. ### Empty db protection If the number of keys in the local database is less than a configured threshold, an sks server should disable recon, and throw a warning. The particular threshold could be set in the conf file, and a sensible default provided in the distro. This should prevent new servers from attempting recon until a reasonable dump is loaded. Version 2.0: Type filters with version ratchet -- This proposal seems to have the most support in principle. It is relatively easy to implement, and directly addresses both illegal content and database bloat. It does however require precise choreography. It should be possible to alter the sks code during a version bump so that: 1. All objects of an expanded but hardcoded set of types (private keys, localsigs, photo IDs, ...) are silently dropped if submitted 2. Any existing objects in the database of these types are treated as nonexistent for all operations (queries, recon, dumps, ...) 3. The above rules are only enabled on a future flag day, say 180 days after the release date of the new version 4. The version criterion for pool membership is bumped a few days in advance of the flag day 5. A crufty database could be cleaned by dumping and reloading the db locally, or a database cleaner could be run on a schedule from within SKS itself This would purge the pool of the most obviously objectionable content (child porn, copyrighted material), with minimal collateral damage. The disadvantage is that any noncompliant peer would fail recon after flag day due to excessive delta, and thus would need to be either depeered manually, or have its recon attempts denied by a sanity callback. Other implementations (i.e. hockeypuck) would have to move in lockstep or be depeered. Future speculation == Future A: Policy blacklisting - Pay attention, kid. This is where it gets complicated. Version ratchets may not be flexible or responsive enough to deal with specific legal issues. Policy-based blacklisting gives server operators a fine-grained tool to clean their databases of all sorts of content without having to move in lockstep with their peers. These proposals are more controversial, given that individual operators will have hands-on responsibility for managing policy, and thereby potentially be more exposed legally. It should be noted however that technical debt may not be a valid defence against legal liability. IANAL. All of the changes in this section must be made simultaneously, otherwise various forms of recon failure are inevitable. This will involve a major rewrite of the code, which may not be considered a good use of time. If type filters have been implemented (see above), the need for local policy would be considerably reduced. If however type filters were not used, then policy blacklists would be the main method for filtering objectionable content, which might be prohibitive. Note that locally-divergent blacklist policies have the potential to break eventual consistency across the graph (see below). ### Local blacklist An SKS server may maintain a local blacklist of hashes that it does not want to store. At submission time, any object found in the blacklist is silently dropped. Any requests for objects in
Re: [Sks-devel] Keyservers and GDPR
On 22.05.18 21:44, Vincent Breitmoser wrote: [...] > My personal conclusion is that keyservers that support user id packets are, > quite simply, incompatible with GDPR law. Has anyone else thought about this? > It's fairly unlikely that there will be actual consequences since keyservers > aren't widely used, but running a keyserver on this assumption is hardly > reassuring. 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. -Patrick ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Keyservers and GDPR
Hi Vincent, Am Dienstag 22 Mai 2018 21:44:09 schrieb Vincent Breitmoser: > My personal conclusion is that keyservers that support user id packets are, > quite simply, incompatible with GDPR law. Has anyone else thought about > this? thinking about earlier data privacy laws (which were quite similiar to GDPR in many respects) and pubkey servers got me to no clear conclusion. > For OpenKeychain, we plan to move uploading of key material a bit farther > out of the way and do a better job at informing the user what's going to > happen. If our goal is to automate the common case in an end-to-end crypto mail communication, then asking the user a data privacy agreement question is a stumbling block. I would degrate the user experience a lot. Note that if you use WKD with your email provider and just the email address in the key id (as supported by a policy option), there is no additional personal data saved nor communicated. The email provider already has your email address and the person asking via WKD also. In addition serving of the public key on behalf of ther user could be added to the terms of service of the email provider. Overal I think WKD is doing quite well on the data privacy side and will allow a good user experience by not asking each time to publish a new pubkey for oneself. Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: This is a digitally signed message part. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Keyservers and GDPR
On 05/23/2018 11:27 AM, ilf wrote: > tl;dr: Keep calm and keep running keyservers. > > Vincent Breitmoser: >> (cross-posting on all the cool pgp lists) > > (I wonder, if this really needs to be an all the four lists. I think > sks-devel@ might be the most appropriate. Having said that, I'm only > replying to gnupg-devel@ because I'm not subscribed to sks-devel@. Feel > free to relay my message.) As I think this has a valuable viewpoint I'm posting it to sks-devel. And yes, this is mostly in line with my own thinking, I don't expect the need for radical changes unless we see actual attempts to go after the infrastructure. > >> My personal conclusion is that keyservers that support user id packets >> are, quite simply, incompatible with GDPR law. > > There is a ton of FUD about the GDPR out there right now. Most of it > frivolous. (Actually, a lot of it is deliberate fearmongering by people > who happen to sell legal advice on the GDPR.) > > First of all, the GDPR is not completely new. All EU member states > already have data protection laws, some - like Germany - already very > strong ones. The concepts (PII, responsibilities, technological and > organisational measures, information and documentation obligations) have > already been in place with the old Data Protection Directive from 1995, > which the GDPR is updating. I admit that the GDPR can be read and > interpreted in a fatalist way. But most people leaning that way seem to > not have read the older laws. > > Laws are not set in stone. Laws include leeways, deliberate or > unintended. Laws do not depend on their interpretation by laypeople. > There is a huge dedicated system for its interpretation, conflict > resolve, judgement and enforcement. > > In the case of the GDPR, the very first step of that system are National > Data Protection Authorities (DPA). They have the power - and the > responsibility - to investigate possible violations of the GDPR. They > have been understaffed for years, in many countries dangerously so. They > are getting a lot more powers and responsibilities with the GDPR, but > their resources are growing way slower than their tasks. They are simply > understaffed and overworked. So from all the possible GDPR violations > they will be notified about, they will work off the biggest and most > obvious ones first. Their focus will be on the Facebooks - and not on > small nerd projects or personal websites. They have the power to say "we > don't care about this weird thing called keyserver" - and the probably > will. > > Now even if someone found data protection law infringements with a > keyserver, filed a specific and well-worded legal complaint with a DPA, > and a DPA found the resources to look into it, and the DPA found some > violation of the GDPR (four big IFs!) - the DPAs will not go around and > issue sanctions and fine people. First of all, their job is not to > generate revenues by fines. Their job is to enforce data protection law. > If a DPA did find an issue with a keyserver - or the very concept - they > would reach out and talk to the people running the servers. They would > hear their perspective, learn more about the very concept - and try to > work out a viable solution to provide the service without possible data > protection infringements. This is their job and their goal. > > The most feared sanction of some undefined GDPR violation is a fine. As > I layed out, DPAs don't want to issue fines, they want to stop privacy > violations. And they will not blindly issue a fine without talking to > you first. That being said, they obviously do have the power to issue > fines. After due process. However, this power is also not new, it has > also existed in many countries. And DPAs don't run around and fine > people left and right (you would have heard about that), they exercise > their power in a balanced way. And fines are always in relation to the > economic and personal circumstances of the - then guilty and obstinate - > data protection violators. I guess most keyservers are run by > non-profit individuals or institutions. Even if a company runs a > keyserver, it doesn't make money with that service. Therefore, I think > the chance of *any* fine is negligible - and the chance of an > unreasonably high fine is almost zero. And if it ever came to this, the > community and public alarmed by public outcry would probably donate more > than the fine issued. > > To sum up: Keep calm and keep running keyservers. You'll be fine. > > More elaboration in German: > https://netzpolitik.org/2018/bussgelder-bei-datenschutzverstoessen-angst-vor-einem-phantom/ > > > Disclaimer: IANAL. This is not legal advice. > > > > ___ > Gnupg-devel mailing list > gnupg-de...@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk
