DNS-based Authentication of Named Entities
DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC). It is proposed in as a way to authenticate TLS client and server entities without a certificate authority (CA). It is updated with operational and deployment guidance in . Application specific usage of DANE is defined in for SMTP and for using DANE with Service (SRV) records. 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: However, unlike DANE, those technologies have wide support from browsers. 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 . A DANE record indicates that the sender must use TLS. Additionally, a draft exists for applying DANE to S/MIME, and standardises bindings for OpenPGP. 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 does require a Common Name match. It is important to verify if there are specific instructions for the protocol being used. RR data fields. The RR itself has 4 fields of data, describing which level of validation the  domain owner provides. E.g. codice_1 Certificate usage. The first field after the TLSA text in the DNS RR, specifies how to verify the certificate. Selector. When connecting to the service and a certificate is received, the selector field specifies which parts of it should be checked. Certificate association data. The actual data to be matched given the settings of the other fields. This is a long "text string" of hexadecimal data. Examples. The TLSA record for "www.ietf.org" specifies to check the SHA-256 hash of the public key of the certificate provided, ignoring any CA. Their mail service has the same  exact certificate and TLSA. Finally, the following example, does the same as the others, but does the hash calculation over the entire certificate.