DANE Deployment Observations

The DANE protocol defined in RFC 6698 provides a mechanism for specifying in DNS the Transport Layer Security (TLS) certificate or trust anchor (ex. certificate authority) to be used for a given domain. As the DANE protocol is being more widely deployed, we can observe some of the challenges seen to date. This document attempts to capture some of those observations and poses some questions for further consideration. Feedback on this document is welcome.

As I have been helping people understand the value of using DANE I have observed the following points related to deploying DANE: AWARENESS OF DANE - I have found that most people are completely unaware that DANE exists. Once people are informed about DANE and how it works, they usually see the value. CREATION OF TLSA RECORDS - Some people have found it difficult to create the TLSA records. Newer tools such as hashslinger and Shumon Huque's website are helping make this easier, but more tools need to be available. INABILITY TO ENTER TLSA RECORDS AT DNS HOSTING OPERATORS - One of the biggest deployment challenges has turned out to be that many people are unable to enter TLSA records in the provisioning interface for their DNS hosting operator. Those interfaces are typically web-based and allow a user to add only a certain set of RRTYPES to a DNS zone file. Until the DNS hosting provider allows users to add a TLSA record, those users will not be able to publish TLSA records and use DANE. AVAILABILITY OF DEVELOPER LIBRARIES - Some people have found that DANE support is not yet included in the DNS library they have previously used. This is changing as DANE is added to more DNS libraries. The new getDNS API is also helpful to have. PERCEPTION THAT DANE IS ONLY FOR SELF-SIGNED CERTIFICATES - Some people who have heard of DANE believe that is only for people using self-signed certificates. They do not understand that it can also be used with certificates from an existing certificate authority (CA). PERFORMANCE - A few people have raised concerns about the additional DNS queries required to complete the DANE transaction and wondered about the performance impact. CRYPTOGRAPHIC CONCERNS - A few concerns have been raised that DANE is cryptographically weaker than other potential solutions, although in further discussion this often seems to be more of a perception issue and not fully understanding how DANE can be used. There are also questions about the availability of DNSSEC, but as that deployment is increasing on both the signing and validation side and tools are now more readily available, I've chosen here to focus more on observations I have heard directly related to DANE.

Several potential questions for discussion include: What roadblocks are people running into with implementing DANE? (outside of the broader issue of getting DNSSEC validation and signing more widely available) are there lessons we can feed back into our process of developing DANE-related standards? Are there more "Using DANE with <foo>" types of documents that we can or should create? (and who is willing to do so?) Are there some good examples/case studies of DANE implementations that we could perhaps capture as informational RFCs? (the Jabber community's implementation comes to mind) Are there places where it would be helpful if there were reference implementations of DANE support? For example, DANE for email got a boost when support was added to postfix. Are there other commonly-used open source projects where the addition of DANE support would help move deployment along? Are there test tools that need to be developed? or existing ones that need to be better promoted? are there interop tests we can arrange?

This document requests no actions from the IANA.

This document raises no specific security considerations.