What is DANE Protocol?

Previously we discussed about DNSSEC. DNSSEC is a method of authenticating DNS records that also uses a chain of trust. The trust structure is identical to the DNS hierarchy. But What is DANE Protocol? DANE stands for DNS-based Authentication of Named Entities. DANE Uses the DNS System to Store Fingerprint to Certify Which CA the Domain Uses to Protect From Security Breeches. DANE is a network protocol intended to secure in a way so that the used certificates of domain can not be substituted, thus increasing the safety while transporting encrypted emails and accessing websites. With DANE either the public key or entire certificate may be put in a DNS record which specifies the certificate or public key to be used for connecting to the domain over tcp port 443.

What is DANE Protocol : Basics and RFC

If a user with a browser as a client wants to establish a secure TLS connection to a web page about https://thecustomizewindows.com and wants to ensure that the responding server is also legitimized to deliver the desired website for this, the client first checks whether that domain name is entered in the certificate provided by the server. TLS sessions require a chain of trust to authenticate the server to the client. That is commonly used method. Trusted root certificates are issued by Certificate Authorities (CA). But it is still not ensured that the certificate came from a trusted certification authority (CA). CAs are considered trustworthy, so the browser automatically uses a list of trusted CAs, which in turn as Trust Anchors for the certificate hierarchy of the client certificate. So, currently this is achieved through a series of PKIX certificates that link the server’s certificate to a trusted root certificate stored by the client. However, many serious incidents gave rise to doubts about the safety of this procedure. The administrator is bypassed to certify CAs certificates for the domain. Currently, no technical mechanism exists that can prevents any authority from signing a certificate for any domain name.

At this point is where DANE came. Clients can ask the DNS Servers which certificates can be trusted. Therefore a new DNS Resource Record named TLSA is defined. This includes a certificate in PKIX format whose fingerprint or public key is used. In this three types of responses are possible:

1. Service Certificate Constraint : The client asked to accept only a defined certificate. The certificate itself needs to check for trustworthiness.
2. Domain-Issued Certificate: The client is asked to trust the reference in TLSA record certificate. An examination of the trust hierarchy is not performed.
3. Trust Anchor Assertion: The client is asked to use the validation of the certificate from a defined Trust Anchor. The certificate must be its chain of trust to this purpose and pass the certification test.

Service Certificate constraint entries thus serve to confirm output of public Roots certificates. Domain Issued Certificates give the domain holder the possibility to issue for its own TLS-secured services. Trust Anchor Assertion is finally in self-operated in private certification of the bodies relevant to Trust Anchor.

RFC 6698 defines DANE as a way to authenticate TLS client and server entities without a certificate authority (CA). Updated operational and deployment guidance is defined in RFC 7671, RFC 7672 defines application specific usage of DANE and RFC 7673 for using DANE with Service (SRV) records. DANE can also be used by domain owners to issue their own certificates, without an existing certificate authority.

What is DANE Protocol Related DNS Record?

DANE uses a new record types called TLSA. From the text under sub header “What is DANE Protocol : Basics and RFC”, we can get four possibilities, they are types of policies :

• Usage Number 0 – CA specification – Specifies the Certificate Authority (CA) who will provide TLS certificates for the domain. We can only say that the domain will use TLS certificates from a specific CA.  Like we are using Geotrust as CA. It only will allow Geotrust. It is difficult to get a SSL/TLS certificate from Geotrust without being WE.
• Usage Number 1 – Specific TLS certificate – Specifies the exact TLS certificate that should be used for the domain. Like we are using Geotrust’s specific certificate for this domain. CA can not be from Let’s Encrypt at this moment (Let’s Encrypt recommends using 2 or 3). This should be commonest case.
• Usage Number 2 – Trust anchor assertion – Specifies the trust anchor to be used for validating the TLS certificates for the domain. It is basically for CA’s own websites.
• Usage Number 3 – Domain-issued certificate – Specifies the exact TLS certificate that should be used for the domain, but certificate can be self-signed certificate. It is basically just a security.

We can write the above as :

1. Certificate Authority Constraint (0 – PKIX-TA)
2. Service Certificate Constraint (1 – PKIX-EE)
3. Trust Anchor Assertion (2 – DANE-TA)
4. Domain Issued Certificate (3 – DANE-EE)

As Case 2 is obvious usage, that Service Certificate Constraint (1 – PKIX-EE) is commonly used. That is Usage 1 of RFC. This is called TLSA Certificate usage value.

As we can either use the full certificate or pin, we will have two selector fields :

1. Using full certificate (0 – Cert)
2. Using subject public key (1 – SPKI)

As we commonly use full certificate to generate it, it is almost always 0. This is known as TLSA selector value.

From the type of encryption, we can have :

1. No Hash (0 – Full)
2. SHA-256 hash (1 – SHA-256)
3. SHA-512 hash (2 – SHA-512)

As SHA 256 is a sane hash, 1 will be common value. This is known as TLSA Matching Type.

Above three information can be written as [number] [number] [number] like 101, 301 etc. As we are generating a hash, it is a data. Second second of information is :

1. port
2. protocol
3. domain name

We can write in this way :

If you run this command for a domain named example.com

you will get one output like ours a TLSA record :

That value 30 is time to live. Obviously, DNS provider needs to support it. Dyn does support it. How that bizarre data  :

came?

It is generated by running a command against the certificate. Obviously it is added via DNS.