WKD proper behavior on fetch error

[Ángel]

On 2021-01-18 at 10:14 +0100, Neal H. Walfield wrote:
> 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.

Hi Neal

I have been also giving some thought to this in the recent days.
I think the issue here is the lack of a defined policy. Each user may
have a completely different policy, but that would affect how this
should be treated.

In some cases, the user trust on the key will just be inherited from
the https certificate of the sate where it was published. In others,
the key will be completely validated through WoT.

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.

There is also the trust on the https CA itself. Which https CA should
the client trust? The https certificate was signed by a private CA, you
might not trust certain web CA for WKD, or you could want to augment
that set with e.g. the sks-keyservers CA.

We usually consider the OpenPGP keys as standalone entities, but the
client could be tagging the received keys: "received from keyserver X",
fetched via WKD (openpgpkey.foo.com) on $DATE, retrieved through WKD
using a broken https certificate, certificate validated with PKI, with
DANE, etc.

A client could be configured to take all of that into account for
computing the key trust in a way consistent with its user opinion.


All of that complexity for then having the end user, in almost every
case, merrily re-sending it in plain text if asked to.  ¯\_(ツ)_/¯



Some other related ideas that crossed my mind:

- If you are allowing certificates, that an unknown CA (or maybe are
even  self-signed), should the client insist in that the certificate
matches the presented hostname?

- 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 ?

- 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).



(...)

> 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!

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.


* However, an attack where your DNS server returned a fake NXDOMAIN
would be very hard to detect.


Best regards

Ángel