idnits 2.17.1 draft-ietf-dnssec-ddi-05.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-26) 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. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnssec-ddi-05.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-ddi-05.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-ddi-05.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-dnssec-ddi-05.txt,', but the file name used is 'draft-ietf-dnssec-ddi-05' == 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 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: ---------------------------------------------------------------------------- == Line 163 has weird spacing: '...ollowed by th...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 1998) is 9539 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) -- Looks like a reference, but probably isn't: '1035' on line 65 Summary: 10 errors (**), 1 flaw (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 CyberCash, Inc. 3 Expires September 1998 March 1998 5 Detached Domain Name System (DNS) Information 6 -------- ------ ---- ------ ----- ----------- 8 Donald E. Eastlake 3rd 10 Status of This Document 12 This draft, file name draft-ietf-dnssec-ddi-05.txt, is intended to be 13 become a Proposed Standard RFC. Distribution of this document is 14 unlimited. Comments should be sent to the DNS Security Working Group 15 mailing list or to the author. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 31 ftp.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 32 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 34 Abstract 36 A standard format is defined for representing detached DNS 37 information. This is anticipated to be of use for storing 38 information retrieved from the Domain Name System (DNS), including 39 security information, in archival contexts or contexts not connected 40 to the Internet. 42 Table of Contents 44 Status of This Document....................................1 46 Abstract...................................................2 47 Table of Contents..........................................2 49 1. Introduction............................................3 51 2. General Format..........................................4 52 2.1 Binary Format..........................................4 53 2.2. Text Format...........................................6 55 3. Usage Example...........................................7 56 4. Security Considerations.................................7 58 References.................................................8 59 Author's Address...........................................8 60 Expiration and File Name...................................8 62 1. Introduction 64 The Domain Name System (DNS) is a replicated hierarchical distributed 65 database system [RFC 1034, 1035] that can provide highly available 66 service. It provides the operational basis for Internet host name to 67 address translation, automatic SMTP mail routing, and other basic 68 Internet functions. The DNS has been extended as described in 69 [draft-ietf-dnssec-secext2-*.txt] to permit the general storage of 70 public cryptographic keys in the DNS and to enable the authentication 71 of information retrieved from the DNS though digital signatures. 73 The DNS was not originally designed for storage of information 74 outside of the active zones and authoritative master files that are 75 part of the connected DNS. However there may be cases where this is 76 useful, particularly in connection with archived security 77 information. 79 2. General Format 81 The formats used for detached Domain Name System (DNS) information 82 are similar to those used for connected DNS information. The primary 83 difference is that elements of the connected DNS system (unless they 84 are an authoritative server for the zone containing the information) 85 are required to count down the Time To Live (TTL) associated with 86 each DNS Resource Record (RR) and discard them (possibly fetching a 87 fresh copy) when the TTL reaches zero. In contrast to this, detached 88 information may be stored in a off-line file, where it can not be 89 updated, and perhaps used to authenticate historic data or it might 90 be received via non-DNS protocols long after it was retrieved from 91 the DNS. Therefore, it is not practical to count down detached DNS 92 information TTL and it may be necessary to keep the data beyond the 93 point where the TTL (which is defined as an unsigned field) would 94 underflow. To preserve information as to the freshness of this 95 detached data, it is accompanied by its retrieval time. 97 Whatever retrieves the information from the DNS must associate this 98 retrieval time with it. The retrieval time remains fixed thereafter. 99 When the current time minus the retrieval time exceeds the TTL for 100 any particular detached RR, it is no longer a valid copy within the 101 normal connected DNS scheme. This may make it invalid in context for 102 some detached purposes as well. If the RR is a SIG (signature) RR it 103 also has an expiration time. Regardless of the TTL, it and any RRs 104 it signs can not be considered authenticated after the signature 105 expiration time. 107 2.1 Binary Format 109 The standard binary format for detached DNS information is as 110 follows: 112 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 113 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | first retrieval time | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | RR count | | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) | 119 / / 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 121 | next retrieval time | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | RR count | | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) | 125 / / 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 / ... / 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | hex 20 | 130 +-+-+-+-+-+-+-+-+ 132 Retrieval time - the time that the immediately following information 133 was obtained from the connected DNS system. It is an unsigned 134 number of seconds since the start of 1 January 1970, GMT, ignoring 135 leap seconds, in network (big-endian) order. Note that this time 136 can not be before the initial proposal of this standard. 137 Therefore, the initial byte of an actual retrieval time, 138 considered as an unsigned quantity, will be larger than 20 hex. 139 The end of detached DNS information is indicated by a "retrieval 140 time" field initial byte equal to 20 hex. Use of a "retrieval 141 time" field with a leading unsigned byte less than 20 in binary 142 detached DNS information is reserved for future use. It may 143 indicate a different format. The present format will run out of 144 bits during the year 2106. Retrieval times will not generally be 145 32 bit aligned with respect to each other due to the variable 146 length nature of RRs. 148 RR count - an unsigned integer number (with bytes in network order) 149 of following resource records retrieved at the preceding retrieval 150 time. 152 Resource Records - the actual data which is in the same format as if 153 it were being transmitted in a DNS response. In particular, name 154 compression via pointers is permitted with the origin at the 155 beginning of the particular detached information data section, 156 just after the RR count. 158 2.2. Text Format 160 The standard text format for detached DNS information is as 161 prescribed for zone master files [RFC 1035] except that the $INCLUDE 162 control entry is prohibited and the new $DATE entry is required 163 (unless the information set is empty). $DATE is followed by the date 164 and time that the following information was obtained from the DNS 165 system as described for retrieval time in section 2.1 above. It is 166 in the text format YYYYMMDDHHMMSS where YYYY is the year, the first 167 MM is the month number (01-12), DD is the day of the month (01-31), 168 HH is the hour in 24 hours notation (00-23), the second MM is the 169 minute (00-59), and SS is the second (00-59). Thus a $DATE must 170 appear before the first RR and at every change in retrieval time 171 through the detached information. 173 3. Usage Example 175 A document might be authenticated by a key retrieved from the DNS in 176 a KEY resource record (RR). To later prove the authenticity of this 177 document, it would be desirable to preserve the KEY RR for that 178 public key, the SIG RR signing that KEY RR, the KEY RR for the key 179 used to authenticate that SIG, and so on through SIG and KEY RRs 180 until a well known trusted key is reached, perhaps the key for the 181 DNS root or some third party authentication service. (In some cases 182 these KEY RRs will actually be sets of KEY RRs with the same owner 183 and class because SIGs actually sign such record sets.) 185 This information could be preserved as a set of detached DNS 186 information blocks. 188 4. Security Considerations 190 The entirety of this document concerns a means to represent detached 191 DNS information. Such detached resource records may be security 192 relevant and/or secured information as described in [draft-ietf- 193 dnssec-secext2-*.txt]. The detached format provides no overall 194 security for sets of detached information or for the association 195 between retrieval time and information. This can be provided by 196 wrapping the detached information format with some other form of 197 signature. However, if the detached information is accompanied by 198 SIG RRs, its validity period is indicated in those SIG RRs so the 199 retrieval time might be of secondary importance. 201 References 203 [RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 204 November 1987. 206 [RFC 1035] - Domain Names - Implementation and Specifications, P. 207 Mockapetris, November 1987. 209 [draft-ietf-dnssec-secext2-*.txt] - Domain Name System Security 210 Extensions, D. Eastlake. 212 Author's Address 214 Donald E. Eastlake 3rd 215 CyberCash, Inc. 216 318 Acton Street 217 Carlisle, MA 01741 USA 219 Telephone: +1 978 287 4877 220 +1 703 620 4200 (main office, Reston, Virginia) 221 Fax: +1 978 371 7148 222 email: dee@cybercash.com 224 Expiration and File Name 226 This draft expires September 1998. 228 Its file name is draft-ietf-dnssec-ddi-05.txt.