idnits 2.17.1 draft-wkumari-dnsop-defense-collision-mitigate-03.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 (November 22, 2013) is 3801 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Intended status: Informational November 22, 2013 5 Expires: May 26, 2014 7 A method for mitigating namespace collisions 8 draft-wkumari-dnsop-defense-collision-mitigate-03 10 Abstract 12 This document outlines a possible, but not recommended, method to 13 mitigate the effect of collisions in the DNS namespace by providing a 14 means for end users to disambiguate the conflict. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 26, 2014. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction / Background . . . . . . . . . . . . . . . . . . 2 51 2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Implementation / Disclaimers . . . . . . . . . . . . . . . . 3 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 4 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1. Introduction / Background 62 Collisions in the DNS occur in multiple ways; one common case is that 63 an organization has used an sub-domain (foo) of their primary domain 64 (example.com) for corporate infrastructure, and then the string "foo" 65 is delegated as a TLD. When an employee of the organization enters 66 'www.foo', is the goal to reach a machine in the internal namespace 67 (www.foo.example.com) or the hostname 'www' in the 'foo' TLD? 69 This document describes a means of disambiguating these, and similar 70 cases. 72 Implementation of these methods are not recommended; they are 73 documented here to explain some of the pitfalls with approaches like 74 these. 76 2. Mitigation 78 The mitigation described in this document involves presenting the 79 multiple options to the user, and allowing them to indicate which of 80 the names is the one they were trying to reach. 82 The mitigation would lookup the name in multiple namespaces. When if 83 a conflict is detected, it would then provide a means for the user to 84 indicate which one of the colliding names they wish to connect to, 85 and return the disambiguated answer to the application. An 86 additional feature could be for the mitigation to cache the user's 87 choice, and / or provide a means to set priorities. 89 This could be accomplished in a number of ways, including: 91 Intercepting the resolution requests from the application in a 92 "shim" type library 94 Replacing the resolver library entirelyT 95 Integrating this type of mitigation into applications (some web 96 browsers already do something similar to this) 98 Proxying the request to a server that provides an interstitial 99 page that allows the user to indicate the intended name (for 100 applications such as HTTP requests) 102 There are a number of issues with this solution, including but not 103 limited to: 105 o There may not be a human available to disambiguate the answer 106 (unattended machines, mail servers, etc.) 108 o The human / user may have no idea which is the correct choice, 109 especially in the case of a phishing attackor other malicious 110 intent 112 o The additional latency introduced may cause the originating 113 application to time out 115 o The user experience would be time consuming to select each site 116 and subsite intended (www.intranet, images.intranet, etc.) 118 o Caching the responses could lead to problems when the user changes 119 location (internal sites would fail when offsite, or otherwise 120 lead to incorrect sites being loaded) 122 For these and other reasons, implementation of this technique is not 123 recommended. 125 3. Implementation / Disclaimers 127 This document does not reference an implementation. Due to the 128 numerous issues described above, we do not recommend this solution be 129 implemented. We do not recommend that this be viewed as a solution 130 to the namespace collision problem. 132 This is a very slight mitigation. It should not be viewed as a 133 solution to the "namespace collision" issue. 135 4. IANA Considerations 137 This document contains no IANA considerations. 139 5. Security Considerations 141 While this method may make some users more aware of which version of 142 a name they are going to (and so careful users may avoid some 143 phishing attacks), the security risks described above outweigh this 144 potential benefit. 146 There are numerous security implications in this approach, including 147 leaking internal names (secret-project.corp.example.com), users being 148 tricked into selecting the incorrect choice when trying to 149 disambiguate answers, etc. 151 For these reasons, it is not recommended that this solution be 152 deployed. 154 6. Acknowledgements 156 The authors wish to thank some folk, including Fred Baker, Bob 157 Braden, Carsten Bormann, Nevil Brownlee, Eric Burger, Brian 158 Carpenter, Benoit Claise, Keith Drage, Martin J. Duerst, David 159 Harrington, Paul Hoffamn, John Levine and Ted Lemon, 161 7. References 163 Appendix A. Changes / Author Notes. 165 [RFC Editor: Please remove this section before publication.] 167 From -00 to -01. 169 o Nothing changed in the template. 171 from -01 to -02 173 o Rewrite. Less flippant. 175 From -02 to -03: 177 o Changed to Informational. Suggestion from ISE:"I see only one 178 remaining thing - you've changed its Intended Status to 179 Experimental. I think Informational would be better, since 180 'Experimental' implies that you have an implementation and are 181 publishing the document so that others can try it too. " 183 Author's Address 184 Warren Kumari 185 Google 186 1600 Amphitheatre Parkway 187 Mountain View, CA 94043 188 US 190 Email: warren@kumari.net