]> American Civil Liberties Union

USA dkg@fifthhorseman.net

sec intarea Internet-Draft This document establishes registries that list known security-sensitive labels in the DNS and in e-mail contexts. It provides references and brief explanations about the risks associated with each known label. The registries established here offer guidance to the security-minded system administrator, who may not want to permit registration of these labels by untrusted users. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Internet Area Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Internet has a few places where seemingly arbitrary labels can show up and be used interchangeably. Some choices for those labels have surprising or tricky consequences. Reasonable admnistrators may want to be aware of those labels to avoid an accidental allocation that has security implications. This document registers a list of labels in DNS and e-mail systems that are known to have a security impact. It is not recommended to create more security-sensitive labels. Offering a stable registry of these dangerous labels is not an endorsement of the practice of using arbitrary labels in this way. A new protocol that proposes adding a label to this list is encouraged to find a different solution if at all possible.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

DNS Labels Note that defines the use of "underscored" labels which are treated differently than normal DNS labels, and often have security implications. That document also established the IANA registry for "Underscored and Globally Scoped DNS Node Names". That registry takes precedence to the list enumerated here, and any label in that list or with a leading underscore ("_") MUST NOT be included in this list. Below are some normal-looking DNS labels that may grant some form of administrative control over the domain that the are attached to. They are mostly "leftmost" or least-significant labels (in the sense used in ), in that if foo were listed here, it would be because granting control over the foo.example.net label (or control over the host pointed to by foo.example.net) to an untrusted party might offer that party some form of administrative control over other parts of example.org. Note: where "<key-tag>" occurs in , it indicates any sequence of five or more decimal digits, as described in . DNS Label Rationale Reference mta-sts Set SMTP transport security policy openpgpkey Domain-based OpenPGP certificate lookup and verification root-key-sentinel-is-ta-<key-tag> Indicates which DNSSEC root key is trusted root-key-sentinel-not-ta-<key-tag> Indicates which DNSSEC root key is not trusted www Popular web browsers guess this label FIXME: find a reference

E-mail Local Parts defines the local-part of an e-mail address (the part before the "@" sign) as "domain-dependent". However, allocating some specific local-parts to an untrusted party can have significant security consequences for the domain or other associated resources. Note that all these labels are expected to be case-insensitive. That is, an administrator restricting registration of a local-part named "admin" MUST also apply the same constraint to "Admin" or "ADMIN" or "aDmIn". offers some widespread historical practice for common local-parts. The CA/Browser Forum's Baseline Requirements () constrain how any popular Public Key Infrastructure (PKI) Certification Authority (CA) should confirm domain ownership when verifying by e-mail. The public CAs used by popular web browsers ("web PKI") will adhere to these guidelines, but anyone relying on unusual CAs may still be subject to risk additional labels described here. E-mail local-part Rationale References abuse Receive reports of abusive public behavior administrator PKI Cert Issuance Section 3.2.2.4.4 of admin PKI Cert Issuance Section 3.2.2.4.4 of hostmaster PKI Cert Issuance, DNS zone control Section 3.2.2.4.4 of , info PKI Cert Issuance (historical) is PKI Cert Issuance (historical) it PKI Cert Issuance (historical) noc Receive reports of network problems postmaster Receive reports related to SMTP service, PKI Cert Issuance , Section 3.2.2.4.4 of root Receive system software notifications, PKI Cert Issuance (historic) , FIXME: find a reference for root (software config docs?) security Receive reports of technical vulnerabilities ssladministrator PKI Cert Issuance (historical) ssladmin PKI Cert Issuance (historical) sslwebmaster PKI Cert Issuance (historical) sysadmin PKI Cert Issuance (historical) webmaster PKI Cert Issuance, Receive reports related to HTTP service Section 3.2.2.4.4 of , www Common alias for webmaster

Security Considerations Allowing untrusted parties to allocate names with the labels associated in this document may grant access to administrative capabilities. The administrator of a DNS or E-mail service that permits any untrusted party to register an arbitrary DNS label or e-mail local-part for their own use SHOULD reject attempts to register the labels listed here.

Additional Risks Out of Scope The lists of security concerns in this document cover security risks and concerns associated with interoperable use of specific labels. They do not cover every possible security concern associated with any DNS label or e-mail localpart. For example, DNS labels with an existing underscore are likely by construction to be sensitive, and are registered separately in the registry defined by . Similarly, where humans or other systems capable of transcription error are in the loop, subtle variations of the labels listed here may also have security implications, due to homomgraphic confusion (), but this document does not attempt to enumerate all phishing, typosquatting, or similar risks of visual confusion, nor does it exhaustively list all other potential risks associated with variant encodings. See for a deeper understanding of these categories of security concerns. Additionally, some labels may be associated with security concerns that happen to also commonly show up as DNS labels or e-mail local parts, but their risk is not associated with their use in interoperable public forms of DNS or e-mail. For example, on some systems, a local user account named backup has full read access to the local filesytsem so that it can transfer data to the local backup system. And in some cases, the list of local user accounts is also aliased into e-mail local parts. However, permitting the registration of backup@example.net as an e-mail address is not itself an interoperable security risk -- no external third party will treat any part of the example.net domain differently because of the registration. This document does not cover any risk entirely related to internal configuration choices.

IANA Considerations This document asks IANA to establish two registries, from and .

Dangerous DNS Labels Registry The table of Dangerous DNS Labels (in ) has three columns: DNS Label (text string) Rationale (human-readable short explanation) References (pointer or pointers to more detailed documentation) Note that this table does not include anything that should be handled by the pre-existing "Underscored and Globally Scoped DNS Node Names" registry defined by . Following the guidance in , any new entry to this registry will be assigned using Specification Required. The IESG will assign one or more designated experts for this purpose, who will consult with the IETF DNSOP working group mailing list or its designated successor. The Designated Expert will support IANA by clearly indicating when a new DNS label should be added to this table, offering the label itself, a brief rationale, and a pointer to the permanent and readily available documentation of the security consequences of the label. Updates or deletions of of DNS Labels will follow the same process.

Dangerous E-mail Local Parts Registry The table of Dangerous E-mail Local Parts (in also has three columns: E-mail local part (text string) Rationale (human-readable short explanation) References (pointer or ponters to more detailed documentation) Following the guidance in , any new entry to this registry will be assigned using Specification Required. The IESG will assign one or more designated experts for this purpose, who will consult with the IETF EMAILCORE working group mailing list or its designated successor. The Designated Expert will support IANA by clearly indicating when a new e-mail local part should be added to this table, offering the local part itself, a brief rationale, and a pointer to the permanent and readily available documentation of the security consequences of the local part. Updates or deletions of of E-mail Local Parts will follow the same process.

Shared Considerations Having to add a new security-sensitive entry to either of these tables is likely to be a bad idea, because existing DNS zones and e-mail installations may have already made an allocation of the novel label, and cannot avoid the security implications. For a new protocol that wants to include a label in either registry, there is almost always a better protocol design choice. Yet, if some common practice permits any form of administrative control over a separate resource based on control over an arbitrary label, administrators need a central place to keep track of which labels are dangerous. If such a practice cannot be avoided, it is better to ensure that the risk is documented clearly and referenced in the appropriate registry, rather than leaving it up to each administrator to re-discover the problem.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.This document obsoletes RFC 7719 and updates RFC 2308. The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. GnuPG e.V. This specification describes a service to locate OpenPGP keys by mail address using a Web service and the HTTPS protocol. It also provides a method for secure communication between the key owner and the mail provider to publish and revoke the public key. This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK] ICANN This document defines an new IANA registry for special labels in the DNS. The registry is useful because the labels cause special handling in DNS entities such as stub resolvers, recursive resolvers, and applications that use DNS, and developers of software for those entities should be aware of the many types of special labels in use. [[ A GitHub repo for this document is at https://github.com/paulehoffman/dns-special-labels ]]

Acknowledgements Many people created these dangerous labels or the authorization processes that rely on them over the years. Dave Crocker wrote an early list of special e-mail local-parts, from . Paul Hoffman tried to document a wider survey of special DNS labels (not all security-sensitive) in .

Document Considerations RFC Editor: please remove this section before publication.

Other types of labels? This document is limited to leftmost DNS labels and e-mail local-parts because those are the arbitrary labels There may be other types of arbitrary labels on the Internet with special values that have security implications that the author is not aware of.

Document History

Substantive Changes from -00 to -01 explicitly define IANA tables indicate that the tables use Specification Required clarify scope