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]