WKD proper behavior on fetch error

[Neal H. Walfield]

On Mon, 18 Jan 2021 16:47:38 +0100,
Ángel wrote:
> So, while in the first case a bad certificate would be a critical
> failure, in the second the right thing would be to fetch the key 
> *even if the certificate was invalid*, as it is used purely for
> discovery.

When you look up the openpgpkey.example.org domain, you are revealing
to anyone snooping DNS traffic that you are using OpenPGP and are
looking for a key related to example.org.  That's a privacy issue.

When you send the HTTP GET request, you reveal what email address you
are interested in (yes, it is obfuscated by the hash, but that can
often be broken using a dictionary attack).  That's an even bigger
privacy issue.

Given how easy it is to get a valid TLS certificate using Let's
Encrypt, I think it is better to flatout reject invalid TLS
certificates.

> - Should the client attempt to detect openpgpkey wildcard records and
> ignore the advanced method in such case? (this also covers ISP
> hijacking NXDOMAIN, which I also thought in)
> While it's easy to detect when this seems to be the case, that's still
> an heuristic, and why should I be prevented from serving WKD from a
> wildcard dns record if I want to ?

It's an interesting idea.  But I'm afraid that it really complicates
the WKD client's implementation for marginal security improvements.

> - An idea that seems worth considering, inspired by the way flowcrypt
> does its check, is to fall back to the direct method if the openpgpkey
> subdomain exists but it doesn't serve a policy file.
>
> This would solve the issue of non-malicious NXDOMAIN hijackings or DNS
> wildcards (assuming the certificate was valid).

That's a neat idea.

> How do you envision the users to use WKD? I would generally expect key
> retrieval to be a manual action, performed either from command line or
> a GUI client, but in both cases it would be possible to show a
> diagnostic about the non-working WKD.* And, even if the MUA was
> configured to automatically fetch the recipients key every time, it
> still needs a way to report back whether the message will be sent
> encrypted, there is no key or it isn't trusted. Unless OpenPGP is being
> used in a purely opportunistic way.

First, I'd regularly refresh keys in the background using all
available methods (WKD, multiple keyservers, gpg sync-style key lists)
using something like parcimonie:

  https://github.com/EtiennePerot/parcimonie.sh

Second, for key discovery, there are two main types of users.  For
security-sensitive users (people whose threat model includes dying if
this type of information is revealed), we should probably make key
discovery via WKD a manual operation.  For privacy-sensitive users,
I'd just transparently, and automatically look for a key when the user
types in an email address.  For a bit more privacy, one could wait
until the user presses send so that any WKD lookup will normally
immediately be followed by an SMTP connection to the same domain.  If
key discovery fails, the MUA could show an error ("can't encrypted,
because..."), or just send the message unencrypted, like Signal.

:) Neal