Hi Neal, thanks for chiming in with details about your implementation. It's now clear that the wrong certificate in fact triggers an alarm, which is good. Only the fall-back behavior differs from GnuPG. Since Stefan set up the direct method as well, that leads to his setup actually working with Sequoia.
On 13/01/2021 10.12, Neal H. Walfield wrote: > So, the hostname mismatch is correctly identified, and it correctly > returns an error. > > Where sq's behavior diverges from gpg's is that sq then tries the > direct method, but gpg does not. I agree that this is the culprit why the two implementations differ. > The I-D says "Only if the required sub-domain does not exist, they > SHOULD fall back to the direct method." The text doesn't say: "If > there is an error, they SHOULD fallback to the direct method unless > the required sub-domain does not exist, in which case they MUST NOT > fall back to the direct method." So, strictly speaking, I don't think > Sequoia is violating the specification. The way I read it, "SHOULD fall back" means that it can opt not to fall back at all. The sentence begins with "Only if ... does not exist", so the whole SHOULD statement just doesn't apply if the subdomain does exist. Proper behavior when the subdomain exists, but some other error occurs, is undefined in the spec. There is certainly room for improvement / clarification here. > But, I don't want to be overly pedantic. Even if the spec were to > prohibit falling back to the direct method when the subdomain exists, > what exactly would this prohibition gain us? The whole point in my opinion is to give the domain admin control over the WKD resolution process. By blocking the openpgpkey subdomain from resolving, they can avoid needless HTTPS request handling, as I explained in detail before: https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064622.html > (If we overlooked possible attacks, I'd be happy to hear about them.) I don't see any big *security* implications either, but I'm really no expert on that topic. There seems to be good reasons for why the I-D specifies it exactly as it does, namely to give a way to control which server automated WKD requests go to and keeping the load as small as possible. > On the other hand, implementing this prohibition means that a DNS > server can prevent its clients from using WKD by forcing all > openpgpkey subdomains to resolve to 127.1. That's hard to notice, > because everything else still appears to work. One can't really prohibit anyone from *trying* to request a resource over some HTTPS URL, especially not in a protocol specification. But the current WKD draft tries to specify at which point a well-behaved WKD client makes the decision on the "correct" method. > Practically speaking, we helped an organziation deploy WKD, and they > had a similar problem to what Stefan is observing: the admins setup > the direct method, but it didn't work, because their DNS automatically > resolved all unknown subdomains to serve a 404. Unfortunately, they > had outsourced management of their DNS and couldn't (or didn't know > how) to disable this behavior. IIRC, in the end, they spun up an > https server for openpgpkeys.domain. So the core problem, as with Stefan's case, is the lack of control over the domain's DNS settings. Which the WKD mechanism relies upon to delegate trust to the domain operators. I think that is a legitimate concern regarding the current WKD Internet Draft. At least a clarification and maybe some adjustments to the advised fall-back behavior would be in order. Let's see what Werner has to say about it and if there are yet unclear reasons for the currently specified way. Kind regards André -- Greetings... From: André Colomb <an...@colomb.de> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
