Dangerous Labels in DNS and E-mail

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 November 2022.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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.¶

2. DNS Labels

Note that [RFC8552] 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 Section 8 of [RFC8499]), 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 Table 1, it indicates any sequence of five or more decimal digits, as described in [RFC8509].¶

3. E-mail Local Parts

Section 3.4.1 of [RFC5322] 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".¶

[RFC2142] offers some widespread historical practice for common local-parts. The CA/Browser Forum's Baseline Requirements ([CABForum-BR]) 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.¶

4. 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.¶

5. IANA Considerations

This document asks IANA to establish two registries, from Table 1 and Table 2.¶

Note that the DNS table in Table 1 does not include anything that should be handled by the pre-existing "Underscored and Globally Scoped DNS Node Names" registry defined by [RFC8552].¶

It's not clear how these registries should be updated.¶

Adding 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 access to a resource based on control over an arbitrary label, administrators need a central place to keep track of which labels are dangerous.¶

Appendix A. 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 [RFC2142].¶

Paul Hoffman tried to document a wider survey of special DNS labels (not all security-sensitive) in [I-D.hoffman-dns-special-labels].¶

Appendix B. Document Considerations

RFC Editor: please remove this section before publication.¶

Author's Address