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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users