DNS-based Authentication of Named Entities

Last updated

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). [1]

Contents

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.

Rationale

TLS/SSL encryption is currently based on certificates issued by certificate authorities (CAs). Within the last few years[ when? ], 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.

Email encryption

Until recently, there has been no widely implemented standard for encrypted email transfer. [2] Sending an email is security agnostic; there is no URI scheme to designate secure SMTP. [3] Consequently, most email that is delivered over TLS uses only opportunistic encryption. [4] 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. [3]

Additionally, RFC   8162 exists for applying DANE to S/MIME, [5] and RFC   7929 standardises bindings for OpenPGP. [6]

Support

Applications

Servers

Services

Libraries

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. _25._tcp.somehost.example.com.TLSA3110123456789ABCDEF

Certificate usage

Certificate usage value
PKIX path
validation		Target of RR
Trust anchorEnd entity
Required01
Not required23

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 of 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. [lower-alpha 1]
  • A value of 1 is for what is commonly called service certificate constraint (and PKIX-EE). The certificate used must match the TLSA record, 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 TLSA record matches the certificate of the root CA, or one of the intermediate CAs, of the certificate in use by the service. The certification path must be valid up to the matching certificate, but there is no need for a trusted root-CA.
  • A value of 3 is for what is commonly called domain issued certificate (and DANE-EE). The TLSA record matches the used certificate itself. The used certificate does not need to be signed by other parties. This is useful for self-signed certificates, but also for cases where the validator does not have a list of trusted root certificates.

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 is 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 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.

_443._tcp.www.ietf.org.TLSA3110C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

Their mail service has the same exact certificate and TLSA.

ietf.org.MX0mail.ietf.org._25._tcp.mail.ietf.org.TLSA3110C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

Finally, the following example, does the same as the others, but does the hash calculation over the entire certificate.

_25._tcp.mail.alice.example.TLSA301AB9BEB9919729F3239AF08214C1EF6CCA52D2DBAE788BB5BE834C13911292ED9

Standards

See also

Notes

  1. ↑ An uncommon example where this could be useful would be if you don't trust the root-CA completely, but many applications do still use it, and you do trust a specific of the intermediate CAs, so you list the intermediate and still get full trust path verification.

Related Research Articles

The Domain Name System (DNS) is a hierarchical and distributed name service that provides a naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T). ITU-T was formerly known as the Consultative Committee for International Telephony and Telegraphy (CCITT). X.500 was first approved in 1988. The directory services were developed to support requirements of X.400 electronic mail exchange and name lookup. The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) were partners in developing the standards, incorporating them into the Open Systems Interconnection suite of protocols. ISO/IEC 9594 is the corresponding ISO/IEC identification.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

<span class="mw-page-title-main">Public key infrastructure</span> System that can issue, distribute and verify digital certificates

A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email. It is required for activities where simple passwords are an inadequate authentication method and more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred.

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes the public key and information about it, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the device examining the certificate trusts the issuer and finds the signature to be a valid signature of that issuer, then it can use the included public key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

<span class="mw-page-title-main">Web of trust</span> Mechanism for authenticating cryptographic keys

In cryptography, a web of trust is a concept used in PGP, GnuPG, and other OpenPGP-compatible systems to establish the authenticity of the binding between a public key and its owner. Its decentralized trust model is an alternative to the centralized trust model of a public key infrastructure (PKI), which relies exclusively on a certificate authority. As with computer networks, there are many independent webs of trust, and any user can be a part of, and a link between, multiple webs.

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

The Domain Name System Security Extensions (DNSSEC) are a suite of extension specifications by the Internet Engineering Task Force (IETF) for securing data exchanged in the Domain Name System (DNS) in Internet Protocol (IP) networks. The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

S/MIME is a standard for public-key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFC 8551. It was originally developed by RSA Data Security, and the original specification used the IETF MIME specification with the de facto industry standard PKCS #7 secure message format. Change control to S/MIME has since been vested in the IETF, and the specification is now layered on Cryptographic Message Syntax (CMS), an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality is built into the majority of modern email software and interoperates between them. Since it is built on CMS, MIME can also hold an advanced digital signature.

In cryptography and computer security, self-signed certificates are public key certificates that are not issued by a certificate authority (CA). These self-signed certificates are easy to make and do not cost money. However, they do not provide any trust value.

Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents (MTA) who participated in transferring and possibly modifying a message.

Opportunistic encryption (OE) refers to any system that, when connecting to another system, attempts to encrypt communications channels, otherwise falling back to unencrypted communications. This method requires no pre-arrangement between the two systems.

Opportunistic TLS refers to extensions in plain text communication protocols, which offer a way to upgrade a plain text connection to an encrypted connection instead of using a separate port for encrypted communication. Several protocols use a command named "STARTTLS" for this purpose. It is a form of opportunistic encryption and is primarily intended as a countermeasure to passive monitoring.

Email encryption is encryption of email messages to protect the content from being read by entities other than the intended recipients. Email encryption may also include authentication.

DNSCurve is a proposed secure protocol for the Domain Name System (DNS), designed by Daniel J. Bernstein. It encrypts and authenticates DNS packets between resolvers and authoritative servers.

SMTPS (Simple Mail Transfer Protocol Secure) is a method for securing the SMTP using transport layer security. It is intended to provide authentication of the communication partners, as well as data integrity and confidentiality.

DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a "CAA" Domain Name System (DNS) resource record.

References

  1. ↑ Samad, Muhammad Alif Adha Bin (October 6, 2011). "DANE: Taking TLS Authentication to the Next Level Using DNSSEC". IETF Journal . Retrieved August 5, 2018.
  2. ↑ "Postfix TLS Support - Secure server certificate verification". Postfix.org. Retrieved 2015-12-30.
  3. 1 2 Dukhovni; Hardaker (2013-07-28). DANE for SMTP (PDF). IETF 87 Proceedings. IETF.
  4. ↑ Filippo Valsorda (2015-03-31). "The sad state of SMTP encryption" . Retrieved 2015-12-30.
  5. ↑ Hoffman, P. (May 2017). Using Secure DNS to Associate Certificates with Domain Names For S/MIME. IETF. doi: 10.17487/RFC8162 . RFC 8162 . Retrieved 2022-03-30.
  6. ↑ Wouters, P. (August 2016). DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP. IETF. doi: 10.17487/RFC7929 . RFC 7929 . Retrieved 2016-09-14.
  7. ↑ Langley, Adam (2015-01-17). "ImperialViolet - Why not DANE in browsers". www.imperialviolet.org. Retrieved 2017-03-24.[ self-published source ]
  8. ↑ Duane Wessels, Verisign (2016-05-16). "Increasing the Strength Zone Signing Key for the Root Zone". Verisign.com. Retrieved 2016-12-29.
  9. ↑ "Bind9 DNSSEC Guide". bind9.readthedocs.io. Retrieved 2021-08-22.
  10. ↑ Adam Langley (2012-10-20). "DANE stapled certificates". ImperialViolet. Retrieved 2014-04-16.[ self-published source ]
  11. ↑ Adam Langley (2011-06-16). "DNSSEC authenticated HTTPS in Chrome". ImperialViolet. Retrieved 2014-04-16.[ self-published source ]
  12. ↑ How To Add DNSSEC Support To Google Chrome
  13. ↑ "672600 - Use DNSSEC/DANE chain stapled into TLS handshake in certificate chain validation".
  14. ↑ "1479423 - support for DNSSEC/DANE/TLSA validation".
  15. ↑ Weber, Johannes (25 October 2016). "How to use DANE/TLSA". Weberblog.net.
  16. ↑ DNSSEC/TLSA Validator
  17. ↑ "GnuPG - Release Notes". gnupg.org. 12 June 2021. Retrieved 2021-08-27.[ self-published source ]
  18. ↑ "cheogram-android 2.13.0-1" . Retrieved 2021-02-11.
  19. ↑ "Postfix TLS Support - DANE". Postfix.org. Retrieved 2014-04-16.
  20. ↑ "PowerMTA 5.0 Release". SparkPost.com. Retrieved 2020-04-26.
  21. ↑ "Exim 4.91 spec: Encrypted SMTP connections using TLS/SSL / 15. DANE". exim.org. Retrieved 2018-07-05.
  22. ↑ "mod_s2s_auth_dane_in". prosody.im. Retrieved 2024-02-11.
  23. ↑ Scaturro, Michael (2014-08-24). "Protect your email the German way". The Guardian . Retrieved 2018-04-29. ... Last May, [Posteo] became the world's first email provider to adopt DNS-based Authentication of Named Entities (Dane) on its servers. ...
  24. ↑ DANE Everywhere?! Let's Make the Internet a Private Place Again, tutanota.de, retrieved 2015-12-17[ self-published source ]
  25. ↑ Richard Levitte (2016-01-07). "DANE CHANGES". GitHub . Retrieved 2016-01-13.[ self-published source ]
  26. ↑ "Verifying a certificate using DANE (DNSSEC)". Gnu.org.[ self-published source ]
  27. ↑ Osterweil, Eric; Wiley, Glen; Okubo, Tomofumi; Lavu, Ramana; Mohaisen, Aziz (6 July 2015). "Opportunistic Encryption with DANE Semantics and IPsec: IPSECA". Internet Engineering Task Force .
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.