idnits 2.17.00 (12 Aug 2021) /tmp/idnits59394/draft-dkg-intarea-dangerous-labels-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 document date (6 May 2022) is 8 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-koch-openpgp-webkey-service-13 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 6 May 2022 5 Expires: 7 November 2022 7 Dangerous Labels in DNS and E-mail 8 draft-dkg-intarea-dangerous-labels-00 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 7 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 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 6.2. Informative References . . . . . . . . . . . . . . . . . 7 80 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 81 Appendix B. Document Considerations . . . . . . . . . . . . . . 8 82 B.1. Other types of labels? . . . . . . . . . . . . . . . . . 8 83 B.2. Document History . . . . . . . . . . . . . . . . . . . . 8 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 86 1. Introduction 88 The Internet has a few places where seemingly arbitrary labels can 89 show up and be used interchangeably. 91 Some choices for those labels have surprising or tricky consequences. 92 Reasonable admnistrators may want to be aware of those labels to 93 avoid an accidental allocation that has security implications. 95 This document registers a list of labels in DNS and e-mail systems 96 that are known to have a security impact. It is not recommended to 97 create more security-sensitive labels. 99 Offering a stable registry of these dangerous labels is not an 100 endorsement of the practice of using arbitrary labels in this way. A 101 new protocol that proposes adding a label to this list is encouraged 102 to find a different solution if at all possible. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in 109 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 2. DNS Labels 114 Note that [RFC8552] defines the use of "underscored" labels which are 115 treated differently than normal DNS labels, and often have security 116 implications. That document also established the IANA registry for 117 "Underscored and Globally Scoped DNS Node Names". That registry 118 takes precedence to the list enumerated here, and any label in that 119 list or with a leading underscore ("_") MUST NOT be included in this 120 list. 122 Below are some normal-looking DNS labels that may grant some form of 123 administrative control over the domain that the are attached to. 125 They are mostly "leftmost" or least-significant labels (in the sense 126 used in Section 8 of [RFC8499]), in that if foo were listed here, it 127 would be because granting control over the foo.example.net label (or 128 control over the host pointed to by foo.example.net) to an untrusted 129 party might offer that party some form of administrative control over 130 other parts of example.org. 132 Note: where "" occurs in Table 1, it indicates any sequence 133 of five or more decimal digits, as described in [RFC8509]. 135 +===============+==================================================+ 136 | DNS Label | Rationale and References | 137 +===============+==================================================+ 138 | mta-sts | Set SMTP transport security policy ([RFC8641]) | 139 +---------------+--------------------------------------------------+ 140 | openpgpkey | Domain-based OpenPGP certificate lookup and | 141 | | verification ([I-D.koch-openpgp-webkey-service]) | 142 +---------------+--------------------------------------------------+ 143 | root-key- | Indicates which DNSSEC root key is trusted | 144 | sentinel-is- | ([RFC8509] | 145 | ta- | | 146 +---------------+--------------------------------------------------+ 147 | root-key- | Indicates which DNSSEC root key is not trusted | 148 | sentinel-not- | ([RFC8509] | 149 | ta- | | 150 +---------------+--------------------------------------------------+ 151 | www | Popular web browsers guess this label (???) | 152 +---------------+--------------------------------------------------+ 154 Table 1: Dangerous DNS labels 156 3. E-mail Local Parts 158 Section 3.4.1 of [RFC5322] defines the local-part of an e-mail 159 address (the part before the "@" sign) as "domain-dependent". 160 However, allocating some specific local-parts to an untrusted party 161 can have significant security consequences for the domain or other 162 associated resources. 164 Note that all these labels are expected to be case-insensitive. That 165 is, an administrator restricting registration of a local-part named 166 "admin" MUST also apply the same constraint to "Admin" or "ADMIN" or 167 "aDmIn". 169 [RFC2142] offers some widespread historical practice for common 170 local-parts. The CA/Browser Forum's Baseline Requirements 171 ([CABForum-BR]) constrain how any popular Public Key Infrastructure 172 (PKI) Certification Authority (CA) should confirm domain ownership 173 when verifying by e-mail. The public CAs used by popular web 174 browsers ("web PKI") will adhere to these guidelines, but anyone 175 relying on unusual CAs may still be subject to risk additional labels 176 described here. 178 +==================+=============================================+ 179 | E-mail local- | Rationale and References | 180 | part | | 181 +==================+=============================================+ 182 | abuse | Receive reports of abusive public behavior | 183 | | (Section 2 of [RFC2142]) | 184 +------------------+---------------------------------------------+ 185 | administrator | PKI Cert Issuance (Section 3.2.2.4.4 of | 186 | | [CABForum-BR]) | 187 +------------------+---------------------------------------------+ 188 | admin | PKI Cert Issuance (Section 3.2.2.4.4 of | 189 | | [CABForum-BR]) | 190 +------------------+---------------------------------------------+ 191 | hostmaster | PKI Cert Issuance (Section 3.2.2.4.4 of | 192 | | [CABForum-BR]), DNS zone control (Section 7 | 193 | | of [RFC2142]) | 194 +------------------+---------------------------------------------+ 195 | info | PKI Cert Issuance (historical, see | 196 | | [VU591120]) | 197 +------------------+---------------------------------------------+ 198 | is | PKI Cert Issuance (historical, see | 199 | | [VU591120]) | 200 +------------------+---------------------------------------------+ 201 | it | PKI Cert Issuance (historical, see | 202 | | [VU591120]) | 203 +------------------+---------------------------------------------+ 204 | noc | Receive reports of network problems | 205 | | (Section 4 of [RFC2142]) | 206 +------------------+---------------------------------------------+ 207 | postmaster | Receive reports related to SMTP service | 208 | | (Section 5 of [RFC2142]), PKI Cert Issuance | 209 | | ( Section 3.2.2.4.4 of [CABForum-BR]) | 210 +------------------+---------------------------------------------+ 211 | root | Receive system software notifications | 212 | | (???), PKI Cert Issuance (historical, see | 213 | | [VU591120]) | 214 +------------------+---------------------------------------------+ 215 | security | Receive reports of technical | 216 | | vulnerabilities (Section 4 of [RFC2142]) | 217 +------------------+---------------------------------------------+ 218 | ssladministrator | PKI Cert Issuance (historical, see | 219 | | [VU591120]) | 220 +------------------+---------------------------------------------+ 221 | ssladmin | PKI Cert Issuance (historical, see | 222 | | [VU591120]) | 223 +------------------+---------------------------------------------+ 224 | sslwebmaster | PKI Cert Issuance (historical, see | 225 | | [VU591120]) | 226 +------------------+---------------------------------------------+ 227 | sysadmin | PKI Cert Issuance (historical, see | 228 | | [VU591120]) | 229 +------------------+---------------------------------------------+ 230 | webmaster | PKI Cert Issuance (Section 3.2.2.4.4 of | 231 | | [CABForum-BR]), Receive reports related to | 232 | | HTTP service (Section 5 of [RFC2142]) | 233 +------------------+---------------------------------------------+ 234 | www | Common alias for webmaster (Section 5 of | 235 | | [RFC2142]) | 236 +------------------+---------------------------------------------+ 238 Table 2: Dangerous E-mail local-parts 240 4. Security Considerations 242 Allowing untrusted parties to allocate names with the labels 243 associated in this document may grant access to administrative 244 capabilities. 246 The administrator of a DNS or E-mail service that permits any 247 untrusted party to register an arbitrary DNS label or e-mail local- 248 part for their own use SHOULD reject attempts to register the labels 249 listed here. 251 5. IANA Considerations 253 This document asks IANA to establish two registries, from Table 1 and 254 Table 2. 256 Note that the DNS table in Table 1 does not include anything that 257 should be handled by the pre-existing "Underscored and Globally 258 Scoped DNS Node Names" registry defined by [RFC8552]. 260 It's not clear how these registries should be updated. 262 Adding a new security-sensitive entry to either of these tables is 263 likely to be a bad idea, because existing DNS zones and e-mail 264 installations may have already made an allocation of the novel label, 265 and cannot avoid the security implications. For a new protocol that 266 wants to include a label in either registry, there is almost always a 267 better protocol design choice. 269 Yet, if some common practice permits any form of administrative 270 access to a resource based on control over an arbitrary label, 271 administrators need a central place to keep track of which labels are 272 dangerous. 274 6. References 276 6.1. Normative References 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, 280 DOI 10.17487/RFC2119, March 1997, 281 . 283 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 284 DOI 10.17487/RFC5322, October 2008, 285 . 287 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 288 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 289 May 2017, . 291 [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource 292 Records through "Underscored" Naming of Attribute Leaves", 293 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 294 . 296 6.2. Informative References 298 [CABForum-BR] 299 Forum, C., "CA/Browser Forum Baseline Requirements", 23 300 April 2022, . 303 [I-D.hoffman-dns-special-labels] 304 Hoffman, P., "IANA Registry for Special Labels in the 305 DNS", Work in Progress, Internet-Draft, draft-hoffman-dns- 306 special-labels-00, 1 October 2018, 307 . 310 [I-D.koch-openpgp-webkey-service] 311 Koch, W., "OpenPGP Web Key Directory", Work in Progress, 312 Internet-Draft, draft-koch-openpgp-webkey-service-13, 14 313 November 2021, . 316 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 317 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 318 . 320 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 321 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 322 January 2019, . 324 [RFC8509] Huston, G., Damas, J., and W. Kumari, "A Root Key Trust 325 Anchor Sentinel for DNSSEC", RFC 8509, 326 DOI 10.17487/RFC8509, December 2018, 327 . 329 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 330 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 331 September 2019, . 333 [VU591120] Center, C. C., "Multiple SSL certificate authorities use 334 predefined email addresses as proof of domain ownership", 335 7 April 2015, . 337 Appendix A. Acknowledgements 339 Many people created these dangerous labels or the authorization 340 processes that rely on them over the years. 342 Dave Crocker wrote an early list of special e-mail local-parts, from 343 [RFC2142]. 345 Paul Hoffman tried to document a wider survey of special DNS labels 346 (not all security-sensitive) in [I-D.hoffman-dns-special-labels]. 348 Appendix B. Document Considerations 350 RFC Editor: please remove this section before publication. 352 B.1. Other types of labels? 354 This document is limited to leftmost DNS labels and e-mail local- 355 parts because those are the arbitrary labels There may be other types 356 of arbitrary labels on the Internet with special values that have 357 security implications that the author is not aware of. 359 B.2. Document History 361 /No history yet/ 363 Author's Address 365 Daniel Kahn Gillmor 366 American Civil Liberties Union 367 United States of America 368 Email: dkg@fifthhorseman.net