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 (
    308203743082025C020900E76A0CF4925E133E300D06092A864886F70D01010B0500307C
    310B30090603550406130255533111300F06035504080C084D6172796C616E6431123010
    06035504070C0942616C74696D6F72653110300E060355040A0C074578616D706C653114
    301206035504030C0B6578616D706C652E636F6D311E301C06092A864886F70D01090116
    0F666F6F406578616D706C652E636F6D301E170D3137303432373138303735365A170D32
    37303432353138303735365A307C310B30090603550406130255533111300F0603550408
    0C084D6172796C616E643112301006035504070C0942616C74696D6F72653110300E0603
    55040A0C074578616D706C653114301206035504030C0B6578616D706C652E636F6D311E
    301C06092A864886F70D010901160F666F6F406578616D706C652E636F6D30820122300D
    06092A864886F70D01010105000382010F003082010A0282010100CAA1A034CBDFE931E7
    AA4AC3483C108D4D550233771D628D8089AF24B93A85968524018D147A9AF7757D117271
    4CF66A5070C03463471FE671130948D6B6DA65E1A11D7E6AF5121F1F9E890D4E2C8340E4
    0A8639AD98E05946473C3A4E8278A50A9FDE7D360543140BB2950554189042248BF71E59
    BF35BF72205B55BCC9464C1B24D6345F69C6F60B496A636398B40F7E5D03F4EB3CEA807B
    FAD766FC4997F97FB558EEA96333A1BEAD32012813AE9D7B47FD7DFC55575A79DEC2AA58
    1A1792750A2F7DD63B408EE928FAB275812EB04CA27C7A57A7162A08517BC3C876EB49B8
    8EBEF77CA526CBE787E2741630290FB44AD52FF2064CC0B6734415AAA1224B0203010001
    300D06092A864886F70D01010B050003820101009B8266A472C9A04AA8A71A102DAB14B7
    CAC1A61B4F75C55F1917BC974E7C8BA62352201221588ED5C7DFA8871A0BD7917311C3D2
    F4BC2697FCA607EBAE8A0C8208E2896DB32F14DAFE82E6B2E328E7211B57ABA9E60A4575
    CA298F83919BDA8040810830296C898E4D0D6AA35B49EEAC2C86E3BBDC1481698678E09F
    E595345DBA9A28CC002C882E18B2C5FCEA112E5FF8BAD295DA0AC50F490C256BF4E5ABC0
    BCD297A55231EF1EDC799294A2A3317FCC8FEB981E04C04E85665D35EBA32D6BAB0EF4D8
    701B96501506931A9DA7AF12C16EC17AEC238310C9DE46BE4E0C4EDFF07CE3A99ED2493E
    B6B054CC62196CF274D70C0BDBD7B4AE8B59ECEF2C3544C5)

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.

Resources: