DNS-based Authentication of Named Entities (DANE) is a protocol to allow X.509 certificates, commonly used for Transport Layer Security (TLS), to be bound to DNS names using Domain Name System Security Extensions (DNSSEC).
It is proposed in RFC 6698 as a way to authenticate TLS client and server entities without a certificate authority (CA). It is updated with operational and deployment guidance in RFC 7671. Application specific usage of DANE is defined in RFC 7672 for SMTP and RFC 7673 for using DANE with Service (SRV) records.
Video DNS-based Authentication of Named Entities
Rationale
TLS/SSL encryption is currently based on certificates issued by certificate authorities (CAs). Within the last few years, a number of CA providers suffered serious security breaches, allowing the issuance of certificates for well-known domains to those who don't own those domains. Trusting a large number of CAs might be a problem because any breached CA could issue a certificate for any domain name. DANE enables the administrator of a domain name to certify the keys used in that domain's TLS clients or servers by storing them in the Domain Name System (DNS). DANE needs the DNS records to be signed with DNSSEC for its security model to work.
Additionally DANE allows a domain owner to specify which CA is allowed to issue certificates for a particular resource, which solves the problem of any CA being able to issue certificates for any domain.
DANE solves similar problems as:
- Certificate Transparency
- ensuring that rogue CAs cannot issue certificates without the permission of the domain holder without being detected
- DNS Certification Authority Authorization
- limiting which CAs can issue certificates for a given domain
However, unlike DANE, those technologies have wide support from browsers.
Maps DNS-based Authentication of Named Entities
Email encryption
Until recently, there has been no widely implemented standard for encrypted email transfer. Sending an email is security agnostic; there is no URI scheme to designate secure SMTP. Consequently, most email that is delivered over TLS uses only opportunistic encryption. Since DNSSEC provides authenticated denial of existence (allows a resolver to validate that a certain domain name does not exist), DANE enables an incremental transition to verified, encrypted SMTP without any other external mechanisms, as described by RFC 7672. A DANE record indicates that the sender must use TLS.
Additionally, a draft exists for applying DANE to S/MIME, and RFC 7929 standardises bindings for OpenPGP.
Support
Applications
- Google Chrome does not support DANE, since Google Chrome wishes to eliminate the use of 1024-bit RSA within the browser (DNSSEC previously used a 1024-bit RSA signed root, and many zones are still signed with 1024-bit RSA). According to Adam Langley the code was written and, although it is not in Chrome today, it remains available in add-on form.
- Mozilla Firefox (before version 57) has support via an add-on.
- GNU Privacy Guard Allows fetching keys via OpenPGP DANE (--auto-key-locate). New option--print-dane-records. (version 2.1.9)
Servers
- Postfix
- Halon
- Exim
Services
- Posteo
- Tutanota
Libraries
- OpenSSL
- GnuTLS
TLSA RR
The TLSA RR (Resource Record) for a service is located at a DNS name that specifies certificate constraints should be applied for the services at a certain TCP or UDP port. At least one of the TLSA RRs must provide a validation (path) for the certificate offered by the service at the specified address.
Not all protocols handle Common Name matching the same way. HTTP requires that the Common Name in the X.509 certificate provided by the service matches regardless of the TLSA asserting its validity. SMTP does not require the Common Name matches, if the certificate usage value is 3 (DANE-EE), but otherwise do require a Common Name match. It is important to verify if there are specific instructions for the protocol being used.
Where to put and look for TLSA records for a service
The TLSA RR for a service at somehost.example.com will be published at _<portnumber>._<protocol>.somehost.example.com. SMTP uses port 25/TCP, so the TLSA RR for the mail service at somehost.example.com will be placed at _25._tcp.somehost.example.com. Likewise for its web service it will be placed at _443._tcp.somehost.example.com as HTTPS uses port 443/TCP.
RR data fields
The RR itself has 4 fields of data, describing which level of validation the domain owner provides.
- the certificate usage field
- the selector field
- the matching type field
- the certificate association data
E.g. _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==
Certificate usage
The first field after the TLSA text in the DNS RR, specifies how to verify the certificate.
- A value of 0 is for what is commonly called CA constraint (and PKIX-TA). The certificate provided when establishing TLS must be issued by the listed root-CA or one it its intermediate CAs, with a valid certification path to a root-CA already trusted by the application doing the verification. The record may just point to an intermediate CA, in which case the certificate for this service must come via this CA, but the entire chain to a trusted root-CA must still be valid.
- A value of 1 is for what is commonly called Service certificate constraint (and PKIX-EE). The certificate used must match the TLSA record exactly, and it must also pass PKIX certification path validation to a trusted root-CA.
- A value of 2 is for what is commonly called Trust Anchor Assertion (and DANE-TA). The certificate used has a valid certification path pointing back to the certificate mention in this record, but there is no need for it to pass the PKIX certification path validation to a trusted root-CA.
- A value of 3 is for what is commonly called Domain issued certificate (and DANE-EE). The services uses a self-signed certificated. It is not signed by anyone else, and is exactly this record.
Selector
When connecting to the service and a certificate is received, the selector field specifies which parts of it should be checked.
- A value of 0 means to select the entire certificate for matching.
- A value of 1 means to select just the public key for certificate matching. Matching the public key is often sufficient, as this is likely to be unique.
Matching type
- A type of 0 means the entire information selected in present in the certificate association data.
- A type of 1 means to do a SHA-256 hash of the selected data.
- A type of 2 means to do a SHA-512 hash of the selected data.
Certificate association data
The actual data to be matched given the settings of the other fields. This is a long "text string" of BASE64 data.
Examples
The HTTPS certificate for www.ietf.org specifies to check the SHA-256 hash of the public key of the certificate provided, ignoring any CA.
_443._tcp.www.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6
Their mail service has the same exact certificate and TLSA.
ietf.org. MX 0 mail.ietf.org. _25._tcp.mail.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6
Finally, this fake example, does the same as the others, but does the hash calculation over the entire certificate.
_25._tcp.mailserver.example.com. TLSA 3 0 1 AB9BEB9919729F3239AF08214C1EF6CCA52D2DBAE788BB5BE834C13911292ED9
Standards
- RFC 6394 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)
- RFC 6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
- RFC 7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)
- RFC 7671 The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
- RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
- RFC 7673 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records
- RFC 7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
See also
- DNS Certification Authority Authorization
Notes
References
Further reading
- DNSSEC is unnecessary - Against DNSSEC
- For DNSSEC - A rebuttal to the points in "Against DNSSEC"
External links
- List of DANE test sites
- Verisign Labs DANE Demonstration
- Online tool to check domains for DNSSEC and DANE support
Source of article : Wikipedia
0 Comments