WKD & Sequoia

[Neal H. Walfield]

Hi Andre,

On Tue, 12 Jan 2021 20:13:42 +0100,
André Colomb wrote:
> It has also been pointed out repeatedly in this thread that Sequoia
> apparently does not properly check the TLS certificate, which you have
> proven with your example setup.  That could be called "modern" or
> "insecure".  It has nothing to do with the ordering of the two methods.

I'd like to clarify what Sequoia is doing (wrong).

As per the I-D, sq first tries the advanced method.  If that fails for
any reason, it falls back to the direct method.  You can see the three
relevant lines of code here:

  https://gitlab.com/sequoia-pgp/sequoia/-/blob/c80d2ab0/net/src/wkd.rs#L288

If I remove the "or_else", which falls back to the direct method, then
sq shows the following error when fetching stefan at sac001.github.io:

  $ sq wkd get stefan at sac001.github.io
  Error: error trying to connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: (Hostname mismatch)
  
  Caused by:
      0: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: (Hostname mismatch)
      1: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915:

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.

The latest WKD I-D says:

   3.1.  Key Discovery

   There are two variants on how to form the request URI: The advanced
   and the direct method.  Implementations MUST first try the advanced
   method.  Only if the required sub-domain does not exist, they SHOULD
   fall back to the direct method.

   https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-11

(FWIW, this was added to revision 7, which was published in
Nov. 2018.)

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.

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?

We thought about this question, but we couldn't figure out a
satisfactory answer.  The worst attack we could come up with is: an
attacker could force a WKD client to use an illegitimate WKD via the
direct method instead of a legitimate WKD via the advanced method by:

  - Taking over foo.com's https, AND
  - Preventing a WKD client from correctly using the advanced method.

But the attacker is NOT able to:

  - Take over openpgpkey.foo.com's https, OR
  - Prevent the WKD client from resolving openpgpkey.foo.com.

So sure, that's possible, but it seems like WKD shouldn't foo.com's
biggest worry in that case.

(If we overlooked possible attacks, I'd be happy to hear about them.)

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.

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.

:) Neal