DMARC Extensions for DANE
draft-osterweil-dmarc-dane-names-00

Abstract

This document proposes additions to the Domain-based Message Authentication, Reporting, and Conformance (DMARC) Tag Registry to enable Mail administrators to specify the domain-wide policies for S/MIME and PGP key usage in their mail domains, in conjunction with use of the DANE SMIMEA and OPENPGPKEY resource records. This would mean adding to the authentication mechanisms specified in RFC 7489, but it would specify only the domain-wide policies for S/MIME and PGP, such as what the policies are for signing and encrypting (does the sender mandate it, not allow it, etc.). This document also suggests the specification of the type of encoding of the left-hand sides used in the DANE resource records.

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 http://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 July 22, 2016.

Copyright Notice

Copyright (c) 2016 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Record Locators
• 1.2. MUA Awareness
• 1.3. Requirements Language
• 2. Registry Additions
• 2.1. Formal Definition
• 3. Examples
• 4. Benefits
• 5. Acknowledgements
• 6. IANA Considerations
• 7. Security Considerations
• 8. Normative References
• Authors' Addresses

1. Introduction

This document proposes additions to the Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489] Tag Registry to enable Mail administrators to specify the domain-wide policies for S/MIME and PGP key usage in their mail domains, in conjunction with use of the DANE SMIMEA [I-D.ietf-dane-smime] and OPENPGPKEY [I-D.ietf-dane-openpgpkey] resource records. This would mean adding to the authentication mechanisms specified in RFC 7489, but it would specify only the domain-wide policies for Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751] and PGP, such as what the policies are for signing and encrypting (does the sender mandate it, not allow it, etc.). This document also suggests the specification of the type of encoding of the left-hand sides used in the DANE resource records.

DMARC is aimed to "express domain-level policies and preferences for message validation, disposition, and reporting that mail-receiving organizations can use to improve mail handling." [RFC7489]. In addition, consumption of DMARC records is primarily aimed at receiving SMTP server. Consideration for including S/MIME is discussed in [RFC7489] Appendix A.1. There, the document lists several reasons why S/MIME was not a proper fit for DMARC, initially. However, with recent work in the DANE working group on an SMIMEA DNS RR type, the previous obstacles for broad S/MIME deployment have either disappeared, or are now surmountable.

Previous concerns for incorporating S/MIME into DMARC include:

• The previous implicit requirements for a "heavyweight ... PKI" are now obviated by DANE's use of DNS [RFC1035] and the DNS Security Extension (DNSSEC) [RFC4035].
• Deployment of DANE's SMIMEA record will operationally benefit from the additions proposed in this document, and this directly addresses the previous concern that incorporating S/MIME semantics into DMARC "would neither cause nor enable a substantial increase in the accuracy of the overall mechanism."
• Finally, DMARC focuses on "authentication at the domain level," but recent work in the DANE working group has raised the issue that domain-level policies (including LHS encoding and canonicalization) are domain level policies that need to be learned by receiving side domains in order to learn S/MIME keys for users. Senders must learn their receivers' policies for encryption and receivers must learn senders' policies in order to properly perform signature verification.

The enhancements added by this document (as additions to DMARC's "DMARC Tag Registry") are to enable S/MIME (and Open PGP) with DANE, and will allow:

• Mail senders to have an option to ingest DMARC records (whereas before, DMARC was primarily focused on the mail receiver). Mail senders will now, optionally, be able to ascertain:
  • What (if any) are the signing or encryption requirements of a domain?
  • What is the encoding technique for LHS portions of an email address?
  • What is the canonicalization policy of LHS portions of email addresses in a domain?

• Mail receivers to learn:
  • Does a sending domain have any mandatory signing or encryption rules for outbound emails?
  • What is the encoding technique for LHS portions of an email address?
  • What is the canonicalization policy of LHS portions of email addresses in a domain?

1.1. Record Locators

The per-user records such as SMIMEA and OPENPGPKEY specify that the LHS of an email address be encoded so that it can be used to locate an RR published for a specific user. Some domains may opt for hashed labels (such as SHA224), some may opt for Base32 encoded labels, etc. In addition, specifying the canonicalization of case for LHS lookups ensures that mail domains can choose how to encode the LHS and how Mail User Agents (MUAs) can learn this. An MUA MUST query the DNS for an SMIMEA or OPENPGPKEY record using the canonicalization and encoding policy in the DMARC records for the domain. For example, a mail address like "JSmith@example.com" can be down-cased and SHA224 hashed to become: "b7b7da967f26e6ee45e4eeb92ce64cd126a39635c83e8ac6c3f68649", and MUAs must be able to learn these domain-level conventions.

The LHS of the email address in the RFC5322.From field is used to locate the SMIMEA or OPENPGPKEY record that provides signing keys.

The reason that canonicalization and encoding policy discovery is important for senders and receivers is because there is considerable debate regarding which algorithms for canonicalization and encoding of the LHS of email addresses should be used to construct the labels that comprise the domain name of a RR. Some large email providers have chosen to implement canonicalization that is not consistent with the standard.

Using the additions to DMARC described in this document a domain may publish its canonicalization algorithm which will allow accurate construction of the labels for a record corresponding to a specific email address.

Domains which choose to encode the LHS of a canonicalized email address may prefer a hash rather than a simple encoding to address privacy concerns, inhibit zone walking, or for other reasons. The additions in this document provide a means for a domain to publish an encoding algorithm, which will allow mail receivers and senders to accurately construct the labels for a record corresponding to a specific email address.

1.2. MUA Awareness

The previous specification of DMARC is almost entirely relevant to the MTA and transparent to the end user. The additions in this document are also relevant to the MUA, even though an MTA/MDA may use the policy published in a DMARC record using these new tags, For example a mail user who composes a message can be warned that the domain to which the message is directed requires that all messages be signed by the sender.

1.3. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. Registry Additions

This document outlines six types of domain-level policies that MAY be needed by either sender mail domains or receiver mail domains: 1) DANE LHS Encoding: "danelhse", 2) DANE LHS Canonicalization: "danelhsc", 3) DANE Receiving-side Signing Policy: "danersp", 4) DANE Receiving-side Encryption Policy: "danerep", 5) DANE Sending-side Signing Policy: "danessp", and 6) DANE Sending-side Encryption Policy: "danesep".

As specified in [RFC7489], DMARC follows the extensible "tag-value" syntax.

• "danelhse": (plain-text; OPTIONAL; default is "L0".) Indicates how an email address is encoded in the corresponding label in DNS. The value is a concatenation of 'F' (LHS with domain) or 'L' (LHS only) which indicates whether the domain part is included in the encoding. Valid values are:
  • F0: Truncated SHA256, [RFC4846], LHS and domain
  • F1: SHA224, LHS and domain
  • F2: Base32, [RFC4648], LHS and domain
  • L0: Truncated SHA256, [RFC4846], LHS only
  • L1: SHA224, LHS only
  • L2: Base32, [RFC4648], LHS only

• "danelhsc": (plain-text; OPTIONAL; default is "lc".) Indicates how the LHS component of email addresses in the domain are canonicalized before being encoded. Valid values are:
  • lc: Lower case
  • uc: Upper case
  • lcid: Lower case, ignore dots (as in some very large email service providers)
  • none: No canonicalization rules are implemented, domain-wide.

• "danersp": (plain-text; OPTIONAL; default is "optional") Indicates what (if any) requirements a receiving domain has on whether email SHOULD be signed in order to be accepted. Valid values are:
  • required: Emails MUST be signed
  • optional: Emails MAY be signed
  • forbidden: Emails MUST NOT be signed

  The signing policy indicated by this tag refers to signing using (for example) SMIMEA or OPENPGPKEY records associated with the sender's email address in the domain.

• "danerep": (plain-text; OPTIONAL; default is "optional") Indicates what (if any) requirements a receiving domain has on whether email SHOULD be encrypted in order to be accepted. Valid values are:
  • required: Emails MUST be encrypted
  • optional: Emails MAY be encrypted
  • forbidden: Emails MUST NOT be encrypted

• "danessp": (plain-text; OPTIONAL; default is "optional") Indicates what (if any) requirements a sending domain has on whether a receiving domain SHOULD consider email originating from the sending domain legitimate. Valid values are:
  • required: Emails MUST be signed
  • optional: Emails MAY be signed
  • forbidden: Emails MUST NOT be signed

  The signing policy indicated by this tag refers to signing using SMIMEA or OPENPGPKEY records associated with the sender's email address in the domain.

• "danesep": (plain-text; OPTIONAL; default is "optional") Indicates what (if any) requirements a sending domain has on whether a receiving domain SHOULD consider email originating from the sending domain legitimate. Valid values are:
  • required: Emails MUST be encrypted
  • optional: Emails MAY be encrypted
  • forbidden: Emails MUST NOT be encrypted

2.1. Formal Definition

The formal definition of the tag-values above, using Section 2.1 is:

• danelhse ::= [ <F> | <L> ] + [ <0> | <1> | <2> ]
• danelhsc ::= <uc> | <lc> | <lcid> | <none>
• danersp ::= <required> | <optional> | <forbidden>
• danerep ::= <required> | <optional> | <forbidden>
• danessp ::= <required> | <optional> | <forbidden>
• danesep ::= <required> | <optional> | <forbidden>

3. Examples

These examples explore some permutations of the additions in this document but do not explore the uses of tags already present in DMARC. The existing policy tags are not relevant but are included for context.

In the following example TXT record, the domain has published a policy indicating that email addresses used to locate SMIMEA or OPENPGPKEY records should be converted to lower case and then the LHS and domain are encoded using base32.

• "v=DMARC1; p=none; danelhsc=lc; danelhse=F2; rua=mailto:postmaster@example.com; "

In the following example TXT record, the domain has published a policy indicating that messages sent to the domain must be signed by the sender.

• "v=DMARC1; p=none; danersp=required; rua=mailto:postmaster@example.com; "

4. Benefits

These additions give mail administrators semantics to address policies around how their domains should handle email with (for example) S/MIME protections. They also remove guesswork around how mail domains should handle DANE key learning.

By recognizing the current approach to canonicalization by large scale email implementations these additions make it possible to accommodate existing widely deployed policies.

5. Acknowledgements

This draft was was greatly benefited by feedback from Danny McPherson. In addition, helpful insights were given my Doug Montgomery.

6. IANA Considerations

This memo includes a request to IANA to update the IANA sub-registry called "DMARC Tag Registry". The sub-registry will need new "current" tags