idnits 2.17.1 draft-york-dane-deployment-observations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6698' is defined on line 153, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DANE D. York 3 Internet-Draft Internet Society 4 Intended status: Informational October 27, 2014 5 Expires: April 30, 2015 7 DANE Deployment Observations 8 draft-york-dane-deployment-observations-00 10 Abstract 12 This document provides some observations about the deployment of the 13 DANE protocol to date and some questions for discussion on the DANE 14 mailing list and potentially at the IETF 91 meeting of the DANE 15 Working Group. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 30, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Observations . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 4 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1. Introduction 62 The DANE protocol defined in RFC 6698 provides a mechanism for 63 specifying in DNS the Transport Layer Security (TLS) certificate or 64 trust anchor (ex. certificate authority) to be used for a given 65 domain. As the DANE protocol is being more widely deployed, we can 66 observe some of the challenges seen to date. This document attempts 67 to capture some of those observations and poses some questions for 68 further consideration. Feedback on this document is welcome. 70 2. Observations 72 As I have been helping people understand the value of using DANE I 73 have observed the following points related to deploying DANE: 75 o AWARENESS OF DANE - I have found that most people are completely 76 unaware that DANE exists. Once people are informed about DANE and 77 how it works, they usually see the value. 79 o CREATION OF TLSA RECORDS - Some people have found it difficult to 80 create the TLSA records. Newer tools such as hashslinger and 81 Shumon Huque's website are helping make this easier, but more 82 tools need to be available. 84 o INABILITY TO ENTER TLSA RECORDS AT DNS HOSTING OPERATORS - One of 85 the biggest deployment challenges has turned out to be that many 86 people are unable to enter TLSA records in the provisioning 87 interface for their DNS hosting operator. Those interfaces are 88 typically web-based and allow a user to add only a certain set of 89 RRTYPES to a DNS zone file. Until the DNS hosting provider allows 90 users to add a TLSA record, those users will not be able to 91 publish TLSA records and use DANE. 93 o AVAILABILITY OF DEVELOPER LIBRARIES - Some people have found that 94 DANE support is not yet included in the DNS library they have 95 previously used. This is changing as DANE is added to more DNS 96 libraries. The new getDNS API is also helpful to have. 98 o PERCEPTION THAT DANE IS ONLY FOR SELF-SIGNED CERTIFICATES - Some 99 people who have heard of DANE believe that is only for people 100 using self-signed certificates. They do not understand that it 101 can also be used with certificates from an existing certificate 102 authority (CA). 104 o PERFORMANCE - A few people have raised concerns about the 105 additional DNS queries required to complete the DANE transaction 106 and wondered about the performance impact. 108 o CRYPTOGRAPHIC CONCERNS - A few concerns have been raised that DANE 109 is cryptographically weaker than other potential solutions, 110 although in further discussion this often seems to be more of a 111 perception issue and not fully understanding how DANE can be used. 113 There are also questions about the availability of DNSSEC, but as 114 that deployment is increasing on both the signing and validation side 115 and tools are now more readily available, I've chosen here to focus 116 more on observations I have heard directly related to DANE. 118 3. Questions 120 Several potential questions for discussion include: 122 o What roadblocks are people running into with implementing DANE? 123 (outside of the broader issue of getting DNSSEC validation and 124 signing more widely available) are there lessons we can feed back 125 into our process of developing DANE-related standards? 127 o Are there more "Using DANE with " types of documents that we 128 can or should create? (and who is willing to do so?) 130 o Are there some good examples/case studies of DANE implementations 131 that we could perhaps capture as informational RFCs? (the Jabber 132 community's implementation comes to mind) 134 o Are there places where it would be helpful if there were reference 135 implementations of DANE support? For example, DANE for email got 136 a boost when support was added to postfix. Are there other 137 commonly-used open source projects where the addition of DANE 138 support would help move deployment along? 140 o Are there test tools that need to be developed? or existing ones 141 that need to be better promoted? are there interop tests we can 142 arrange? 144 4. IANA Considerations 145 This document requests no actions from the IANA. 147 5. Security Considerations 149 This document raises no specific security considerations. 151 6. References 153 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 154 of Named Entities (DANE) Transport Layer Security (TLS) 155 Protocol: TLSA", RFC 6698, August 2012. 157 Appendix A. Acknowledgements 159 (to be added) 161 Author's Address 163 Dan York 164 Internet Society 166 Email: york@isoc.org 167 URI: https://www.internetsociety.org/