On 12/01/2021 20.40, Stefan Claas wrote:
>> So there are two "bugs" involved here. 1. GitHub presenting an invalid
>> certificate for the sub-subdomain and 2. Sequoia not noticing that.
>> Neither of these are bugs in GnuPG. If you can accept these facts, then
>> it makes sense to further discuss what could be changed where to make
>> your desired setup work. Maybe that discussion will lead to a concise
>> change proposal.
>
> Hi Andre, currently I can only accept the fact that these two "bugs" are
> currently not resolved in GnuPG and gpg4win, if you allow me to
> formulate it this way. I desperately hope that this thread will lead to a
I (and others) understand the word "bug" as in "software not working
according to its specification". The specification is the WKD Internet
Draft as well as some RFCs about TLS certificate rules. Bugs in Sequoia
or GitHub's DNS configuration can therefore not be resolved in a
different software, namely GnuPG. Not sure what you mean by "resolve"
otherwise. Ignoring security rules would be a workaround, and a
terrible one as well.
Regarding the "misconfiguration" of GitHub's DNS and HTTPS, I noticed
Werner has actually added a corresponding paragraph to the WKD draft in
May 2019 (version 08):
Sites which do not use the advanced method but employ wildcard DNS
for their sub-domains MUST make sure that the "openpgpkey" sub-domain
is not subject to the wildcarding. This can be done by inserting an
empty TXT RR for this sub-domain.
Of course that only applies for someone striving for WKD conformance,
which the github.io domain has absolutely no business with. Therefore
they don't take this extra measure to suppress a failed attempt with the
WKD advanced method.
> Good question Andre! In case of github.io there is apprently no
> email address, which is IMHO a good thing if people like to
> set-up a github.io page and do not want to reveal their real
> email address, to third parties, which is IMHO their good right,
> in case they like to use this github.io pub key as multi-purpose
> key, let's say for multiple email accounts, from other services,
> file transfer, NFC postcards, you name it.
Okay, so you're using a protocol (WKD) that was purpose-designed with
e-mail in mind, but your user IDs don't work as e-mail addresses.
Despite looking exactly alike. That in itself might confuse people
(like me) using those keys. However WKD itself is not strictly tied to
e-mail, in contrast to WKS (the related Web Key Service protocol).
> Let's say as an example for gnupg.org. If am not mistaken
> dev.gnupg.org has a different cert as gnupg.org. Let's assume
> also that gnupg.org would come up with the idea of running
> keys.gnupg.org. I strongly believe that a (purchased) SSL
> cert for gnupg.org, covering wildcard subdomains, like GitHub's
> cert is neither wrong nor does it cause any security implications,
> when the direct method is used.
You need to distinguish at which level the wildcard is found. A TLS
certificate for *.gnupg.org would be perfectly fine, and even if
dev.gnupg.org uses its own even though it would be covered by the
wildcard. A fictional openpgpkey.gnupg.org server could present the
wildcard cert, just as GitHub does it. But for an
openpgpkey.dev.gnupg.org server, that would be invalid. Again, a
certificate for *.dev.gnupg.org could be used there.
There's two sides to the validity: DNS and TLS. Going back to the
GitHub example for continuity. The DNS server resolves
example.github.io to some IP address. It also resolves any
sub-subdomain like openpgpkey.example.github.io to a (probably the same)
IP address. The web server at that address presents a TLS certificate
which is issued for *.github.io. It would need to present a different
certificate for *.example.github.io in order to make a valid TLS
authenticated connection. I don't think there is something like a
*.*.github.io entry they could include in their certificate that would
cover all sub- and sub-sub-domains at once. So the HTTPS connection to
openpgpkey.example.github.io "works" on the DNS level, but has NO VALID
TLS set up, which is the "bug" / error on their side.
> Speaking of overhead, I must admit (again) I do not understand
> what this is or what this can cause for a server maintainer or
> a GnuPG or gpg4win user, when I for example can fetch my
> pub key with sequoia real quick, because in binary form these
> are only a couple of bytes and I strongly believe that a simple
> directory structure, holding some files, on a web server has no
> issues either.
I'll try to explain what happens during a WKD lookup attempt in your
preferred order, in hopefully simple terms (not 100 % technically correct).
1. The client queries DNS for the github.io domain, gets back an NS
record (a name server for the github.io zone).
2. Client asks the returned DNS server about example.github.io, gets
back an IP address for the (web) server.
3. Client contacts the web server on port 443, initiating a TLS
handshake. Gets back a TLS certificate issued for *.github.io.
4. Client checks that the contacted DNS name is actually covered by that
certificate. (OK for example.github.io, not for deeper levels)
5. Client sends an HTTP request over the established TLS connection,
asking for the well-known URL's path component. The server answers "404
Not found" or similar.
6. Client decides that the simple method failed and goes back to step 2,
this time trying the openpgpkey.example.github.io DNS name. Step 5 will
succeed this time, returning the OpenPGP certificate and public key.
Now you need to know that the "handshake" part consists of several
back-and-forth data transfers, which is why surfing over satellite links
is awful and stuff like QUIC / HTTP/2 is being developed to try and
reduce these round trips. There are also many points where things can
go wrong, e.g. the web server simply not answering on port 443 because
it is really only an e-mail server and WKD is handled somewhere else
(where we get in the second round). That involves the connection
needing to time out first. So repeating steps 2 to 5 is what I mean
with "overhead", which may very well cause user-noticeable delays.
In contrast to that, *first* querying the sub-sub-domain
openpgpkey.example.github.io would ideally return NXDOMAIN and we can
switch immediately to trying the direct method. Less time and energy
wasted.
I say ideally, because on github.io specifically, that doesn't happen.
Which is fine in itself. But the WKD spec lets us interpret that as
"cool, the openpgpkey subdomain resolved, so let's use advanced method!"
If it now fails at a later step (TLS certificate validity in this case),
sane implementations rightfully report a misconfiguration and abort,
because it may just as well be an MITM attacker fooling with the TLS
certificate.
What could be done in the WKD spec and / or GnuPG is to fall back to the
simple method not only when the openpgpkey subdomain is unresolvable,
but also if any other error happens during the advanced method. I don't
see any obvious *security* implications in that. But providers like
GitHub would then go through two complete HTTPS connections before the
client notices "WKD just isn't set up properly there". The current WKD
draft tries to avoid that duplicated server load by aborting early based
on the DNS response.
What Sequoia could do is fix their TLS host name check (step 4 above) to
only match one level with a wildcard, slightly increasing security. But
that is their call and I'm not knowledgeable enough on official TLS
validity rules to point a finger. Just GnuPG and curl choking on your
example indicates that it might be the Right Thing to do.
What GitHub could do (easily) is follow the WKD recommendation and
specifically block any "openpgpkey" sub-subdomain from resolving. Just
in case someone is crazy enough (no offense Stefan :-) to try abusing
their free web page service for WKD.
Remember it is *their* domain even if they grant you free usage of a
subdomain. And WKD specifically delegates some trust to the *domain
owner*, so they have every right to not care about OpenPGP at all and
let WKD requests fail ungracefully. Even the right to serve an invalid
wildcard certificate for sub-subdomains (which is still bad though).
Sorry for the long read, but I hope it clarifies the situation.
Regards
André
--
Greetings...
From: André Colomb <andre@colomb.de>
