idnits 2.17.1 draft-dickson-dnsop-ds-hack-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (11 August 2021) is 961 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group . B Dickson 3 Internet-Draft GoDaddy 4 Intended status: Informational 11 August 2021 5 Expires: 12 February 2022 7 DS Algorithms for Securing NS and Glue 8 draft-dickson-dnsop-ds-hack-00 10 Abstract 12 This Internet Draft proposes a mechanism to encode relevant data for 13 NS records (and optionally A and AAAA records) on the parental side 14 of a zone cut, by encoding them in new DS algorithms. 16 Since DS records are signed by the parent, this creates a method for 17 validation of the otherwise unsigned delegation and glue records. 19 This is beneficial if the name server _names_ are in a DNSSEC signed 20 zone. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 12 February 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 57 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. New DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 3 59 4.1. Algorithm {TBD1} . . . . . . . . . . . . . . . . . . . . 3 60 4.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. Algorithm {TBD2} . . . . . . . . . . . . . . . . . . . . 4 62 4.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.3. Algorithm {TBD3} . . . . . . . . . . . . . . . . . . . . 5 64 4.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Validation Using These DS Records . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 There are new privacy goals and DNS server capability discovery 77 goals, which cannot be met without the ability to validate the name 78 of the name servers for a given domain at the delegation point. 80 Specifically, a query for NS records over an unprotected transport 81 path returns results which do not have protection from tampering by 82 an active on-path attacker, or against successful cache poisoning 83 attackes. 85 This is true regardless of the DNSSEC status of the domain containing 86 the authoritative information for the name servers for the queried 87 domain. 89 For example, querying for the NS records for "example.com", at the 90 name servers for the "com" TLD, where the published com zone has 91 "example.com NS ns1.example.net", is not protected against MITM 92 attacks, even if the domain "example.net" (the domain serving records 93 for "ns1.example.net") is DNSSEC signed. 95 More infomation can be found in [I-D.nottingham-for-the-users]. (An 96 exmple of an informative reference to a draft in the middle of text. 97 Note that referencing an Internet draft involves replacing "draft-" 98 in the name with "I-D.") 100 2. Conventions and Definitions 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 3. Background 110 The methods developed for adding security to the Domain Name System, 111 collectively refered to as DNSSEC, had as a primary requirement that 112 they be backward compatible. The original specifications for DNS 113 used the same Resourc Record Type (RRTYPE) on both the parent and 114 child side of a zone cut (the NS record). The main goal of DNSSEC 115 was to ensure data integrity by using cryptographic signatures. 116 However, owing to this overlap in the NS record type where the 117 records above and below the zone cut have the same owner name created 118 an inherent conflict, as only the child zone is authoritative for 119 these records. 121 The result is that the parental side of the zone cut has records 122 needed for DNS resolution which are not signed and not validatable. 124 This has no impact on DNS zones which are fully DNSSEC signed 125 (anchored at the IANA DNS Trust Anchor), but does impact unsigned 126 zones regardless of where the transition from secure to insecure 127 occurs. 129 4. New DNSKEY Algorithms 131 These new DNSKEY algorithms conform to the structure requirements 132 from [RFC4034], but are not themselves used as actual DNSKEY 133 algorithms. They are assigned values from the DNSKEY algorithm 134 table. No DNSKEY records are published with these algorithms. 136 They are used only as the input to the corresponding DS hashes 137 published in the parent zone. 139 4.1. Algorithm {TBD1} 141 This algorithm is used to validate the NS records of the delegation 142 for the owner name. 144 The NS records are canonicalized and sorted according to the DNSSEC 145 signing process [RFC4034] section 6, including removing any label 146 compression, and normalizing the character cases to lower case. The 147 RDATA fields of the records are concatenated, and the result is 148 hashed using the selected digest algorithm(s), e.g. SHA2-256 for DS 149 digest algorithm 1. 151 4.1.1. Example 153 Consider the delegation in the COM zone: example.com NS 154 ns1.example.net example.com NS ns2.example.net 156 These two records have RDATA, which after canonicalization and 157 sorting, would be ns1.example.net ns2.example.net 159 The input to the digest is the concatenation of those values in wire 160 format. For example, if the NS set's RDATA are "ns1.example.net" and 161 "ns2.example.net", the wire format would be 163 0x03 164 ns1 165 0x07 166 example 167 0x03 168 net 169 0x00 170 0x03 171 ns2 172 0x07 173 example 174 0x03 175 net 176 0x00 178 The Key Tag is calculated per [RFC4034] using this value as the 179 RDATA. 181 The resulting DS record is 183 example.com DS KeyTag=0 Algorithm={TBD1} DigestType=2 \ 184 Digest=sha2-256() 186 4.2. Algorithm {TBD2} 188 This algorithm is used to validate the glue A records required as 189 glue for the delegation NS set associated with the owner name. 191 The glue A records are canonicalized and sorted according to the 192 DNSSEC signing process [RFC4034], including removing any label 193 compression, and normalizing the character cases. The entirety of 194 the records are concatenated, and the result is hashed using the 195 selected hash type(s), e.g. SHA2-256 for DS type 2. 197 4.2.1. Example 199 For example, if the original "glue" (unsigned) A records are: 201 ns1.example.net IN 3600 A standard-example-ip-1 202 ns2.example.net IN 3600 A standard-example-ip-2 204 There would be one DS record for each of the glue "A" records, with 205 the canonicalized wire format of the entire record provided as input 206 to the hash function. 208 FIXME replace 0xfffffffx with real example IP addresses 209 (per IANA table of example IPs) 210 First A record's DS record: 211 wire_format(ns1.example.net) 0x01 0x01 3600 0xfffffff0 212 Second A record's DS record: 213 wire_format(ns2.example.net) 0x01 0x01 3600 0xfffffff1 215 Then the resulting DS record is 217 FIXME - who is the right owner to use here? 218 (The glue owner name, or the zone owner name (bailiwick only)?) 219 example.net DS KeyTag=0 Algorithm={TBD2} DigestType=2 \ 220 Digest=sha2-256() 221 example.net DS KeyTag=0 Algorithm={TBD2} DigestType=2 \ 222 Digest=sha2-256() 224 4.3. Algorithm {TBD3} 226 This algorithm is used to validate the glue AAAA records required as 227 glue for the delegation NS set associated with the owner name. 229 The glue AAAA records are canonicalized and sorted according to the 230 DNSSEC signing process [RFC4034], including removing any label 231 compression, and normalizing the character cases. The entirety of 232 the records are concatenated, and the result is hashed using the 233 selected hash type(s), e.g. SHA2-256 for DS type 2. 235 4.3.1. Example 237 For example, if the original "glue" (unsigned) AAAA records are: 239 ns1.example.net IN 3600 AAAA standard-example-ip6-1 240 ns2.example.net IN 3600 AAAA standard-example-ip6-2 242 There would be one DS record for each of the glue "A" records, with 243 the canonicalized wire format of the entire record provided as input 244 to the hash function. 246 FIXME replace 0xfffffffx with real example IP addresses 247 (per IANA table of example IPs) 248 First A record's DS record: 249 wire_format(ns1.example.net) 0x01 0xXX 3600 0x32-hex-digits 250 Second A record's DS record: 251 wire_format(ns2.example.net) 0x01 0xXX 3600 0x32-hex-digits 253 Then the resulting DS record is 255 FIXME - who is the right owner to use here? 256 (The glue owner name, or the zone owner name (bailiwick only)?) 257 example.net DS KeyTag=0 Algorithm={TBD2} DigestType=2 \ 258 Digest=sha2-256() 259 example.net DS KeyTag=0 Algorithm={TBD2} DigestType=2 \ 260 Digest=sha2-256() 262 5. Validation Using These DS Records 264 These new DS records are used to validate corresponding delegation 265 records and glue, as follows: - NS records are validated using {TBD1} 266 - Glue A records (if present) are validated using {TBD2} - Glue AAAA 267 records (if present) are validated using {TBD3} 269 The same method used for constructing the DS records, is used to 270 validate their contents. The algorithm is replicated with the 271 corresponding inputs, and the hash compared to the published DS 272 record(s). 274 6. Security Considerations 276 As outlined above, there could be security issues in various use 277 cases. 279 7. IANA Considerations 281 This document has no IANA actions. (Well, actually, TBD1, TBD2, and 282 TBD3 need to be assigned from the DNSSEC DNSKEY Algorithm Table.) 284 8. References 286 8.1. Normative References 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, 290 DOI 10.17487/RFC2119, March 1997, 291 . 293 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 294 Rose, "Resource Records for the DNS Security Extensions", 295 RFC 4034, DOI 10.17487/RFC4034, March 2005, 296 . 298 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 299 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 300 May 2017, . 302 8.2. Informative References 304 [I-D.nottingham-for-the-users] 305 Nottingham, M., "The Internet is for End Users", Work in 306 Progress, Internet-Draft, draft-nottingham-for-the-users- 307 09, 22 July 2019, . 310 Acknowledgments 312 Thanks to everyone who helped create the tools that let everyone use 313 Markdown to create Internet Drafts, and the RFC Editor for xml2rfc. 315 Thanks to Dan York for his Tutorial on using Markdown for writing 316 IETF drafts. 318 Thanks to YOUR NAME HERE for contributions, reviews, etc. 320 Author's Address 322 Brian Dickson 323 GoDaddy 325 Email: brian.peter.dickson@gmail.com