idnits 2.17.1 draft-dkg-intarea-dangerous-labels-01.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 date (21 May 2022) is 704 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-koch-openpgp-webkey-service-14 -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 intarea D. K. Gillmor 3 Internet-Draft ACLU 4 Intended status: Informational 21 May 2022 5 Expires: 22 November 2022 7 Dangerous Labels in DNS and E-mail 8 draft-dkg-intarea-dangerous-labels-01 10 Abstract 12 This document establishes registries that list known security- 13 sensitive labels in the DNS and in e-mail contexts. 15 It provides references and brief explanations about the risks 16 associated with each known label. 18 The registries established here offer guidance to the security-minded 19 system administrator, who may not want to permit registration of 20 these labels by untrusted users. 22 About This Document 24 This note is to be removed before publishing as an RFC. 26 The latest revision of this draft can be found at 27 https://dkg.gitlab.io/dangerous-labels/. Status information for this 28 document may be found at https://datatracker.ietf.org/doc/draft-dkg- 29 intarea-dangerous-labels/. 31 Discussion of this document takes place on the Internet Area Working 32 Group mailing list (mailto:intarea@ietf.org), which is archived at 33 https://mailarchive.ietf.org/arch/browse/intarea/. 35 Source for this draft and an issue tracker can be found at 36 https://gitlab.com/dkg/dangerous-labels. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 22 November 2022. 55 Copyright Notice 57 Copyright (c) 2022 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Revised BSD License text as 66 described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Revised BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 73 2. DNS Labels . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. E-mail Local Parts . . . . . . . . . . . . . . . . . . . . . 4 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 4.1. Additional Risks Out of Scope . . . . . . . . . . . . . . 6 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 5.1. Dangerous DNS Labels Registry . . . . . . . . . . . . . . 7 79 5.2. Dangerous E-mail Local Parts Registry . . . . . . . . . . 8 80 5.3. Shared Considerations . . . . . . . . . . . . . . . . . . 8 81 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 83 6.2. Informative References . . . . . . . . . . . . . . . . . 9 84 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 85 Appendix B. Document Considerations . . . . . . . . . . . . . . 10 86 B.1. Other types of labels? . . . . . . . . . . . . . . . . . 10 87 B.2. Document History . . . . . . . . . . . . . . . . . . . . 11 88 B.2.1. Substantive Changes from -00 to -01 . . . . . . . . . 11 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 91 1. Introduction 93 The Internet has a few places where seemingly arbitrary labels can 94 show up and be used interchangeably. 96 Some choices for those labels have surprising or tricky consequences. 97 Reasonable admnistrators may want to be aware of those labels to 98 avoid an accidental allocation that has security implications. 100 This document registers a list of labels in DNS and e-mail systems 101 that are known to have a security impact. It is not recommended to 102 create more security-sensitive labels. 104 Offering a stable registry of these dangerous labels is not an 105 endorsement of the practice of using arbitrary labels in this way. A 106 new protocol that proposes adding a label to this list is encouraged 107 to find a different solution if at all possible. 109 1.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 2. DNS Labels 119 Note that [RFC8552] defines the use of "underscored" labels which are 120 treated differently than normal DNS labels, and often have security 121 implications. That document also established the IANA registry for 122 "Underscored and Globally Scoped DNS Node Names". That registry 123 takes precedence to the list enumerated here, and any label in that 124 list or with a leading underscore ("_") MUST NOT be included in this 125 list. 127 Below are some normal-looking DNS labels that may grant some form of 128 administrative control over the domain that the are attached to. 130 They are mostly "leftmost" or least-significant labels (in the sense 131 used in Section 8 of [RFC8499]), in that if foo were listed here, it 132 would be because granting control over the foo.example.net label (or 133 control over the host pointed to by foo.example.net) to an untrusted 134 party might offer that party some form of administrative control over 135 other parts of example.org. 137 Note: where "" occurs in Table 1, it indicates any sequence 138 of five or more decimal digits, as described in [RFC8509]. 140 +============+==============+===================================+ 141 | DNS Label | Rationale | Reference | 142 +============+==============+===================================+ 143 | mta-sts | Set SMTP | [RFC8641] | 144 | | transport | | 145 | | security | | 146 | | policy | | 147 +------------+--------------+-----------------------------------+ 148 | openpgpkey | Domain-based | [I-D.koch-openpgp-webkey-service] | 149 | | OpenPGP | | 150 | | certificate | | 151 | | lookup and | | 152 | | verification | | 153 +------------+--------------+-----------------------------------+ 154 | root-key- | Indicates | [RFC8509] | 155 | sentinel- | which DNSSEC | | 156 | is-ta- | root key is | | 157 | | trusted | | 158 +------------+--------------+-----------------------------------+ 159 | root-key- | Indicates | [RFC8509] | 160 | sentinel- | which DNSSEC | | 161 | not-ta- | root key is | | 162 | | not trusted | | 163 +------------+--------------+-----------------------------------+ 164 | www | Popular web | FIXME: find a reference | 165 | | browsers | | 166 | | guess this | | 167 | | label | | 168 +------------+--------------+-----------------------------------+ 170 Table 1: Dangerous DNS labels 172 3. E-mail Local Parts 174 Section 3.4.1 of [RFC5322] defines the local-part of an e-mail 175 address (the part before the "@" sign) as "domain-dependent". 176 However, allocating some specific local-parts to an untrusted party 177 can have significant security consequences for the domain or other 178 associated resources. 180 Note that all these labels are expected to be case-insensitive. That 181 is, an administrator restricting registration of a local-part named 182 "admin" MUST also apply the same constraint to "Admin" or "ADMIN" or 183 "aDmIn". 185 [RFC2142] offers some widespread historical practice for common 186 local-parts. The CA/Browser Forum's Baseline Requirements 187 ([CABForum-BR]) constrain how any popular Public Key Infrastructure 188 (PKI) Certification Authority (CA) should confirm domain ownership 189 when verifying by e-mail. The public CAs used by popular web 190 browsers ("web PKI") will adhere to these guidelines, but anyone 191 relying on unusual CAs may still be subject to risk additional labels 192 described here. 194 +==================+=========================+====================+ 195 | E-mail local- | Rationale | References | 196 | part | | | 197 +==================+=========================+====================+ 198 | abuse | Receive reports of | Section 2 of | 199 | | abusive public behavior | [RFC2142] | 200 +------------------+-------------------------+--------------------+ 201 | administrator | PKI Cert Issuance | Section 3.2.2.4.4 | 202 | | | of [CABForum-BR] | 203 +------------------+-------------------------+--------------------+ 204 | admin | PKI Cert Issuance | Section 3.2.2.4.4 | 205 | | | of [CABForum-BR] | 206 +------------------+-------------------------+--------------------+ 207 | hostmaster | PKI Cert Issuance, DNS | Section 3.2.2.4.4 | 208 | | zone control | of [CABForum-BR], | 209 | | | Section 7 of | 210 | | | [RFC2142] | 211 +------------------+-------------------------+--------------------+ 212 | info | PKI Cert Issuance | [VU591120] | 213 | | (historical) | | 214 +------------------+-------------------------+--------------------+ 215 | is | PKI Cert Issuance | [VU591120] | 216 | | (historical) | | 217 +------------------+-------------------------+--------------------+ 218 | it | PKI Cert Issuance | [VU591120] | 219 | | (historical) | | 220 +------------------+-------------------------+--------------------+ 221 | noc | Receive reports of | Section 4 of | 222 | | network problems | [RFC2142] | 223 +------------------+-------------------------+--------------------+ 224 | postmaster | Receive reports related | Section 5 of | 225 | | to SMTP service, PKI | [RFC2142], | 226 | | Cert Issuance | Section 3.2.2.4.4 | 227 | | | of [CABForum-BR] | 228 +------------------+-------------------------+--------------------+ 229 | root | Receive system software | [VU591120], FIXME: | 230 | | notifications, PKI Cert | find a reference | 231 | | Issuance (historic) | for root (software | 232 | | | config docs?) | 233 +------------------+-------------------------+--------------------+ 234 | security | Receive reports of | Section 4 of | 235 | | technical | [RFC2142] | 236 | | vulnerabilities | | 237 +------------------+-------------------------+--------------------+ 238 | ssladministrator | PKI Cert Issuance | [VU591120] | 239 | | (historical) | | 240 +------------------+-------------------------+--------------------+ 241 | ssladmin | PKI Cert Issuance | [VU591120] | 242 | | (historical) | | 243 +------------------+-------------------------+--------------------+ 244 | sslwebmaster | PKI Cert Issuance | [VU591120] | 245 | | (historical) | | 246 +------------------+-------------------------+--------------------+ 247 | sysadmin | PKI Cert Issuance | [VU591120] | 248 | | (historical) | | 249 +------------------+-------------------------+--------------------+ 250 | webmaster | PKI Cert Issuance, | Section 3.2.2.4.4 | 251 | | Receive reports related | of [CABForum-BR], | 252 | | to HTTP service | Section 5 of | 253 | | | [RFC2142] | 254 +------------------+-------------------------+--------------------+ 255 | www | Common alias for | Section 5 of | 256 | | webmaster | [RFC2142] | 257 +------------------+-------------------------+--------------------+ 259 Table 2: Dangerous E-mail local-parts 261 4. Security Considerations 263 Allowing untrusted parties to allocate names with the labels 264 associated in this document may grant access to administrative 265 capabilities. 267 The administrator of a DNS or E-mail service that permits any 268 untrusted party to register an arbitrary DNS label or e-mail local- 269 part for their own use SHOULD reject attempts to register the labels 270 listed here. 272 4.1. Additional Risks Out of Scope 274 The lists of security concerns in this document cover security risks 275 and concerns associated with interoperable use of specific labels. 276 They do not cover every possible security concern associated with any 277 DNS label or e-mail localpart. 279 For example, DNS labels with an existing underscore are likely by 280 construction to be sensitive, and are registered separately in the 281 registry defined by [RFC8552]. 283 Similarly, where humans or other systems capable of transcription 284 error are in the loop, subtle variations of the labels listed here 285 may also have security implications, due to homomgraphic confusion 286 ([Homograph]), but this document does not attempt to enumerate all 287 phishing, typosquatting, or similar risks of visual confusion, nor 288 does it exhaustively list all other potential risks associated with 289 variant encodings. See [UTR36] for a deeper understanding of these 290 categories of security concerns. 292 Additionally, some labels may be associated with security concerns 293 that happen to also commonly show up as DNS labels or e-mail local 294 parts, but their risk is not associated with their use in 295 interoperable public forms of DNS or e-mail. For example, on some 296 systems, a local user account named backup has full read access to 297 the local filesytsem so that it can transfer data to the local backup 298 system. And in some cases, the list of local user accounts is also 299 aliased into e-mail local parts. However, permitting the 300 registration of backup@example.net as an e-mail address is not itself 301 an interoperable security risk -- no external third party will treat 302 any part of the example.net domain differently because of the 303 registration. This document does not cover any risk entirely related 304 to internal configuration choices. 306 5. IANA Considerations 308 This document asks IANA to establish two registries, from Table 1 and 309 Table 2. 311 5.1. Dangerous DNS Labels Registry 313 The table of Dangerous DNS Labels (in Table 1) has three columns: 315 * DNS Label (text string) 317 * Rationale (human-readable short explanation) 319 * References (pointer or pointers to more detailed documentation) 321 Note that this table does not include anything that should be handled 322 by the pre-existing "Underscored and Globally Scoped DNS Node Names" 323 registry defined by [RFC8552]. 325 Following the guidance in [BCP26], any new entry to this registry 326 will be assigned using Specification Required. The IESG will assign 327 one or more designated experts for this purpose, who will consult 328 with the IETF DNSOP working group mailing list or its designated 329 successor. The Designated Expert will support IANA by clearly 330 indicating when a new DNS label should be added to this table, 331 offering the label itself, a brief rationale, and a pointer to the 332 permanent and readily available documentation of the security 333 consequences of the label. Updates or deletions of of DNS Labels 334 will follow the same process. 336 5.2. Dangerous E-mail Local Parts Registry 338 The table of Dangerous E-mail Local Parts (in Table 2 also has three 339 columns: 341 * E-mail local part (text string) 343 * Rationale (human-readable short explanation) 345 * References (pointer or ponters to more detailed documentation) 347 Following the guidance in [BCP26], any new entry to this registry 348 will be assigned using Specification Required. The IESG will assign 349 one or more designated experts for this purpose, who will consult 350 with the IETF EMAILCORE working group mailing list or its designated 351 successor. The Designated Expert will support IANA by clearly 352 indicating when a new e-mail local part should be added to this 353 table, offering the local part itself, a brief rationale, and a 354 pointer to the permanent and readily available documentation of the 355 security consequences of the local part. Updates or deletions of of 356 E-mail Local Parts will follow the same process. 358 5.3. Shared Considerations 360 Having to add a new security-sensitive entry to either of these 361 tables is likely to be a bad idea, because existing DNS zones and 362 e-mail installations may have already made an allocation of the novel 363 label, and cannot avoid the security implications. For a new 364 protocol that wants to include a label in either registry, there is 365 almost always a better protocol design choice. 367 Yet, if some common practice permits any form of administrative 368 control over a separate resource based on control over an arbitrary 369 label, administrators need a central place to keep track of which 370 labels are dangerous. 372 If such a practice cannot be avoided, it is better to ensure that the 373 risk is documented clearly and referenced in the appropriate 374 registry, rather than leaving it up to each administrator to re- 375 discover the problem. 377 6. References 378 6.1. Normative References 380 [BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 381 Writing an IANA Considerations Section in RFCs", BCP 26, 382 RFC 8126, June 2017. 384 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, 388 DOI 10.17487/RFC2119, March 1997, 389 . 391 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 392 DOI 10.17487/RFC5322, October 2008, 393 . 395 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 396 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 397 May 2017, . 399 [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource 400 Records through "Underscored" Naming of Attribute Leaves", 401 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 402 . 404 6.2. Informative References 406 [CABForum-BR] 407 Forum, C., "CA/Browser Forum Baseline Requirements", 23 408 April 2022, . 411 [Homograph] 412 "*** BROKEN REFERENCE ***". 414 [I-D.hoffman-dns-special-labels] 415 Hoffman, P., "IANA Registry for Special Labels in the 416 DNS", Work in Progress, Internet-Draft, draft-hoffman-dns- 417 special-labels-00, 1 October 2018, 418 . 421 [I-D.koch-openpgp-webkey-service] 422 Koch, W., "OpenPGP Web Key Directory", Work in Progress, 423 Internet-Draft, draft-koch-openpgp-webkey-service-14, 13 424 May 2022, . 427 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 428 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 429 . 431 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 432 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 433 January 2019, . 435 [RFC8509] Huston, G., Damas, J., and W. Kumari, "A Root Key Trust 436 Anchor Sentinel for DNSSEC", RFC 8509, 437 DOI 10.17487/RFC8509, December 2018, 438 . 440 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 441 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 442 September 2019, . 444 [UTR36] Davis, M. and M. Suignard, "Unicode Security 445 Considerations", n.d., 446 . 448 [VU591120] Center, C. C., "Multiple SSL certificate authorities use 449 predefined email addresses as proof of domain ownership", 450 7 April 2015, . 452 Appendix A. Acknowledgements 454 Many people created these dangerous labels or the authorization 455 processes that rely on them over the years. 457 Dave Crocker wrote an early list of special e-mail local-parts, from 458 [RFC2142]. 460 Paul Hoffman tried to document a wider survey of special DNS labels 461 (not all security-sensitive) in [I-D.hoffman-dns-special-labels]. 463 Appendix B. Document Considerations 465 RFC Editor: please remove this section before publication. 467 B.1. Other types of labels? 469 This document is limited to leftmost DNS labels and e-mail local- 470 parts because those are the arbitrary labels There may be other types 471 of arbitrary labels on the Internet with special values that have 472 security implications that the author is not aware of. 474 B.2. Document History 476 This section is to be removed before publishing as an RFC. 478 B.2.1. Substantive Changes from -00 to -01 480 * explicitly define IANA tables 482 * indicate that the tables use Specification Required 484 * clarify scope 486 Author's Address 488 Daniel Kahn Gillmor 489 American Civil Liberties Union 490 United States of America 491 Email: dkg@fifthhorseman.net