WKD vs VV and VVV

[Bernhard Reiter]

Since 2-3 years there is a struggle about distributing public keys
to enable a better user experience with end-to-end crypto.

As you may know, https://wiki.gnupg.org/WKD
is the approach that g10code and Intevation have chosen May 2016
and which is fully implemented in GnuPG 2.2.

I've briefly looked at two other initiatives in Germany, which basically ran 
in parallel or a little later than the contract that resulted in WKD.

Best Regards,
Bernhard

== Details

  https://www.keys4all.de/aktuelles.php
  https://www.keys4all.de/gi-2017.php

link to a number of papers describing the approaches and results
of https://volksverschluesselung.de/ (VV)
and Vertrauenswürdige Verteilung von Verschlüsselungsschlüsseln (VVV).
All in German.

* [VV] is a central distribution of pubkeys and wants to strongly associate
  pubkey to person, thus does not have anonymity on its goals.

* VVV papers criticise that a DNS record per email-address
  would not scale with DNS.
  That aligns with one of our arguments against using DNS.

* VVV uses DNS SRV records to point to a special HKP server
  for each email provider. [BVVV] put forth arguments against WKD/WKS,
  remarks to some:
  ** inconsistency because pubkey management via policy file HTTPS and later
     SMTP but lookup with HTTPS
     They did not comment on the rationale that this management
     way may possibly be more easily implemented with email clients and fit
     an asynchronus email workflow better.

  ** No revoke, no requirements for keys like length, 
     no anti-brute-force-strategy specified.
     Comment: WKD was aimed for being a "lean" spec, where the main problem
     is solved first, and less important ones refined later with more
     experience in the wild. I'm not sure what they would want the
     "anti-brute-force-strategy" for as WKD is not "walkable" and you need to
     know the email-address before you request a pubkey.

  ** no distribution of old pubkeys for old signatures.
     This may be a valid use case once the main use cases are solved.

  ** Email provider needs "full control" about the webserver of the same 
     domain. 
     We point out this problem as well, though WKD does not need "full" access
     as an internal proxing or a https redirect also works. (Right now this is
     a point of discussion about evolving WKD as v05 offers DNS SRV records
     that some clients cannot easily implement. My personal stand is to use 
     HTTPS and one of the redirection methods if necessary until this is
     a broader consensus.)

  ** No definition of how the HTTPS service is secured.
     For larger email providers, they have a valid interest to keep their
     domain secured, so that is not worth mentioning. But for people with
     their own webside or smaller prodivers without weblogin on the email
     domain this could be an addition to WKD to give some hints about how to
     secure the main domain.

  ** Because no authentication is needed when submitting a pubkey via SMTP,
     it shall be possible to use this management servive as
     email-address-dossier.
     This is something I don't understand as WKD is not walkable.

* The VVV procedure requires DNS records, and thus cannot be implemented by
  modern Webbrowser Javascript in the page or an extension. It would need
  an external helper, either on the operating system side with native
  messaging or on the server. This is an implementation drawback.
  Anotherone is that many folks do not have access or are very conservative
  about their DNS records. And that use DNSSEC cannot be reliable checked
  from a client.
  Those implementation difficulties lead us to using HTTPS for the lookup
  in WKD.

* A legal paper [R] makes a point that a service handing out public keys 
  with some metadata like the name is like a phone book service and thus
  would be subject to data privacy directives that would require the
  user to be informed and thoroughly asked before publishing something.
  Of course this goes against the goal of doing encryption mostly in the 
  background and it a major hurdle for designing a good user experience
  for VVV.

  The WKD style of only allowing the email address to be present as metadata
  in the pubkey has the advantage that (in my very limited legal
  understanding) it is not a personal data record in a phone book like
  service, as you already have to know the email address before you can
  ask a WKD service of the provider for the pubkey. So there is no 
  "publication" of personal data going on and if really necessary
  email providers could put a remark in their terms of service.
  Overall WKD should allow to implement a better user experience in the
  setup phase.

* I haven't easily found source code for the prototype implementation
  of [VVV] on the webpage. GnuPG 2.2 is out there, KMail, Enigmail, GpgOL
  implement a good part of WKD with still more user experience work on
  the way.


  
== Literature
   
[BVVV] Beschreibung der VVV-Lösung
Peter Fischer, Ulrich Waldmann, Jan 2017
https://www.keys4all.de/media/beschreibung-vvv-loesung.pdf

[R] Rechtliche Problemstellungen der Ende-zu-Ende-Verschlüsselung: 
Anforderungen des künftigen europäischen Datenschutzrechts an die 
vertrauenswürdige Verteilung von Verschlüsselungsschlüsseln
Stephan Blazy, Susan Gonscherowski, Annika Selzer, Sept 2017

[VVV] Verfahren zur vertrauenswürdigen Verteilung von 
Verschlüsselungsschlüsseln
Peter Fischer, Thomas Kunz, Katharina Lorenz, Ulrich Waldmann, July 2017 
https://www.keys4all.de/media/Fischer-et-al.pdf

[VV] Die Volksverschlüsselung: Förderung vertrauenswürdiger 
Ende-zu-Ende-Verschlüsselung durch benutzerfreundliches Schlüssel- und 
Zertifikatsmanagement
Dominik Spychalski, Levona Eckstein, Michael Herfert, Daniel Trick, Tatjana 
Rubinstein, Jun 2017
https://www.keys4all.de/media/Spychalski-et-al.pdf


-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180425/1dc46efa/attachment.sig>