idnits 2.17.1 draft-hamilton-fix-dns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9529 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Martin Hamilton 3 INTERNET-DRAFT Jon Knight 4 Loughborough University 5 March 1998 7 Distributing control of the Domain Name System 9 draft-hamilton-fix-dns-00.txt 11 Status of This Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as ``work in 22 progress.'' 24 To learn the current status of any Internet-Draft, please check 25 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 26 Shadow Directories on ds.internic.net (US East Coast), 27 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 28 munnari.oz.au (Pacific Rim). 30 Distribution of this memo is unlimited. Comments should be sent 31 directly to the author. 33 This Internet Draft expires September 1998. 35 Abstract 37 This proposal outlines a way in which the Internet community may be 38 able to route around the legal and political issues associated with 39 control of the Domain Name System. We suggest a new mechanism for 40 the distribution of domain name information, based on strong 41 cryptographic authentication. In this new system, anyone is free to 42 "publish" domain name information, with control over whether or not 43 it is accepted left to the local site DNS server administrators. 45 1. Problem definition 47 The Domain Name System is theoretically an extension to the basic 48 Internet infrastructure - simply resolving requests to look up 49 "domain name" tokens and returning Internet Protocol addresses and 50 related information [1,2]. In practice it is treated as essential by 51 the vast majority of Internet users, and control of the DNS is a 52 legal and political Hot Potato. 54 There appear to be two general problems with control of the DNS :- 56 * Clashes over who has the right to a particular domain name, 57 e.g. should Apple Computer, Inc. have an inalienable 58 right to the apple.com domain name ? 60 * Clashes over the hierarchical authority structure which is 61 used to delegate portions of the Internet domain namespace 62 to particular domain name serveres. 64 This proposal does not address the first point directly, though it 65 may be of some indirect benefit in this area. The second point is at 66 the heart of this proposal. 68 2. Proposed solution 70 The Usenet News system incorporates a "control" mechanism, which is 71 used for the creation and deletion of "newsgroups" (conferences). 72 Anyone is free to create or delete a newsgroup, but in practice most 73 Usenet servers will only act on control messages from a very small 74 number of originators - at the discretion of their administrators. 75 Usenet has recently added strong cryptographic authentication for 76 control messages, using PGP [3]. 78 We propose that this model should be adopted for the distribution of 79 Domain Name information. 81 We anticipate that some minor changes would be necessary to DNS 82 server software (e.g. BIND) to take account of this new model of DNS 83 propagation. No changes would be needed at the resolver level, as 84 moving to this new system would be transparent to end users. Usenet 85 News would be an excellent mechanism for the distribution of DNS 86 related control messages - though not a timely one. For this reason 87 we assume that most use of this system would be for the distribution 88 of new top level domain information, which could be expected to 89 change infrequently. 91 The exact level of control which is given to a particular identity 92 would, of necessity, vary from site to site. Some sites might choose 93 to act on control messages from particular people (e.g. Jon Postel or 94 Paul Vixie :-) for arbitrary second and third level domains - at 95 their discretion. 97 3. Security considerations 99 Use of strong cryptographic authentication such as PGP is essential 100 for the correct operation of this system. Compromised cryptographic 101 protocols (e.g. using 40 bit keys, or escrowed private keys) would 102 not be appropriate, since these weaknesses are now well known outside 103 the cryptological community - e.g. in the print and broadcast media. 105 It is essential that stringent measures are taken to protect the 106 private keys which are used to sign the control messages. As a bare 107 minimum these should be stored on computers which are not connected 108 to a network, with messages and signatures being transported via 109 floppy disk. We envisage that a code of conduct would rapidly emerge 110 if this proposal is successful. 112 The trust model for this system is very simple :- 114 * Implementations should discard control messages which 115 have not been cryptographically signed. 117 * Control messages with invalid signatures may be logged, 118 but should not be acted upon - even if they come from 119 a trusted originator. 121 * Control messages which have a valid signature from a 122 trusted originator but do not fall into their access 123 control list of permitted operations may be logged, 124 but should not be acted upon. 126 In addition, implementors should take care to avoid the normal 127 security problems - e.g. avoid allocating fixed size buffers, check 128 for buffer overruns. Checking for unusual behaviour would also be 129 advisable, e.g. attempts to change large amounts of domain name 130 information in a short space of time may indicate that the 131 originator's private key has been compromised. 133 4. References 135 [1] P.V. Mockapetris. "Domain names - implementation and 136 specification", RFC 1035, 1987. 138 [2] P.V. Mockapetris. "Domain names - concepts and facilities", RFC 139 1034, 1987. 141 [3] David Lawrence et al - pgpcontrol. 142 144 5. Authors' address 146 Martin Hamilton, Jon Knight 147 Department of Computer Studies 148 Loughborough University of Technology 149 Leics. LE11 3TU, UK 151 Email: m.t.hamilton@lut.ac.uk 152 j.p.knight@lut.ac.uk 154 This Internet Draft expires September 1998.