WKD & Sequoia

[André Colomb]

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 <andre at colomb.de>