WKD proper behavior on fetch error

[André Colomb]

Hi Neal,

On 18/01/2021 10.14, Neal H. Walfield wrote:
> 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.

That's a very good point.  In that regard, the spec should maybe present
the two methods as equal alternatives to be tried in a standardized
order until either one succeeds.  Requiring to report configuration
failures is really out of scope for a protocol at that level, and the
end user can hardly do anything about it anyway.

Nevertheless, a big fat warning in the log / console would be appropriate.

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

I suppose you mean other errors besides DNS?

Whichever method was intended to be used, the (weak) trust anchor is
always the returned DNS response, and therefore both methods would be
equally screwed if a failure can be induced at that level.  Pointing the
DNS response for either example.com or openpgpkey.example.com to a
malicious webserver is no different.  Both would need to be done for
e.g. the ACME (Let's Encrypt) verification server's perspective as well,
which is harder than a local network attack.

We need to remember that WKD is only a convenience mechanism for
discovery, not any kind of authentication.  Sending encrypted e-mail to
a domain which was also used to retrieve the encryption public key adds
no protection against MITM, but only transport obscurity.  But that
might still be better than no encryption at all, e.g. to set up an
out-of-band key verification.

Kind regards
André

-- 
Greetings...
From: André Colomb <andre at colomb.de>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210118/8e2b31d8/attachment.sig>