DANE OpenPGP certificate retrieval does not verify DNSSEC signatures
Open, NormalPublic

Description

debian.org is DNSSEC-signed, and even has a delegated, signed subzone for _openpgpkey.debian.org that it now uses to publish DANE OPENPGKEY records containing OpenPGP certificates for @debian.org e-mail addresses.

By contrast, fifthhorseman.net is not currently a signed zone.

However, when i do the following with an empty homedir:

gpg --auto-key-locate dane --locate-keys dkg@debian.org dkg@fifthhorseman.net

then i end up with my certificate C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 with both user IDs attached.

I see no differentiation between the two different User IDs, even when i list them with:

0 $ gpg --with-key-origin --list-keys
/tmp/cdtemp.j9n5Yc/pubring.kbx
------------------------------
pub   ed25519 2019-01-19 [C] [expires: 2021-01-18]
      C4BC2DDB38CCE96485EBE9C2F20691179038E5C6
      origin=dane last=2019-07-10 
uid           [ unknown] Daniel Kahn Gillmor <dkg@fifthhorseman.net>
              origin=dane last=2019-07-10 
uid           [ unknown] Daniel Kahn Gillmor <dkg@debian.org>
              origin=dane last=2019-07-10 
sub   ed25519 2019-01-19 [S] [expires: 2020-01-19]
sub   ed25519 2019-01-19 [A] [expires: 2020-01-19]
sub   cv25519 2019-01-19 [E] [expires: 2020-01-19]

0 $

The fact that both of these records appear to be treated the same suggests that the DNS queries are not validating DNSSEC.

While i think that the certificate discovery via DNS is good in both cases, I think that GnuPG should be able to at least differentiate between records received with a DNSSEC chain and records without one.

Details

Version
2.2.16
dkg created this task.Wed, Jul 10, 6:48 PM
werner triaged this task as Normal priority.
werner added a subscriber: werner.

Sure it is not validated. Standard clients do not provide the system features to do that. That is one of the problems with DNSSEC adoption - it works only for servers in practice.

dkg added a comment.Wed, Jul 10, 9:44 PM

I agree, many currently-shipped DNS client library implementations do not provide DNSSEC validity checks.

As i understand it, GnuPG ships and uses its own DNS client implementations, and doesn't use the system resolver unless standard-resolver is set for dirmngr. Given that situation, the GnuPG DNS client implementation should do DNSSEC validation.

Alternately (and perhaps more maintainably), GnuPG could build against a library that already does DNSSEC validation (e.g. unbound or libknot's libdnssec), and use that library's features. That requires thinking about licensing compatibility and platform availability of course, but already things like standard-resolver are not universally-available across platforms.

Is this really necessary to duplicate functionality that already is provided by Web Key Directory?

The description of things needed to be done is already big and it needs to be tested on all systems supported by GnuPG while WKD provides more privacy in a simple, already working package.

I've seen that the PKA is deprecated but I'm left wondering: are there cases where OPENPGPKEY would be preferred over WKD? Not only setting up exotic records and DNSSEC is a lot more effort than getting a Let's Encrypt certificate I guess client support (except GnuPG) is also low.