DANE OpenPGP certificate retrieval does not verify DNSSEC signatures
Closed, WontfixPublic


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
pub   ed25519 2019-01-19 [C] [expires: 2021-01-18]
      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.


dkg created this task.Jul 10 2019, 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.Jul 10 2019, 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.

mejo added a subscriber: mejo.Aug 6 2019, 1:43 PM

I'm left wondering: are there cases where OPENPGPKEY would be preferred over WKD?

In my opinion, the main adavantage of DANE OPENPGPKEY over WKD is that the former doesn't depend on trusting a centralized CA system. Sure, you still have to trust the DNSSEC root key, but that's a way smaller attack vector than trusting *all* TLS CAs out there.

DNSSEC is a centralized CA system. Just different than the TLS one. Given that Certificate Transparency exists I'd say DNSSEC is less transparent than TLS. For example if you happen to have a .ly domain then the Libyan can silently control your signed zone. Given that there is no CT for DNSSEC they can do so selectively, for any connection they want. It wouldn't be the first problem with them.

I'd refer to the timeless Thomas H. Ptacek for further info on this matter: https://sockpuppet.org/blog/2015/01/15/against-dnssec/

dkg added a comment.Aug 10 2019, 4:24 AM

WKD and DANE/OPENPGPKEY offer rather distinct properties. I'd be hard-pressed to say that one is "better" than the other without understanding the threat model and concerns of the evaluator:

  • WKD uses the CA system, whereas DANE/OPENPGPKEY uses DNSSEC authorities
  • WKD uses a transport security model for authenticity, DANE/OPENPGPKEY uses an object security model
    • this means that DANE/OPENPGPKEY records can be proxied/forwarded, whereas WKD cannot
    • it also means that the domain operator gets to know for sure when you use WKD, but does not necessarily learn when you fetch an OPENPGPKEY record (which could have been cached)
  • DANE/OPENPGPKEY requires only the ability to fetch/receive DNS records, whereas WKD depends by necessity on both DNS and HTTPS
  • DANE/OPENPGPKEY is more likely to be transmitted in the clear today, until there is wider adoption of private DNS mechanisms like DNS-over-TLS or DNS-over-HTTPS

If you look carefully at Ptacek's anti-DNSSEC arguments (leaving aside whether they are valid arguments or not), you'll notice that many of them don't apply to this particular case. In particular, he focuses on the name-to-IP mapping problem, which is not the problem that we are addressing here.

dkg added a comment.Jun 30 2020, 9:30 PM

The same concern has been reported at https://bugs.debian.org/964033 -- if dirmngr is not going to follow the specification, it should at least document (and maybe warn?) about how it is divergent.

wiktor-k removed a subscriber: wiktor-k.Jul 1 2020, 11:55 AM
werner added a comment.Jul 1 2020, 2:10 PM

DANE for OpenPGP is an experimental RFC (RFC-7929) and it is likely that we will remove the support because it is too hard for most users to add keys to a zone. Further a validating resolver on the desktop is too hard to maintain and the cause of too many other failures. And no, unbound etc is not an option because it is not usable by the majority of GnuPG users.

werner closed this task as Wontfix.Jul 1 2020, 2:10 PM
werner claimed this task.