A Step-by-Step guide for implementing DANE with a Proof of Concept

Transcription

1 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, 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

2 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 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: 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

3 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. Further, when a user is connecting to 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

4 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 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

5 Table 1: Usage explained Value Meaning 0 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. 1 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) 2 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. 3 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) Table 2: Selector explained Value Meaning 0 Indicates the certificate association data field contains the full target certificate 1 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) Table 3: Matching type explained Value Meaning 0 indicates that the application has to match the target certificate and the payload at the certificate association data field exactly 1 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 2 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

6 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 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 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 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

7 5.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 Plan Domain Name DNSSEC Target Certificate dane.rd.nic.fr OK Self-signed certificate dane-broken.rd.nic.fr OK 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] 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 :67c:2218:6::7:155 dane-broken :67c:2218:6::7: Filtering rules All the domains used for test will be accessible on port 53 (DNS), port 80 (http) and port 443 (https) 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

8 Figure 4: Steps for implementing DANE for the demo 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 for the parent zones Test Type Command used Status Verifying whether the cctld fr is signed dig +short dnskey zone Done Verifying whether nic.fr is signed dig +short dnskey zone Done Verify whether rd.nic.fr is signed dig +short dnskey zone 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 AwEAAeI3FfKI+96FXufElXWspcxnp6LEt6S2FVESAbV5pPUb9hbP6oJU yakxwc9hraqwtjs+ziqrnd8cenyujequqhv9uo2mdpawo722riiyxrxu SH/7qnP4/EWeSNEzFT+zDsuRzWa9D68xtGKfKtdjnKNS8bS8ApgaxXUr n/tmy19// dane.rd.nic.fr. IN DNSKEY AwEAAd4dVcbYLRV6IDO6Icw4Es5HSVY6rfGB4iNTbw+Y84G2YS7nYGzi nd8rjisxeryiimsj0xwuocuzm9drvmtdr1qy0yeijceajom45xis+xol m0mmicitf1hja+vdtsambubeyvdkvtq2z52hqvvh4lmyj9po8enzuay9 BgQWfIfbyA+NouOvECWOH6KvI05IT4hAaaqUnBU47bG9imuFmytFpgL9 t17pv5t8jmotbje9tblmxzbedyyb6zqrs2cbs7u+4sxo3o+r+wfkotga XCheXUP1W3j+In/KpZ2zCVt5Iefvyodq4WgQKU8gTbbw2DTVmqWphBlc ciqqzg8saub5zavhzyzh6hmjo16guqe+ylblpapedmxt2ziju3l+yghb r2me9uibllklhnosakofefxhcyy2r1i/jgyygg/mci10kivkiz9muwyr 0hZCEcpbNCs1ru9UbTpVlQpQIu9w0Uk5gozF/yUaCr/fKFEZjRvG/x02 vj4dgydw9bevv+jwipbsaxxlea/nbzniqs3xabhstgnhet6pjkfpc/jy fktze2krqbr1sccjslvsy6wtqavwrhihywknbxkukz+mgzsw8lwkyju6 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 DS AE983EBAD81130C170AE2AF2393D6EEF4FA2F97E IN DS F3FE7BF385A40E FEEFA017CDAED7A1FB85256F2D63EE4D B7 IN DS BA5CC64D B214D941CA29FE27687D99E IN DS DA3B395E FD02CDECEE2303BFDF8BCF3BD5FC6C2462CA645CF F8D20B7B 8

9 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 "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 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] 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 e781577c0eabb6701a0caf287e48ceebd3ba64b81792ef49705f0f5e b 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

10 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 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 e781577c0eabb6701a0caf287e48ceebd3ba64b81792ef49705f0f5e b 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 e781577c0eabb6701a0caf287e48ceebd3ba64b81792ef49705f0f5e b 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 E781577C0EABB6701A0CAF287E48CEEBD3BA64B81792EF49705F0F5E B 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

11 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

12 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 What is done How is it broken Result Test1 Launch the domain is a domain provided Page does not load by Comcast with a deliberately broken signature Test2 Launch the domain A bogus RRSIG Domain name is secured dane-broken.rd.nic.fr record is added 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 How is it broken Result Launch the domain Deliberately corrupt the TLSA record. The certificate Domain name is dane-broken.rd.nic.fr offered by the server (6e013c54df90d42d3c016e1 secured by DNSSEC but ac9eb21e6da45403d3a5ae9b2d8f21fc3600d409c) the certificate has Does not match the TLSA record in the DNS zone (6e013c54df an invalid signature 90d42d3c016e1ac9eb21e6da45403d3a5ae9b2d8f21fc3600d409d) but the domain is correctly signed with DNSSEC The add-on successfully identifies when the target certificate and the TLSA RR in the DNS zone does not match for Usage: 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 How it is broken How the Firefox browser reacts Launch the domain The TLSA record is correct. The domain is correctly signed with DNSSEC. Domain name is secured by dane-broken.rd.nic.fr But the TLSA parameters are incorrect. For the certificate, DNSSEC and the certificate is the TLSA parameters are: Usage:1, Selector: 0, matchingtype: 1 validated by DNSSEC whereas it should be Usage:3, Selector: 0, matchingtype: 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

13 IN A IN AAAA 2001:67c:2218:6::7:155 ; Specifying the alias test.dane.rd.nic.fr. IN CNAME 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. " 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 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. IN TLSA 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 What is done How the Firefox browser (with the add-on) reacts Test1 Scenario:1 and open the Owner name test1.dane.rd.nic.fr It shows that both DNSSEC and TLSA validation is OK Test2 Scenario:1 and open the Canonical name Invalid Certificate Test3 Scenario:2 and open the Owner name test1.dane.rd.nic.fr Invalid Certificate Test4 Scenario:2 and open the Canonical name It shows that both DNSSEC and TLSA validation is OK Test5 Scenario:3 and on opening both Owner and Canonical name It shows that both 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 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 D7D DACFB432E EAC9A3A6586BD109D5C5466 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

14 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] [2] [3] IETF PKIX, in [4] David Cooper, Stefan Santesson, Stephen Farrell, Sharon Boeyen, Russell Housley and Tim Polk; RFC Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008 [5] DANE Charter, [6] 14

15 [7] R. Barnes; RFC Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)., October 2011 [8] P. Hoffman, J. Schlyter ; RFC The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA., August 2012 [9] Perspectives Project, [10] Convergence Project, [11] Public Key Pinning, [12] P. Hallam-Baker, R. Stradling; RFC DNS Certification Authority Authorization (CAA) Resource Record., January 2013 [13] SWEDE Tool, [14] OpenSSL DANE Tool, [15] DANE module in SSHFP, [16] Extended DNSSEC Validator, [17] DANE Patrol, [18] Stapled Certificates, [19] M. StJohns; RFC Automated Updates of DNS Security (DNSSEC) Trust Anchors., September 2007 [20] [21] [22] [23] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose; RFC Resource Records for the DNS Security Extensions., March 2005 [24] P. Mockapetris; RFC Domain names - Implementation and specification, November 1987 [25] P. Mockapetris; RFC Domain names - Concepts and facilities, November 1987 [26] E. Lewis; RFC The Role of Wildcards in the Domain Name System, July