A Step-by-Step guide for implementing DANE with a Proof of Concept
Sandoche BALAKRICHENAN, Stephane BORTZMEYER, Mohsen SOUISSI
AFNIC R&D
{sandoche.balakrichenan, stephane.bortzmeyer, mohsen.souissi}@afnic.fr
April 15, 2013
1
Context
The attacks on Certificate Authorities (CAs) such as DigiNotar [1] and Comodo [2] in 2011 have demonstrated the weakness in the current PKIX (X.509 Public-Key Infrastructure ) [3] [4] model and boosted
the discussion of using DNS leveraged by DNSSEC as an alternative PKI. These discussions led to the
creation of the DANE (DNS-based Authentication of Named Entities) Working Group [5] in the IETF.
”DANE” defines the protocol for storing TLS certificates in the DNS for a variety of applications using
them. It not only reinforces the PKIX model but also provides facilities to secure communications by only
using the DNS as an alternative PKI for certain scenarios.
The outcome of this tutorial is:
1. Implementing a ”Proof of Concept” that demonstrates the use of DANE protocol via a browser
client
2. Publishing a reference documentation which could be in the form of a tutorial that enables DANE
protocol to be implemented and understood by a wider audience
2
Motivation for working on DANE
In order to have a secure web communication (HTTPS (Hypertext Transfer Protocol Secure)), first, the
browser obtains the IP address of a domain name using the Domain Name System (DNS) infrastructure
and then it connects to the domain’s web server using the IP address to obtain a digital certificate.
The digital certificate is issued and signed usually by a trusted third party i.e. a Signing Authority 1 .
Wherever it is mentioned "CA" 2 in this document, it could mean either a CA or a subordinate CA.
The CA is used to assert to the browser that the web server is the representative of the domain asked
by the client. A Transport Layer Security (TLS) connection is established between the browser and the
web server on a successful authentication of the certificate. With the TLS connection established, the
traffic between the browser and the web server is encrypted and is protected against any third party
eavesdropping.
1
The Signing Authority may be a CA, Registration Authority (RA) or some other intermediate authority (such as a
subordinate CA) or it may be a self-signed one
2
The CA is the an integral part of the Public Key Infrastructure (PKI). PKI is an infrastructure for supporting and
managing Public key based digital certificates. The digital certificates used in the secure web communication is an example
of Public Key based digital certificate. Even though there are different PKI approaches, our focus will be on PKIX , which
is the PKI standard mostly used in the Internet
1
While establishing a secure connection to a domain, an end user has an higher probability of being
compromised while establishing the TLS connection using the PKIX rather than resolving the IP address
using the DNS 3 assuming that the domain is signed using DNSSEC.
The reason is, a browser client such as Firefox for example trusts 1,482 CA Certificates (as per SSL
observatory [6]) provided by 651 organizations. Even if only one of them is compromised, the compromised
CA can generate a certificate for any domain name which will be authenticated by Firefox, and thereby
compromising a secure web communication of an end user who is using Firefox as browser. For instance,
multiple CAs can (and in fact has been) issue multiple certificates for www.google.com which will then
be trusted by the browser. The fault here, is that the domain owner had up to now no way of telling the
world how the domain server should be authenticated (for example using a particular CA or certificate).
The DANE WG have developed a new type of DNS record called Transport Layer Security Authentication (TLSA), that allows a domain owner to sign statements about which entities are authorized to emit
certificates on their behalf. End users applications can use these records either to augment the existing
system of CAs or to rely alone on the additional chain of trust, rooted in the DNS. Two RFC’s relating
to DANE have been published by the IETF:
1. DANE Use case RFC 6394 [7] and
2. DANE Protocol RFC 6698 [8]
This tutorial will focus on different steps involved in implementing DANE both at the client and at
the server end. The example in this document will involve implementation of DANE using a web browser
client, but, it should be noted that DANE is also not limited to web, and may be used on any TLS
connection.
3
Background
In the motivation [section 2], a brief introduction to the issue pertaining to the PKIX is provided. This
section will further explain the issue with an example and then briefly demonstrate how DANE is a
solution.
When an user types a URL: https://dane.rd.nic.fr in his browser, then the browser performs the
following steps (as shown in Figure [1]):
1. Step 1 : Obtain the IP address of the domain requested
2. Step 2 : With the help of the obtained IP address, the browser connects to the domain’s web server
and obtains the digital certificate
3. Step 3 : The browser validates the certificate with the CA mentioned in the certificate. The CA
mentioned should be trusted by the browser 4 and valid otherwise it will trigger an alert.
As shown in Figure [1]
5
, there are two types of attacks possible:
1. Type 1: An attacker could use various tactics (e.g. Cache poisoning) in step ”1” (Figure [1]) to
provide a rogue IP address to the browser
3
The Compromise of a particular domain name at the DNS infrastructure can occur only at the particular registry, registrar
or at the hosting provider , hence reducing the attack surface
4
Each web browser by default has a pre-installed list of CAs certificate and the browser client trusts all the digital
certificates signed by those CAs
5
The Orange color is to point the danger and the yellow color to show it is an issue
2
Figure 1: Web browsing Without DNSSEC and DANE
2. Type 2: The ”s” at the end of ”http” indicates that the browser is connecting to the domain’s
web server via TLS (which is the successor of SSL developed by the IETF). During the initial
communication (TLS handshake) between the browser and the web server, the server responds to
the client by presenting PKIX digital certificate . The certificate is meant to assert that the server
is the representative of the domain asked by the client. The browser evaluates this certificate to
decide whether the server is fraudulent or not. This decision is normally based on two criteria:
• Whether the certificate contains the desired domain name and
• Whether the certificate is issued by a trusted CA.
As mentioned earlier, Web browsers (e.g. Firefox, Chrome etc..) come with a default list of trusted
CAs. The number of CAs trusted by a browser varies, and there are examples of up to 1500 distinct
CAs trusted by a browser. If an attacker has been able to compromise any of the CA (out the many
CAs) trusted by the browser, then he/she/they can create a fraudulent certificate for any domain
(for e.g. www.example.com). Further, when a user is connecting to www.example.com, if the attacker
has the means to be the Man In The Middle (MITM), he/she/they can send the created fraudulent
certificate to the end user. Since the fraudulent certificate is created by a CA which is trusted by
the user’s browser, the browser will accept the certificate and the credentials sent by the attacker.
This could help the attacker to redirect the user to a spoofed server. During the communication
between the end user and the spoofed web server, the attacker could steal the data of the user such
as login, password, bank details etc.
As explained in the motivation [Section 2], such attacks have already occurred. It has to be noted
that the issue is not the security of the PKIX technology, but with such a big list of the CAs accepted by
the browser’s there is a higher probability of being compromised. With PKIX, a domain owner does not
have the possibility of telling the browser that any user connecting to his domain should be validated by
a certificate provided by a particular CA.
With the issues explained, let us now to look at the solutions. Type 1 attack (at step 1 in (Figure [1]))
is mitigated by DNSSEC. As explained in the motivation [Section 2], the DANE WG at the IETF was
3
conceived to mitigate ”Type 2” attack (at step 2 and 3 in (Figure [1])). DANE protocol with DNSSEC
allows applications to provide a trust path using security provided by the TLS which hasn’t really been
possible before. Using DANE protocol, a domain owner will sign the certificate provided by the web server
based on different options (Refer Section 3.1) and add it to the domains zone, thus enabling the domain
owner an option of informing the application (e.g. browser) on how to validate the certificate obtained
from the web server. For example, if the domain www.example.com CA is ”X”, with DANE mechanism,
the browser will only accept a certificate from ”X” for authenticating the server, thus, reducing the attack
probability. DANE also enables domains using self-signed certificates to secure the communication between
the web server and the browser within the DNS infrastructure (Bypassing the CA ecosystem).
3.1
TLSA Resource Record (RR)
The first focus by the DANE WG was to standardize the TLSA Resource Record (RR) [8]. The basic
role of this record is to exist in a DNSSEC signed zone, and to indicate the certificate information that
corresponds to a specific service on a specific port of a name in that zone. As shown in Figure [2], the
RDATA (RR specific data) for a TLSA RR consists of a certificate usage field, a selector field,
a matching type field and the certificate for association data field:
Figure 2: TLSA Resource Record Explained
Before further digging into the TLSA RDATA , it should be noted that the payload of the TLSA RR
(i.e. the Certificate for association as shown in Figure [3]) MUST be matched with the certificate given by
the web server. The certificate provided by the server is identified as "Target Certificate". The fields
Usage, Selector, Matching type determines how the matching between the payload (i.e. the Certificate for
association in the TLSA RR) and the target certificate is done.
Figure 3: TLSA Resource Record in Wire-Format
• Usage [Refer Table:1 for further explanation] - Also called as Certificate Usage field describes how
the target certificate should be matched with the ”Certificate for association” payload in the TLSA
RR (’3’ in Figure:2)
4
Value
0
1
2
3
Table 1: Usage explained
Meaning
’0’ in the certificate usage field informs the application (e.g. browser) that it should perform
the PKIX validation (i.e. validating a domain’s certificate using the CA ecosystem) and during
the PKIX validation it should use the CA certificate that matches the TLSA RR obtained from the
DNS zone of the domain. This usage helps to pin a CA to a domain thus limiting which CA can be
used to issue certificates for a domain.
Same as ’0’, but adds another level of security wherein the target certificate must match the
payload in the TLSA RR (e.g. Validate only with the specific certificate
from a specific CA for a domain)
Useful while a domain is using its own CA which is not listed with the browsers. For example,
an organization has planned to create its own CA and each of the department in the organization
creates its own self-signed certificates with the created CA as trust anchor for their
respective department web sites. Browser’s such as Firefox, Chrome will not trust the organization
department web site since it does not have the organization CA in its list of trusted CA. The TLSA
RR is received by the application (i.e. browser) as a result of DNSSEC validation. Hence, it is sure
that the TLSA payload is not forged unless and otherwise someone has access to the DNS zone.
The application (e.g. browser) while performing the certificate validation has to make sure that
the CA of the target certificate is the same as that of the TLSA payload received.
There is no PKIX validation. There is no CA involved. Domain administrator issues the self-signed
certificate which is stored as target certificate in the server and a fingerprint of the certificate is
added in the domain’s zone as the certificate association payload of the TLSA RR. The application
authenticates the server once the target certificate matches the TLSA payload.
• Selector [Refer Table:2 for further explanation] - Describes what part of the target certificate will
be matched against the ”Certificate for association” data (’0’ in Figure:2)
Value
0
1
Table 2: Selector explained
Meaning
Indicates the certificate association data field contains the full target certificate
Indicates the certificate association data field contains only the Subject Public Key Info [4] of the
target certificate
• Matching type [Refer Table:3 for further explanation] - Describes how the ”Certificate for association” data is matched (’1’ in Figure: 2)
Value
0
1
2
Table 3: Matching type explained
Meaning
indicates that the application has to match the target certificate and the payload at
the certificate association data field exactly
Indicates that the SHA-256 algorithm is applied on the target certificate and the
result (i.e. the hash) is matched with the payload at the certificate association data field
Indicates that the SHA-512 algorithm is applied on the target certificate and the result
(i.e. the hash) is matched with the payload at the certificate association data field
5
3.2
DNSSEC is essential for DANE
As specified in the DANE protocol RFC [8], the TLSA RR resulting from a DNS Query must be validated
by DNSSEC. It is MUST that the zone which has a TLSA RR must be signed by DNSSEC and the
applications which query the domain for TLSA RR validation should use a DNSSEC aware resolver.
4
State of Art
Attacks on popular CAs such as comodo [2] and diginotar [1] trusted by default in popular web browsers
and operating systems have led many to question the state of trust in the PKIX. There have been calls for
reevaluating PKIX either providing an alternative or reinforcing the CAs behind the TLS system. Some
of them include Perspectives [9], Convergence [10], Public Key Pinning [11] and Certification Authority
Authorization (CAA) [12] RR in DNSSEC.
Now that DNSSEC has been deployed at the DNS root and by several Top Level Domains (TLDs), the
IETF and various other groups started considering the possibility of replacing/reinforcing CA certification
model with one based on the secured DNS. At the IETF 78, there was a Birds of a Feather (BoF) meeting
on the topic under the title (TLS @DNSSEC) which was organized to discuss how to establish a chain of
trust from DNSSEC root to to the root CA certificate. At IETF 79, the same topic was discussed under
the name Keys In DNS (kidns). Following these discussions a WG was formed in the security area. This
WG got the name DANE [5] and was officially announced at the end of 2010.
As mentioned in the motivation [section 2], two RFC’s [7],[8] relating to DANE have been published
by the DANE WG . There are other drafts in process which look at how DANE mechanism could be
used for Secure/Multipurpose Internet Mail Extensions (s/MIME), Post Office Protocol (POP3), Internet
Message Access Protocol (IMAP) and Simple Mail Transfer Protocol (SMTP).
To implement DANE, TLSA RR(s) should be created for a domain and payload of the TLSA RR
should be matched with the target certificate subject to its different options as explained in the section
3.1. SWEDE [13] is a tool to create and verify TLSA RR’s based on different usages. An example is shown
in sections [5.2.3]. SWEDE developer mentions that it is mostly untested and the last update made to the
SWEDE tool is on April 2012 (as of 17/01/2013). Openssl-dane [14] is another tool similar to SWEDE
where it validates the TLSA record using OpenSSL. There is a ”dane” module added to the SSHFP [15]
tool which allows creating TLSA RR(s) for a domain as explained in section [5.2.3].
As mentioned in section 1, our aim is to implement the proof of concept for DANE using a browser.
The browser needs to have a DANE module which does the verification part. As of now there are two
working browser implementations of DANE - both for Firefox. DANE add-on for Firefox [16] is explained
in detail in section 6. CZNIC [17] has published a add-on for Firefox called ”DANE patrol” which has
been tested. Since this add-on for Firefox was published at the end of the project in 2012, it has not been
further evaluated which could be done during the second version of this document in 2013.
5
Implementation Description
The task for implementing the DANE demonstrator is described in three sections:
1. Platform set up
2. Implementing the components necessary for DANE set up at the server end
3. Implementing the add-on at the browser client (for Firefox)
6
5.1
5.1.1
Platform set up
Naming plan
For convenience of testing, the domains that will be chosen for the DANE demo will be delegated under
AFNIC’s R&D DNS namespace ”rd.nic.fr”. As explained in section 4, the demonstrator will test an
upgraded version [22] of the Firefox add-on [16] for DANE. Two distinct domains have been used for
testing the Firefox add-on: one to test it is working under various criteria and another to test the broken
scenarios. The domain’s used are mentioned below:
Table 4: Naming
Domain Name
DNSSEC
dane.rd.nic.fr
OK
dane-broken.rd.nic.fr OK
Plan
Target Certificate
Self-signed certificate
Self-signed certificate
There is no CA involved in the testing of the above domains. Hence the demonstrator will test only
usage ’3’ [Refer section 3.1]
5.1.2
Addressing plan
As explained in [Table:5] all test domains are accessible both in IPv4 and IPv6.
Table 5: Addressing plan
Domain Name IPv4
IPv6
dane
192.134.7.155 2001:67c:2218:6::7:155
dane-broken
192.134.7.157 2001:67c:2218:6::7:157
5.1.3
Filtering rules
All the domains used for test will be accessible on port 53 (DNS) , port 80 (http) and port 443 (https).
5.1.4
Initial Configurations
Both IPv4 and IPv6 addresses [Mentioned in the section 5.1.2] for the demo are added to a physical host
"telma.rd.nic.fr" : debian 6.0 (squeeze). BIND DNS software implementation is used at the server
end for all the domains [Mentioned in the section 5.1.1]. There is a separate instance of named running
for each domain on "telma.rd.nic.fr" for this demo. Apache is configured on telma so that it listens
to all domains both on IPv4 and IPv6. On "telma.rd.nic.fr", the important directories are:
1. For DNS - /etc/dane (BIND conf) and /var/dane (dane zone)
2. For apache - /etc/apache2/
3. For SSL certificates - /etc/dane/CA
5.2
Setting up Components necessary for implementing DANE at the server end
At the server end, we need to implement three steps (from Step:1 to Step:3) as described in Figure 4.
7
Figure 4: Steps for implementing DANE for the demo
5.2.1
Step 1 : Enabling DNSSEC
Different steps in setting up DNSSEC for the test domains are explained in this section. Configuration
involved in this section is done at the authoritative server for each domain and at the recursive nameserver.
First step is to check whether the parent for the domain is signed. If it is true, the complete tree is
checked for each parent until the TLD [Table:6]. In the case of the DNS Root, it is a known fact that it
is signed.
Table 6: DNSSEC verification
Test Type
Verifying whether the ccTLD ”fr” is signed
Verifying whether ”nic.fr” is signed
Verify whether ”rd.nic.fr” is signed
for the parent zones
Command used
dig +short dnskey zone
dig +short dnskey zone
dig +short dnskey zone
Status
Done
Done
Done
The second step is to enable DNSSEC on authoritative servers of each of the domain ( "dane.rd.nic.fr",
"dane-broken.rd.nic.fr". Once it is signed it can be checked using the same technique as it has been
done for validating the parents. An example of the Zone-Signing Key (ZSK) and the Key-Signing Key
(KSK) for the domain "dane.rd.nic.fr" is shown here:
dane.rd.nic.fr. IN DNSKEY 256 3 5 AwEAAeI3FfKI+96FXufElXWspcxnp6LEt6S2FVESAbV5pPUb9hbP6oJU yakxwc9hRAQWtjs+ziqRnD8CEnYUjEQUqhV9UO2MDpAWO722RiiyxRXU
SH/7qnP4/EWeSNEzFT+zDsuRzWa9D68xtGKfKtdjnKNS8bS8ApgaxXUr n/TMY19//
dane.rd.nic.fr. IN DNSKEY 257 3 5 AwEAAd4dVcbYLRV6IDO6Icw4Es5HSVY6rfGB4iNTbw+Y84G2YS7nYGzi
m0mMICITf1HjA+vdtsAmbUbeyVdKVTQ2Z52HqvVh4lMYJ9pO8ENzUay9
t17PV5t8jMOtBjE9tblmXzBedYYb6ZQRS2CBs7u+4sxO3O+r+wfkoTga
ciqQzg8saUb5ZavHzyzh6hMjo16GuqE+yLbLPAPedmXt2ZIjU3L+yGHB
0hZCEcpbNCs1ru9UbTpVlQpQIu9w0Uk5gozF/yUaCr/fKFEZjRvG/x02
fKtZE2krqbr1SCCjslVSY6wTQavwrhIhYWknBxkUKZ+mgzSW8LwKyJU6
nD8rjiSXERyiimsJ0xWUoCuzm9DRVmtDR1Qy0YEIjceajOM45xis+xol
BgQWfIfbyA+NouOvECWOH6KvI05IT4hAaaqUnBU47bG9imuFmytFpgL9
XCheXUP1W3j+In/KpZ2zCVt5Iefvyodq4WgQKU8gTbbw2DTVmqWphBlc
r2Me9uIblLkLhnosAKOfEfXHcYY2r1i/jGyyGg/Mci10KiVkIZ9MUWYr
vJ4DgYdw9BEvV+JWipBsaXXlEa/NbZNIqs3XAbHsTGNHET6pJkfpc/jy
rSkaNN3Biic//aNFFnyuNhuqCtR1jdXujkVTTTIRJJ8uaLHYQiQU13w1 d8CtZgc4qHqOqA7L
The third step is to add the the Delegation Signer (DS) records for the four domains at its parent
zone "rd.nic.fr":
dane.rd.nic.fr.
dane.rd.nic.fr.
dane-broken.rd.nic.fr.
dane-broken.rd.nic.fr.
IN
IN
IN
IN
DS
DS
DS
DS
44626
44626
36829
36829
5
5
5
5
1
2
1
2
AE983EBAD81130C170AE2AF2393D6EEF4FA2F97E
82F3FE7BF385A40E9876364FEEFA017CDAED7A1FB85256F2D63EE4D3 092021B7
BA5CC64D793299050B214D941CA29FE27687D99E
DA3B395E8224932FD02CDECEE2303BFDF8BCF3BD5FC6C2462CA645CF F8D20B7B
8
As explained in section 3.2, the resolver should be enabled for DNSSEC validation. In the case of BIND
the configuration depends on version. Starting with BIND 9.7.0, the trusted keys can be managed by the
process of automated updates of DNSSEC trust anchors as explained in RFC 5011 [19]. An example of
how the root ”.” trusted keys are added to a recursive resolver is shown below:
managed-keys {
"." initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
};
Note: Enabling the resolver for DNSSEC is not needed for the demo explained in this tutorial, since
the add-on in Firefox has in itself a DNSSEC aware resolver.
5.2.2
Step 2 : Set up TLS for the domain
Configuration involved in this section is done at the Web Server for each domain. For setting up TLS, the
first step is to enable the web server to accept both requests on port 443 (TLS) and 80 (http) and install
TLS in case it is not installed. An example from the ports.conf file (using apache) shows the addition:
NameVirtualHost *:80
<IfModule mod_ssl.c>
Listen 443
</IfModule>
The next step is to create the certificate. Normally there are two options
1. Create a CA and sign a server certificate with it for each domain or
2. Self-sign a server certificate without a CA.
The domains used for the demo have self-signed certificate without a CA. There are two reasons for
choosing option (2) for the demo. Our primary objective as part of this work in 2012 is to demonstrate
that the DANE protocol can be implemented in a browser and to prove that users can have a secure web
connection without the PKIX ecosystem.
The second reason is that the tools to create the TLSA RR concentrated on the Usage 3 (Refer section
3.1) , as a result of which, their implementation for other usages were either buggy or not implemented.
For further explanation on generating a self-signed certificate and then finally configuring the SSL virtual
host for each domain please refer to [20].
5.2.3
Step ”3” - Creating the TLSA RR
Section 3.1 explained the TLSA RR and its relation with the DANE protocol. An example of the TLSA
RR which is added to the domain’s zone is shown here:
_443._tcp.dane.rd.nic.fr. IN TLSA 3 0 1 e781577c0eabb6701a0caf287e48ceebd3ba64b81792ef49705f0f5e1070331b
There are different tools available which can be used to create a TLSA RR for a domain name. These
tools can be installed in any host and run to create the TLSA RR. The only necessity is that they should
be connected to the Internet. This section details how TLSA RR is created with the help of two such
tools.
As explained earlier (Section 4), SWEDE is a tool developed to create and verify TLSA RR’s. SWEDE
can be used to create/verify different TLSA records based on different usages. One has to be careful in
9
choosing the parameters to create the TLSA RR. A mis configured TLSA RRset will effectively disable
access to the TLS server for all conforming clients. Since the demo (as of now) concentrates on Usage ”3”,
the command used to create the TLSA RR is as follows:
./swede create --usage 3 --output rfc dane.rd.nic.fr
The result of the above command is as follows:
Attempting to get certificate from 192.134.7.155
Got a certificate with Subject: /C=FR/ST=SQY/L=Montigny/O=AFNIC/OU=ReD/CN=dane.rd.nic.fr
_443._tcp.dane.rd.nic.fr. IN TLSA 3 0 1 e781577c0eabb6701a0caf287e48ceebd3ba64b81792ef49705f0f5e1070331b
Attempting to get certificate from 2001:67c:2218:6::7:155
Got a certificate with Subject: /C=FR/ST=SQY/L=Montigny/O=AFNIC/OU=ReD/CN=dane.rd.nic.fr
_443._tcp.dane.rd.nic.fr. IN TLSA 3 0 1 e781577c0eabb6701a0caf287e48ceebd3ba64b81792ef49705f0f5e1070331b
The tool connects to the specified domain name (e.g: ”dane.rd.nic.fr”) both in IPv4 and IPv6 to
verify whether it is a valid domain. Then it retrieves the TLS certificate from the domain’s web server.
Depending on the parameters (such as usage, selector etc) provided, it creates the TLSA RR. The obtained
TLSA RR is provisioned in the DNS zone of the domain. It should be noted that even though the tool
creates the TLSA RR twice, each for IPv4 and IPv6 connection, they are both identical since they are
created based on the same certificate from the web server of the domain. Hence, only one TLSA RR is
added to the DNS zone.
Similar to SWEDE there is a dane module added to the SSHFP tool to create and verify TLSA RR’s.
The TLSA RR obtained using dane module from sshfp tool is as follows:
dane --rfc dane.rd.nic.fr
_443._tcp.dane.rd.nic.fr IN TLSA 1 1 E781577C0EABB6701A0CAF287E48CEEBD3BA64B81792EF49705F0F5E1070331B
As in the ”SWEDE” tool, the option ”rfc” is used to generate the TLSA RR as specified in RFC 6698
[8]. The idea of using the ”dane” module in addition to SWEDE, is to check whether the result (TLSA
RR generated) is identical for both the tools. But only the payload (i.e. the Certificate for association)
field is identical for both tools. As of the time of writing, it is not clear how to specify the options (such
as Usage, selector and matching type) with ”dane” module while creating the TLSA RR.
Note: Once the TLSA RR is created it should be added to the domain zone and the zone should be
re signed.
6
Step ”4” - DANE demo: Analysis of Firefox browser with extended
DNSSEC validator
In the previous section, we have tested using existing tools for the creation/validation of TLSA RRs.
But, as explained in the context [section 1], our objective is to implement a ”Proof of Concept” that
demonstrates the use of DANE protocol via a browser. This section will focus on implementing the
”Step:4” as shown in Figure 4.
At the client end, the browser should be capable of performing DNSSEC and TLSA validation. In
our search we found that no browser support DANE natively. There are add-on’s for Firefox and in
this section we test an upgraded version [22] of the Extended DNSSEC validator[16] add-on. In addition
to DNSSEC validation, the add-on checks for the existence of TLSA records in the domain’s zone and
validates the TLSA record with the certificate obtained from the domain’s server based on the TLSA
usage specified. The add-on comes with a DNSSEC enabled unbound resolver. The advantage of having a
resolver embedded with the browser will appeal to a larger public. Any user wanting to implement DANE
on their browser client need not worry about enabling DNSSEC either in their host or at their Internet
Service Provider (ISP). On installing the upgraded version of add-on [22] in Firefox and launching the
domain ”dane.rd.nic.fr”, the result is as shown in (Figure:5). The result (”Domain name is secured by
DNSSEC and the certificate is validated by DNSSEC”), demonstrates that the test domain is validated
for DNSSEC as well as TLSA.
10
Figure 5: Screen-shot of the test domain with Extended DNSSEC validator
In case of a self-signed certificate as it is in our test and the connection is on a secure channel
(”HTTPS”), the add-on verifies if the trust can be obtained from the DNS using DNSSEC. If it can
be trusted based on a validated data from the DNS, an exception for the certificate is passed to the
browser. This exception will disable the self-signed certificate warning and the end-user will be able to
browse a secured version of the domain. Without the Extended DNSSEC validator add-on, Firefox will
display the exception (Figure:6) for the same domain.
Figure 6: Screen-shot of the test domain without the Extended DNSSEC validator
On understanding the add-on successfully validates a valid domain which is configured properly for
DANE, we further conduct some tests to determine whether the add-on is programmed to satisfy certain
other criteria with respect to a DANE implementation. The criteria for the tests are :
1. Whether the add-on identifies broken DNSSEC domains
2. Successful TLSA validation with respect to the following:
• Does the add-on identifies a broken TLSA RR during the course of matching
• Normally, DANE mechanism should satisfy all the four usages explained in section 3.1. The
domain that is tested as shown in the Figure 5 is limited to Certificate Usage ”3”. Here the
test is done to verify whether the add-on support other certificate usages.
• Test whether the add-on supports DNS alias i.e. CNAME (Canonical Name) RR
• Test whether the add-on supports wildcards
11
6.1
DNSSEC Validation
Two tests are conducted here:
1. Test1 - To test whether the add-on validates, when the signature used to sign the domain’s zone is
broken (i.e. corrupt or expired)
2. Test2 - To test whether the add-on validates, when there is a bogus RRSIG (Resource Record digital
SIGnature) [23] in the domain’s zone
Table 7: Testing DNSSEC validation with extended DNSSEC validator add-on
S.NO
Test1
Test2
What is done
Launch the domain
www.dnssec-failed.org
Launch the domain
dane-broken.rd.nic.fr
How is it broken
”www.dnssec-failed.org” is a domain provided
by Comcast with a deliberately broken signature
A bogus RRSIG
record is added
Result
Page does not load
Domain name is secured
by DNSSEC and the certificate
is validated by DNSSEC
For the ”Test2” which failed (Table 7), the bogus RRSIG is added deliberately for a ”A” type DNS
record [24] and not for the TLSA RR. Even though The TLSA RR is valid, this issue should be fixed in
the add-on, since in the case of the browser using a proper DNSSEC capable resolver (not the extended
DNSSEC validator add-on) will not be able to connect to the server and retrieve the IP address, as the
domain zone is provisioned with a bogus RRSIG for ”A” record.
6.2
TLSA Validation
Table 8: Testing the add-on with a broken TLSA RR
What is done
Launch the domain
dane-broken.rd.nic.fr
How is it broken
Deliberately corrupt the TLSA record. The certificate
offered by the server (6e013c54df90d42d3c016e1
ac9eb21e6da45403d3a5ae9b2d8f21fc3600d409c)
Does not match the TLSA record in the DNS zone (6e013c54df
90d42d3c016e1ac9eb21e6da45403d3a5ae9b2d8f21fc3600d409d)
but the domain is correctly signed with DNSSEC
Result
Domain name is
secured by DNSSEC but
the certificate has
an invalid signature
The add-on successfully identifies when the target certificate and the TLSA RR in the DNS zone does not
match for ”Usage:3”.
6.2.1
TLSA Validation for certificate usage other than ”Usage:3”:
Even though we have limited to the ”Usage:3” for TLSA validation (Figure 5), the test here is to check
whether the add-on validates ”Usages” other than 3 in the TLSA record. The result (Table:9) proves that
the add-on validates only Usage 3 and does not bother for values other than ”3” in the usage field.
Table 9: Test the add-on for Usage other than ”Usage:3”
Domain Name
Launch the domain
dane-broken.rd.nic.fr
6.2.2
How it is broken
The TLSA record is correct. The domain is correctly signed with DNSSEC.
But the TLSA parameters are incorrect. For the certificate,
the TLSA parameters are: Usage:1, Selector: 0, matchingType: 1
whereas it should be Usage:3, Selector: 0, matchingType: 1
How the Firefox browser reacts
Domain name is secured by
DNSSEC and the certificate is
validated by DNSSEC
TLSA Validation with CNAME [25]:
It is a common technique in DNS to have a domain name aliased to another. The use of aliases provides number of advantages and this option is provided by CNAME RR. A brief view of the domain
dane.rd.nic.fr zone file used for testing CNAME is as follows:
12
www.dane.rd.nic.fr.
IN A
192.134.7.155
IN AAAA
2001:67c:2218:6::7:155
; Specifying the alias
test.dane.rd.nic.fr.
IN CNAME
www.dane.rd.nic.fr.
The question arises how/where a domain owner will provision the TLSA RR’s. For the above example,
the right-hand side of the DNS entry is the Canonical name i.e. "www.dane.rd.nic.fr." and the lefthand side is the Owner name i.e. "test.dane.rd.nic.fr.". There are three possible scenarios for
provisioning the TLSA RR:
1. Scenario:1 The TLSA RR is provisioned for the Owner name (left-hand entry)
_443._tcp.test.dane.rd.nic.fr. IN TLSA 3 0 1 c68ebcc998fda83222cabf2c0228ecc413566e709e5dc5cf25396a8bf4342dd3
2. Scenario:2 The TLSA RR is provisioned for the Canonical name (right-hand entry) and no TLSA
RR for the owner name
_443._tcp.www.dane.rd.nic.fr. IN TLSA 3 0 1 c68ebcc998fda83222cabf2c0228ecc413566e709e5dc5cf25396a8bf4342dd3
3. Scenario:3 The TLSA RR is provisioned for both owner and canonical name
Both scenario 1 and 2 have the same TLSA RR while creating the TLSA RR, for example with the
tool ”SWEDE”, the TLSA RR is created from the (single) target certificate present at the domain’s web
server. The motivation here is to test whether the add-on successfully does TLSA validation for the above
three scenarios.
Table 10: Test the add-on for CNAME scenarios
S.NO
Test1
Test2
Test3
Test4
Test5
What is done
Scenario:1 and open the Owner name ”test1.dane.rd.nic.fr”
Scenario:1 and open the Canonical name ”www.dane.rd.nic.fr”
Scenario:2 and open the Owner name ”test1.dane.rd.nic.fr”
Scenario:2 and open the Canonical name ”www.dane.rd.nic.fr”
Scenario:3 and on opening both Owner and Canonical name
How the Firefox
It shows that both
Invalid Certificate
Invalid Certificate
It shows that both
It shows that both
browser (with the add-on) reacts
DNSSEC and TLSA validation is ”OK”
DNSSEC and TLSA validation is ”OK”
DNSSEC and TLSA validation is ”OK”
Both ”Test 2” and ”Test 3” failed because the the add-on after retrieving the TLSA RR from the
DNS server, matches the domain name in the TLSA RR with the domain name used by the browser for
querying. On finding that they don’t match, the add-on relinquishes control to the browser which on
identifying it as a self-signed certificate throws the invalid certificate exception.
6.2.3
TLSA Validation with Wildcards [26]:
Like CNAME (mapping a domain name to another), wildcards could make life easier for DNS administrator
in mapping many domain names to one even though its usage should be carefully applied . Testing TLSA
validation for wildcards, the TLSA record in the DNS zone of the test domain (dane.rd.nic.fr) is as follows:
*._tcp.dane.rd.nic.fr IN TLSA 1 1 1363863718D7D8752336636DACFB432E994705872EAC9A3A6586BD109D5C5466
Table 11: Test the add-on for wildcards
What is done
Launch dane.rd.nic.fr
How the Firefox browser reacts
”Invalid domain name signature has been detected”
The validation seems to have failed by the unbound libraries in the add-on.
What we understand from testing the extended DNSSEC validator add-on is that the add-on as it is
now is yet ready for a production environment.
13
7
Conclusion
From this work we have achieved the following :
• A DANE demo set up for testing valid as well as broken sites
• The current document which would be used as a tutorial. Such a document has been in demand in
the DANE mailing list
• Providing feed-back to the add-on developers for DANE
The Firefox Extended validator add-on is a good beginning for incorporating DANE mechanisms in a
browser. But it seems to have been developed with specific goals - for example, just to demonstrate that
DANE mechanism is feasible in a browser. The source code for this add-on seems not to be modular and
as pointed out earlier it assumes certain properties for validation. Our focus had been to test the add-on
under various scenarios (even though it may not be exhaustive) and help the community to take all these
issues into account while upgrading the existing implementations or while developing a new one.
7.1
Prospective work
The DANE protocol as of now seems to be a promising mechanism for the deployment of DNSSEC. The
Deploy360 Program (for the promotion of DNSSEC) by the ISOC has incorporated DANE into this effort.
We identified quite early that DANE could become the promising application only if its use is experienced
by normal users. Hence, we started working on the add-on’s for DANE in browsers. Even though there
are partial efforts to implement DANE in browsers, it is important that the browser vendors support it
natively. To support it natively, they need to know that their users need it. This is where comes the
importance of people who actually publish the TLSA records and that is where our role (AFNIC) comes
into focus, educating the registry community of publishing TLSA records. It may take some time for
normal usage of DANE, but it is important that we should follow this effort until the technology reaches
normal end users.
8
Acknowledgements
Phil Regnauld and Niall O’Reilly have provided input and suggestions to this document.
References
[1] http://www.rijksoverheid.nl/ministeries/bzk/documenten-en-publicaties/rapporten/2011/09/05/diginotarpublic-report-version-1.html
[2] http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
[3] IETF PKIX, in http://www.ietf.org/html.charters/pkix-charter.html
[4] David Cooper, Stefan Santesson, Stephen Farrell, Sharon Boeyen, Russell Housley and Tim Polk; RFC
5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile, May 2008
[5] DANE Charter, http://datatracker.ietf.org/wg/dane/charter
[6] https://www.eff.org/observatory
14
[7] R. Barnes; RFC 6394 - Use Cases and Requirements for DNS-Based Authentication of Named Entities
(DANE)., October 2011
[8] P. Hoffman, J. Schlyter ; RFC 6698 - The DNS-Based Authentication of Named Entities (DANE)
Transport Layer Security (TLS) Protocol: TLSA., August 2012
[9] Perspectives Project, http://perspectives-project.org/
[10] Convergence Project, http://convergence.io/
[11] Public Key Pinning, http://www.imperialviolet.org/2011/05/04/pinning.html
[12] P. Hallam-Baker, R. Stradling; RFC 6844 - DNS Certification Authority Authorization (CAA) Resource Record., January 2013
[13] SWEDE Tool, https://github.com/pieterlexis/swede
[14] OpenSSL DANE Tool, https://github.com/kirei/openssl-dane
[15] DANE module in SSHFP, https://github.com/xelerance/sshfp
[16] Extended DNSSEC Validator, https://os3sec.org/
[17] DANE Patrol, https://labs.nic.cz/page/1207/dane-patrol/
[18] Stapled Certificates, http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
[19] M. StJohns; RFC 5011 - Automated Updates of DNS Security (DNSSEC) Trust Anchors ., September
2007
[20] http://www.debian-administration.org/articles/349
[21] https://github.com/xelerance/sshfp/blob/master/dane
[22] http://people.redhat.com/pwouters/
[23] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose; RFC 4034 - Resource Records for the DNS
Security Extensions., March 2005
[24] P. Mockapetris; RFC 1035 - Domain names - Implementation and specification, November 1987
[25] P. Mockapetris; RFC 1034 - Domain names - Concepts and facilities, November 1987
[26] E. Lewis; RFC 4592 - The Role of Wildcards in the Domain Name System, July 2006
15