Why Great DANE doesn’t require DNSSEC validation by default

SMIMEA as a Discovery mechanism

We at Grier Forensics believe DNSSEC validation for SMIMEA should be optional, encouraging experimentation and adoption of SMIMEA for certificate discovery.

A primary goal of DANE (DNS-based Authentication of Named Entities) is to provide a means to trust certificates without needing recourse to a third, trusted party, such as a certificate authority (CA). DANE is primarily intended as a Trust mechanism, mandating DNSSEC for authenticating DNS data. SMIMEA can be used the same way: Eliminate the need for a CA when trusting S/MIME certificates by using DNSSEC. SMIMEA originates from DANE and is therefore also intended as a Trust mechanism, however it has another usage, completely orthogonal: as a Discovery mechanism.

Say I want to correspond with you securely: How can I discover your certificate? SMIMEA allows me to easily discover your certificate using a simple DNS query. In this scenario, my mail client would expect your certificate to be signed by a trusted CA, which is perfectly acceptable. Mail clients supporting S/MIME already implement and require PKIX certification path validation using some collection of trust anchors. Rather than attempting to eliminate CA-based S/MIME in favor of DANE trust paths, we can gradually roll out SMIMEA by making DNSSEC validation optional.

This approach is in stark contrast with DANE, with respect to TLS. In TLS, there isn’t a need for Discovery: the certificate is exchanged as part of the TLS handshake. DANE addresses the issue of Trust, but Trust for TLS certificates isn’t a terrible problem: witness the fact that TLS is widely adopted using only the CA mechanism. S/MIME adoption, however, is thus far weak, possibly due to the fact that the store-and-forward nature of email doesn’t allow for automated discovery. Ergo, SMIMEA as a Discovery mechanism has unprecedented utility. Making SMIMEA DNSSEC-agnostic eliminates perhaps the largest barrier to adoption. You can and should be able to publish SMIMEA records even if you haven’t deployed DNSSEC. Until you’ve deployed DNSSEC, these records won’t be independently trusted, but they’ll still be discovered automatically and used like any other certificate.

Publishing SMIMEA records without DNSSEC is relatively easy. Using a zonecut at _smimecert enables rapid experimentation (see the example zone file below). Requiring DNSSEC, on the other hand, means domain administrators must fully secure your full domain, making experimentation difficult. Our approach allows you to experiment with SMIMEA with the full security of your CA, which you’re already using, and which your clients currently require.

Example Bind-style zone file for _smimecert.example.com:

$ORIGIN _smimecert.example.com.
$TTL 300

@   IN  SOA ns1.example.com. admin.example.com. (
            20170427    ; serial
            604800      ; refresh
            86400       ; retry
            2419200     ; expire
            604800)     ; negative cache ttl

        NS  ns1.example.com.
        NS  ns2.example.com.

; SMIMEA record for foo@example.com
2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e88 IN SMIMEA 3 0 0 (

The Great DANE Engine supports optional DNSSEC validation through its API, however we are not implementing DNSSEC validation at this time. The Great DANE Engine implementation explicitly ignores the lines in bold below, from the DANE SMIMEA draft RFC, Section 6:

6. Application Use of S/MIME Certificate Associations

The SMIMEA record allows an application or service to obtain an S/
MIME certificate or public key and use it for verifying a digital
signature or encrypting a message to the public key. The DNS answer
MUST pass DNSSEC validation; if DNSSEC validation reaches any state
other than "Secure" (as specified in [RFC4035]), the DNSSEC
validation MUST be treated as a failure.

If no S/MIME certificates are known for an email address, an SMIMEA
DNS lookup MAY be performed to seek the certificate or public key
that corresponds to that email address. This can then be used to
verify a received signed message or can be used to send out an
encrypted email message. An application whose attempt fails to
retrieve a DNSSEC verified SMIMEA resource record from the DNS should
remember that failure for some time to avoid sending out a DNS
request for each email message the application is sending out; such
DNS requests constitute a privacy leak.

An API response to a request for SMIMEA records for a given email address is formatted as follows:

  certificates: [
      data: string => PEM-encoded certificate,
      dnssecValidated: boolean =>
          - True if DNSSEC validation attempted and successful
          - False if DNSSEC validation not attempted, or DNSSEC validation fails due to lack of signing
      ttl: int, optional => TTL from the DNS record
      certificateUsage: int, optional => As per https://tools.ietf.org/html/rfc6698#section-7 and the SMIMEA spec
      selector: int, optional => See spec, as for certificateUsage
      matchingType: int, optional => See spec, as for certificateUsage

The API is specifically designed to allow DNSSEC validation to be omitted or ignored altogether. Users who choose to require successful DNSSEC validation of SMIMEA records can do so with the same API. Additionally, the Great DANE Engine notifies clients of the Certificate Usage field for the corresponding SMIMEA record, however the client is responsible for correctly interpreting this information (as required in Section 5 of the DANE SMIMEA draft RFC). Great DANE for Thunderbird, for example, will always allow Thunderbird to perform classic CA-based validation as it is designed to do, regardless of the Certificate Usage value.

DANE-based, CA-free S/MIME may eventually replace CAs, but, for now, the best way to integrate with existing email infrastructure is a CA-based approach, with DANE being an optional, second layer of security. Our goal is widespread adoption of SMIMEA for certificate discovery, which, in turn, will encourage use of secure, authenticated email. We can achieve this goal only if we promote SMIMEA as a Discovery mechanism, utilizing existing certificate validation methods and deferring mandatory DNSSEC validation.