idnits 2.17.1 draft-ietf-dnssec-ddi-06.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-19) 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-06.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-ddi-06.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-ddi-06.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-06.txt,', but the file name used is 'draft-ietf-dnssec-ddi-06' == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 169 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 (October 1998) is 9318 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 69 Summary: 9 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 IBM 3 Expires April 1999 October 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-06.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 view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 [Changes from last draft: change date, update author info, define 64 35 bit retrieval time format to avoid year 2106 problem, permit text 36 data format to have more than four digits of year, add IANA 37 Considerations section] 39 Abstract 41 A standard format is defined for representing detached DNS 42 information. This is anticipated to be of use for storing 43 information retrieved from the Domain Name System (DNS), including 44 security information, in archival contexts or contexts not connected 45 to the Internet. 47 Table of Contents 49 Status of This Document....................................1 51 Abstract...................................................2 52 Table of Contents..........................................2 54 1. Introduction............................................3 55 2. General Format..........................................3 56 2.1 Binary Format..........................................4 57 2.2. Text Format...........................................5 58 3. Usage Example...........................................5 59 4. IANA Considerations.....................................5 60 5. Security Considerations.................................6 62 References.................................................7 63 Author's Address...........................................7 64 Expiration and File Name...................................7 66 1. Introduction 68 The Domain Name System (DNS) is a replicated hierarchical distributed 69 database system [RFC 1034, 1035] that can provide highly available 70 service. It provides the operational basis for Internet host name to 71 address translation, automatic SMTP mail routing, and other basic 72 Internet functions. The DNS has been extended as described in 73 [draft-ietf-dnssec-secext2-*.txt] to permit the general storage of 74 public cryptographic keys in the DNS and to enable the authentication 75 of information retrieved from the DNS though digital signatures. 77 The DNS was not originally designed for storage of information 78 outside of the active zones and authoritative master files that are 79 part of the connected DNS. However there may be cases where this is 80 useful, particularly in connection with archived security 81 information. 83 2. General Format 85 The formats used for detached Domain Name System (DNS) information 86 are similar to those used for connected DNS information. The primary 87 difference is that elements of the connected DNS system (unless they 88 are an authoritative server for the zone containing the information) 89 are required to count down the Time To Live (TTL) associated with 90 each DNS Resource Record (RR) and discard them (possibly fetching a 91 fresh copy) when the TTL reaches zero. In contrast to this, detached 92 information may be stored in a off-line file, where it can not be 93 updated, and perhaps used to authenticate historic data or it might 94 be received via non-DNS protocols long after it was retrieved from 95 the DNS. Therefore, it is not practical to count down detached DNS 96 information TTL and it may be necessary to keep the data beyond the 97 point where the TTL (which is defined as an unsigned field) would 98 underflow. To preserve information as to the freshness of this 99 detached data, it is accompanied by its retrieval time. 101 Whatever retrieves the information from the DNS must associate this 102 retrieval time with it. The retrieval time remains fixed thereafter. 103 When the current time minus the retrieval time exceeds the TTL for 104 any particular detached RR, it is no longer a valid copy within the 105 normal connected DNS scheme. This may make it invalid in context for 106 some detached purposes as well. If the RR is a SIG (signature) RR it 107 also has an expiration time. Regardless of the TTL, it and any RRs 108 it signs can not be considered authenticated after the signature 109 expiration time. 111 2.1 Binary Format 113 The standard binary format for detached DNS information is as 114 follows: 116 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | first retrieval time | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | RR count | | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) | 123 / / 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 125 | next retrieval time | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | RR count | | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) | 129 / / 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 / ... / 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | hex 20 | 134 +-+-+-+-+-+-+-+-+ 136 Retrieval time - the time that the immediately following information 137 was obtained from the connected DNS system. It is an unsigned 138 number of seconds since the start of 1 January 1970, GMT, ignoring 139 leap seconds, in network (big-endian) order. Note that this time 140 can not be before the initial proposal of this standard. 141 Therefore, the initial byte of an actual retrieval time, 142 considered as a 32 bit unsigned quantity, would always be larger 143 than 20 hex. The end of detached DNS information is indicated by 144 a "retrieval time" field initial byte equal to 0x20. Use of a 145 "retrieval time" field with a leading unsigned byte of zero 146 indicates a 64 bit (actually 8 leading zero bits plus a 56 bit 147 quantity). This 64 bit format will be required when retrieval 148 time is larger than 0xFFFFFFFF, which is some time in the year 149 2106. The meaning of retrieval times with an initial byte between 150 0x01 and 0x1F is reserved (see section 5). Retrieval times will 151 not generally be 32 bit aligned with respect to each other due to 152 the variable length nature of RRs. 154 RR count - an unsigned integer number (with bytes in network order) 155 of following resource records retrieved at the preceding retrieval 156 time. 158 Resource Records - the actual data which is in the same format as if 159 it were being transmitted in a DNS response. In particular, name 160 compression via pointers is permitted with the origin at the 161 beginning of the particular detached information data section, 162 just after the RR count. 164 2.2. Text Format 166 The standard text format for detached DNS information is as 167 prescribed for zone master files [RFC 1035] except that the $INCLUDE 168 control entry is prohibited and the new $DATE entry is required 169 (unless the information set is empty). $DATE is followed by the date 170 and time that the following information was obtained from the DNS 171 system as described for retrieval time in section 2.1 above. It is 172 in the text format YYYYMMDDHHMMSS where YYYY is the year (which may 173 be more than four digits to cover years after 9999), the first MM is 174 the month number (01-12), DD is the day of the month (01-31), HH is 175 the hour in 24 hours notation (00-23), the second MM is the minute 176 (00-59), and SS is the second (00-59). Thus a $DATE must appear 177 before the first RR and at every change in retrieval time through the 178 detached information. 180 3. Usage Example 182 A document might be authenticated by a key retrieved from the DNS in 183 a KEY resource record (RR). To later prove the authenticity of this 184 document, it would be desirable to preserve the KEY RR for that 185 public key, the SIG RR signing that KEY RR, the KEY RR for the key 186 used to authenticate that SIG, and so on through SIG and KEY RRs 187 until a well known trusted key is reached, perhaps the key for the 188 DNS root or some third party authentication service. (In some cases 189 these KEY RRs will actually be sets of KEY RRs with the same owner 190 and class because SIGs actually sign such record sets.) 192 This information could be preserved as a set of detached DNS 193 information blocks. 195 4. IANA Considerations 197 Allocation of meanings to retrieval time fields with a initial byte 198 of between 0x01 and 0x1F requires an IETF consensus. 200 5. Security Considerations 202 The entirety of this document concerns a means to represent detached 203 DNS information. Such detached resource records may be security 204 relevant and/or secured information as described in [draft-ietf- 205 dnssec-secext2-*.txt]. The detached format provides no overall 206 security for sets of detached information or for the association 207 between retrieval time and information. This can be provided by 208 wrapping the detached information format with some other form of 209 signature. However, if the detached information is accompanied by 210 SIG RRs, its validity period is indicated in those SIG RRs so the 211 retrieval time might be of secondary importance. 213 References 215 [RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 216 November 1987. 218 [RFC 1035] - Domain Names - Implementation and Specifications, P. 219 Mockapetris, November 1987. 221 [draft-ietf-dnssec-secext2-*.txt] - Domain Name System Security 222 Extensions, Donald Eastlake 3rd. 224 Author's Address 226 Donald E. Eastlake 3rd 227 IBM 228 318 Acton Street 229 Carlisle, MA 01741 USA 231 Telephone: +1-978-287-4877 232 +1-914-784-7913 233 Fax: +1-978-371-7148 234 email: dee3@us.ibm.com 236 Expiration and File Name 238 This draft expires April 1999. 240 Its file name is draft-ietf-dnssec-ddi-06.txt.