Internet DRAFT - draft-york-dane-deployment-observations
draft-york-dane-deployment-observations
DANE D. York
Internet-Draft Internet Society
Intended status: Informational October 27, 2014
Expires: April 30, 2015
DANE Deployment Observations
draft-york-dane-deployment-observations-00
Abstract
This document provides some observations about the deployment of the
DANE protocol to date and some questions for discussion on the DANE
mailing list and potentially at the IETF 91 meeting of the DANE
Working Group.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
York Expires April 30, 2015 [Page 1]
Internet-Draft DANE Deployment Observations October 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Observations . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
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.
2. Observations
As I have been helping people understand the value of using DANE I
have observed the following points related to deploying DANE:
o 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.
o 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.
o 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.
o 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.
York Expires April 30, 2015 [Page 2]
Internet-Draft DANE Deployment Observations October 2014
o 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).
o PERFORMANCE - A few people have raised concerns about the
additional DNS queries required to complete the DANE transaction
and wondered about the performance impact.
o 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.
3. Questions
Several potential questions for discussion include:
o 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?
o Are there more "Using DANE with <foo>" types of documents that we
can or should create? (and who is willing to do so?)
o 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)
o 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?
o 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?
4. IANA Considerations
York Expires April 30, 2015 [Page 3]
Internet-Draft DANE Deployment Observations October 2014
This document requests no actions from the IANA.
5. Security Considerations
This document raises no specific security considerations.
6. References
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012.
Appendix A. Acknowledgements
(to be added)
Author's Address
Dan York
Internet Society
Email: york@isoc.org
URI: https://www.internetsociety.org/
York Expires April 30, 2015 [Page 4]
