WKD proper behavior on fetch error

[Neal H. Walfield]

Hi Angel,

On Thu, 14 Jan 2021 01:47:12 +0100,
Ángel wrote:
> On 2021-01-13 at 10:12 +0100, Neal H. Walfield wrote:
> As such, I do think sequoia is non-conformant, although I'm
> more interested in determining the proper behaviour of a WKD client.
>
> ...
> I think it would be good that sq stopped after processing
>
> openpgpkey.foo.com, mainly to follow the principle of least surprise.
> 
> If the key can only be placed in one place, then it MUST be good (or
> bad, but it will be consistent).

I've given this issue some more thought.

First, I don't think WKD is a strong authentication method.  It is
sufficient for doing key discovery for opportunistic encryption (i.e.,
it's a reasonable guess), but I wouldn't want someone to rely on it to
protect them from an active adversary, or phishing attempts.

If you consider WKD to be a strong authentication mechanism, then you
are basically relying on X.509 plus a bit of brittleness (the
certificates aren't signed, only the TLS session is).  So, if that's
your position, then just use S/MIME.

One way to increase protection for certificates is to certify them in
the usual OpenPGP manner.  Of course, this begs the question: if you
certify them before you get them via WKD, is WKD really helping with
key discovery?  Well, OpenPGP doesn't only have certifications, it
also has trusted introducers, i.e., CAs.  So, a certificate could be
certified by someone else.  Isn't that just X.509?  Well no, X.509 de
facto relies on a few hundred global CAs (Symantec, TurkTrust, etc.),
but in OpenPGP everyone is by jure a CA.  So, a domain administrator
could just set up a CA for their own domain.  (In fact, OpenPGP CA
[1,2] makes this pretty easy.)  This results in a federated system!
Now, individuals "just" need to designate a few CAs.  Yes, it is still
work, but it is much less work.  As admins are more technically
sophisticated, there are other things that they can do to improve
security.  But, that's getting a bit off topic.

  [1] https://gitlab.com/openpgp-ca/openpgp-ca
  [2] https://openpgp-ca.gitlab.io/openpgp-ca/

Second, the attack that I'm most worried about with repect to WKD is a
DoS.  It is trivial for an attacker to block WKD.  They just need to
filter the DNS.  In the privacy world, there are a lot of tools to do
just that.  For instance, pi hole [3] blocks ads at the DNS level.  It
could just as well be used to force the openpgpkeys subdomain to
revolve to localhost.  Comcast, a major US ISP, used to do this type
of interception as a way to increase revenue: if a user typed in an
invalid domain, instead of return NXDOMAIN, Comcast would resolve it
and show the user some ads instead [4].  AIUI, they stopped doing this
due to general outrage, but that is little solace.

  [3] https://docs.pi-hole.net/main/post-install
  [4] https://www.pcworld.com/article/169723/article.html

This attack is likely to go unnoticed, firstly because most key
discovery is done in the background, and probably shouldn't actively
show errors messages to the user.  But, more importantly, because
nothing else uses the openpgpkeys subdomain, everything else will
still appear to work!


In short: I understand the motivation for the subdomain.  I understand
why one should first check there.  But, I think we do our users a
disservice by not falling back to the direct method in the case of
DNS errors.

:) Neal