DNSSEC/DANE/TLSA Browser Add-ons

The folks at CZ.NIC (the operators of the Czech Republic's country-code top level domain: .cz) have created a set of web browser add-ons to perform DNSSEC/DANE/TLSA validation. You can read about them and download them from their website:

        https://www.dnssec-validator.cz/

I installed the Firefox web browser plugin and did some quick tests of them on my own website. The plugin installs two new icons on the right side of the browser's location (URL) bar. The first with a key on it shows information about whether the domain name for the website has a valid DNSSEC signature associated with it. The second icon with a lock on it shows information about whether the TLS certificate of the website can be authenticated with a DANE TLSA record. Here are screenshots with my own website ( https://www.huque.com/ ).

In this first screenshot (below), I clicked on the key icon, and it reports that the 'www.huque.com'  domain name has a valid DNSSEC signature.

In the next screenshow (below), I clicked on the lock icon, and it reports that the certificate for www.huque.com has been successfully authenticated by means of a signed TLSA record.

In this case, since this is an HTTPS connection at the standard port (TCP port 443), the plugin looked for the TLSA record at the domain name "_443._tcp.www.huque.com."

    $ dig _443._tcp.www.huque.com. TLSA +noall +answer
   [...]
    _443._tcp.www.huque.com. 7200 IN TLSA 3 0 1 (
                    7EF4BD014E9A4F302FC1EE74FB2D29718C5B0F4CB23B
                    25B267A1D92F0410890B )
    _443._tcp.www.huque.com. 7200 IN RRSIG TLSA 8 5 7200 (
                    20140217205026 20140118205010 14703 huque.com.
                    NsUKFsBAUD4OxrHQ72iB0Oz9mBoMEqL8wMsks56sp2yz
                    3ksXcqGSddooC3jZvGH/4iF6ssD3KRNQVONJqpK246nX
                    jPhxBhM730TKEwMZRw/NRqYanRKyEMhkUy538suej0Pv
                    rK3w8r6tdNF4gXqIM3sQlz9gPY/WOu0zxjezaIk= )

Below is another screenshot for https://www.ietf.org/. In this case, the second icon has a cross marked on it, meaning that no TLSA record was found for this site. Apparently, the IETF is not yet eating its own dogfood. Although see this short slide deck from IETF'87 - there appears to be a proposal to do so.

There are a few configuration options that can be set for the add-on. Here is a view of the settings window:

The plug-in appears to do its own DNS resolution (and validation) by default. But you can also choose to use DNS resolvers configured for your system, or a customer resolver such as the Google public resolver (8.8.8.8).

If you need help creating a TLSA record for your website, I have a web based tool available here:

    https://www.huque.com/bin/gen_tlsa

One thing I should mention, in case you're looking at the configuration of my website: huque.com does not today have a secure delegation (i.e. DS record) published in its parent zone. This is because the registrar I use, Network Solutions, still cannot process requests to install DS records. I did quick check on their website (again) to see if anything's changed. Doesn't appear so:

Instead, I've had DLV record published in the ISC DLV Registry. But there are several big resolver services, like Google DNS, and Comcast, that do not perform lookaside validation, so it's probably time to switch registrars. If anyone has suggestions for competent DNSSEC enabled registrars (with registrar-lock support), I'd be happy to receive them. I hope to make the switch soon.

Dan York from ISOC also has an article on these addons here. (I started writing this before seeing his!)

--Shumon Huque

---

Addendum (May 2014): my domain huque.com now has a secure delegation from .COM.

DNSSEC and Certificates

DNSSEC is a system to verify the authenticity of DNS data using public key signatures. With increasing deployment of DNSSEC comes the possibility of applications using the DNS to store and retrieve TLS/SSL certificates in an authenticated manner. And possibly obviating the need for public/global certification authorities (CA), and empowering domain owners to issue their own certificates instead.

For those of you who know me a little better, you're probably aware that I've been griping about the inherent deficiencies of the public CA model for years. Certainly my colleagues at Penn have been subjected to many a diatribe on this topic, and occasionally I've done so more publicly (no pun intended).

In brief, the problems are that applications (such as web browsers) are pre-configured to trust a very large number of global CAs. These CAs have absolutely no constraints on the namespace for which they can issue certificates. Any of them can issue a certificate for any of your services (whether you have a business relationship with them or not). And thus, we have what is tantamount to least common denominator security - the collective security of the system is equivalent to the CA with the weakest security and laxest policies. It gets worse - many of these CAs in turn issue subordinate CA certificates for their customers, again with no namespace constraints.

Another issue is that most of these CAs are capable only of issuing certificates with the most basic capabilities. If you need to deploy a certificate with some more exotic feature (eg. an alternate name form or extension), you're basically out of luck.

Incidentally the PKIX specifications do have the capability of constraining the namespace (see RFC 5280 Section 4.2.1.10: Name Constraints extension), but deploying it in the existing public CA model will require a huge amount of work (both technical and political), including deployment of a hierarchical global CA architecture, as well as enhancing client software to validate name constraints (which practically none do today).

Introducing DANE and TLSA

Recent work in the IETF holds some promise to improve things. RFC 6698 (DANE) defines the new DNS record type TLSA, which holds what is called Certificate Association data. In conjunction with DNSSEC signatures, this will permit better and more secure ways for applications to authenticate certificates. The record can be used in 4 different ways (defined by a "Usage" field):

• (Usage 0) Specify authorized public CAs - this can prevent certificates signed by CAs that you didn't explicitly specify from being trusted by client software.
• (Usage 1) Specify which specific server certificate can be trusted. The public CA certificate validation chain all the way to the server certificate must still be validated.
• (Usage 2) Authorize a new non-public CA (eg. a CA that the domain owner operates itself)
• (Usage 3) Directly specify the server certificate in the DNS - no certificate chain from a public CA needs to be used. This is called a "Domain issued certificate"

If you're looking for a way to not use public CAs, Usage 3 is probably the one for you.

The owner name of the TLSA record defines the port, transport protocol, and server host name. Here's an example for the HTTPS service (port 443, TCP) at www.example.com:

  _443._tcp.www.example.com. IN TLSA ( 0 0 1
                                d2abde240d7cd3ee6b4b28c54df034b9
                                7983a1d16e8a410e4561cb106618e971 )

The right hand side ("rdata" or resource data) of the TLSA record contains 3 numbers and the raw certificate data in hexadecimal. The 3 numbers are the usage field (previously described), the selector field (which says whether the certificate data takes into account the full certificate or only the subject's public key), and the matching-type field (which says whether the certificate data is the full content that the selector field specifies, or whether it is a cryptographic hash of it). See RFC 6698 for a more detailed description.

Deploying a TLSA record for my website

After seeing several prominent mentions of DANE at this week's ICANN'45 DNSSEC workshop, (see Dan York and Paul Wouters' presentations for example) I felt motivated to install a TLSA record for my website.

Now billions of users with TLSA capable web browsers and DNSSEC validating resolvers will be able to securely reach my website! Okay, that's a slight exaggeration, but perhaps one day, in the not too distant future!

I wanted to see if I could do this using standard tools already available on most UNIX systems. It wasn't too hard. My site already has an SSL certificate issued by StartCom Ltd, but I want to specify that the server certificate can also be authenticated directly without a CA (TLSA Usage type 3). I'll also use a SHA256 hash (match-type 1) of the full certificate (selector 0) as the certificate association data (so the 3 numbers in the rdata will be 3 0 1).

OpenSSL can be used to easily generate the certificate association data portion. We first convert my PEM encoded certificate (in file huque.crt) into the binary DER encoding (openssl x509 -outform DER) and then pipe the output to "openssl sha256". This generates the 256-bit SHA hash represented as a string of 64 hex digits (each hex digit is 4 bits):

  $ openssl x509 -in huque.crt -outform DER | openssl sha256
  (stdin)= 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

The resulting TLSA DNS record will thus look like:

  _443._tcp.www.huque.com. IN TLSA 3 0 1 ( 
       8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1 )

One quick nsupdate command  (details omitted) and the record was installed in my DNSSEC signed zone. We can check that the record (and its signature) is present with dig:

$ dig +dnssec +noall +answer +multi _443._tcp.www.huque.com. TLSA

_443._tcp.www.huque.com. 893 IN TLSA 3 0 1 (
                                8CB0FC6C527506A053F4F14C8464BEBBD6DEDE2738D1
                                1468DD953D7D6A3021F1 )
_443._tcp.www.huque.com. 893 IN RRSIG TLSA 8 5 900 (
                                20121117202722 20121018192722 14703 huque.com.
                                OJ4b/O7J+Fh3KVDGG8nH9X5dRSXgl3j7/S/PbB1RczcY
                                fYxdu5C9xZSALCz0MgVFW6Kcne74ou5R/Wd+CDKm7mYY
                                Ga28MrtE1boNLuOTa6kOpFcNjW+UYnMFQuc6S8zhU1G7
                                LH0n3TbM3rJS0wH0u6J4NgtiowZS2VlkwPez3D8= )

(If you're using an older version of BIND/dig that doesn't understand the TLSA record type, you can replace TLSA in the command line above with TYPE52.)

Note: the huque.com zone does not currently have a secure delegation from the .COM TLD. This is mainly because my current DNS registrar (Network Solutions) is incapable of processing DS records, sigh, and I've been too lazy to switch. In the meantime, it has a DLV record published in the DLV registry operated by ISC, so any validating resolver configured to use that registry (and many are) should be able to authenticate records in huque.com.

Not surprisingly, there are already tools out there that make it easy to generate TLSA records. Paul Wouter's hash-slinger package can do it (supposedly integrated into newer Fedora Linux releases). With the "tlsa" program included in that package, we can do this via:

  $ tlsa --create --output rfc --usage 3 --certificate huque.crt www.huque.com
  _443._tcp.www.huque.com. IN TLSA 3 0 1
       8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

Obviously DANE needs to be widely adopted by the Internet community for it to be successful, and it's not yet clear how long that will take. And obviously browsers and other application sofware will have to evolve to make use of TLSA records. But preliminary work appears to already be in progress - there are a few browser extensions that try to validate TLSA records for HTTPS websites. I plan to look into those next ..

Incidentally, I'm teaching a half-day DNS and DNSSEC course at the upcoming USENIX LISA conference in San Diego, December 9th-14th. I hope to talk more about DANE and TLSA there.

Shumon Huque

-------------------------------------------------------------------------
Updates:

* (June 2013)  I thought I'd mention I have a small program that generates the resource data for a TLSA record from a certificate file and given parameters. You can find it on github: tlsa_rdata ]

* (September 2013) Randy Bush pointed out to me that OpenSSL versions on a number of operating systems like current versions of Mac OS X and FreeBSD are too old to support sha256. It appears that the sha256 digest command in OpenSSL is fairly new, appearing in version 1.0.1, which is newer than many current operating system distributions provide.  So I'll provide a few alternatives to "openssl 256" for them:

On Mac OS X, you can use shasum (/usr/sbin/shasum):
  openssl x509 -in certfile.crt -outform DER | shasum -a 256
On FreeBSD, you can use sha256 (/sbin/sha256):
  openssl x509 -in certfile.crt -outform DER | sha256
On Redhat Linux, you can use sha256sum (/usr/sbin/sha256sum):
  openssl x509 -in certfile.crt -outform DER | sha256sum

Or you can use Python's hashlib module (going back as far as Python 2.5). I've put up a small program on github called dgst that provides a simple command line utility to generate various cryptographic hashes of files or whatever is fed on standard input:

    https://github.com/shuque/dgst