1

I have my own virtual DNS infrastructure, from the root to the mail server mail.example.com. Everything is signed using DNSSEC.

client1@example.com can send email to client2@example.com, digitally signed with his certificate. As both the clients trust the same CA, client2 can validate this message.

What if the CA is compromised? Discussing the likelihood of such an event is not the point. Thus I want to add an extra layer of security. I want to add DANE record for client1's certificate.

How can I add a DANE record for email sender's certificate?

Something like:

client1@example.com   IN TLSA ...   AwAeKhf...
Vilican
  • 2,703
  • 8
  • 21
  • 35
TomatoGuy
  • 11
  • 1

2 Answers2

3

That is not what DANE is invented for. The TLSA records are to give extra security mainly to connect to transport endpoints (say, TCP ports) on named hosts, so that the certificates for host names can be independent of Certificate Authorities. With DNSSEC, this can be achieved in a cryptographically secure way.

Some people consider it a disadvantage, that someone controlling one level of domain names can control all names AND certificates present on those names. Actually the owners of the root domain (.) can securely fake any host name and with DANE, a secure certificate as well.

RFC6698 explains it this way:

DNS-Based Authentication of Named Entities (DANE) offers the option
to use the DNSSEC infrastructure to store and sign keys and
certificates that are used by TLS.  DANE is envisioned as a
preferable basis for binding public keys to DNS names...

There is (at least one) related proposal of storing the location of user PGP keys in the DNS of their mail domains in TXT records, but it's main purpose is to make it easier to find such a key, not to actually verify it.

There IS a proposed standard RFC4398 to actually store the certificates, but as it was created before DNSSEC was widespread, it does recommend against storing whole certificates if they would cause the UDP response to be bigger than 512 bytes. It doesn't seem to me it's in wide use either.

Since all user verification occurs in server software requiring additional configuration, there's usually little need to expect official CA issued client certificates, and/or a standardized way of storing additional copies of the said certificates. You're actually free to implement any such verification in your program/site.

If you think the CA compromise may make the user certificates invalid, you it may be easier add each user certificate individually as a trusted certificate instead, for example.

Community
  • 1
chexum
  • 781
  • 6
  • 10
2

DMARC and DKIM are used for the purpose you describe. No CA infrastructure is needed.

For DKIM, all you need to do is generate a public/private RSA keypair, publish the public key in DNS, and tell your signing software to use that private key.

The client will get an email with a DKIM signature in the header. It will then use embedded information to navigate to the DNS entry and get the public key. And verify

DKIM is special since it allows you to sign many email accounts with the same key. Alternatively, you can use a different scope per user and publish those keys in DNS.

makerofthings7
  • 50,090
  • 54
  • 250
  • 536