DMARC E. Osterweil Internet-Draft G. Wiley Intended status: Informational Verisign Expires: July 22, 2016 January 19, 2016 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 Osterweil & Wiley Expires July 22, 2016 [Page 1] Internet-Draft DMARC Extensions for DANE January 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Record Locators . . . . . . . . . . . . . . . . . . . . . 4 1.2. MUA Awareness . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Registry Additions . . . . . . . . . . . . . . . . . . . . . 5 2.1. Formal Definition . . . . . . . . . . . . . . . . . . . . 7 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 Osterweil & Wiley Expires July 22, 2016 [Page 2] Internet-Draft DMARC Extensions for DANE January 2016 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: o 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]. o 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." o 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: o 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? o 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? Osterweil & Wiley Expires July 22, 2016 [Page 3] Internet-Draft DMARC Extensions for DANE January 2016 * 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 Osterweil & Wiley Expires July 22, 2016 [Page 4] Internet-Draft DMARC Extensions for DANE January 2016 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. o "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 o "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 Osterweil & Wiley Expires July 22, 2016 [Page 5] Internet-Draft DMARC Extensions for DANE January 2016 uc: Upper case lcid: Lower case, ignore dots (as in some very large email service providers) none: No canonicalization rules are implemented, domain-wide. o "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. o "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 o "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. o "danesep": (plain-text; OPTIONAL; default is "optional") Indicates what (if any) requirements a sending domain has on whether a Osterweil & Wiley Expires July 22, 2016 [Page 6] Internet-Draft DMARC Extensions for DANE January 2016 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 ::= [ | ] + [ <0> | <1> | <2> ] danelhsc ::= | | | danersp ::= | | danerep ::= | | danessp ::= | | danesep ::= | | 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; " Osterweil & Wiley Expires July 22, 2016 [Page 7] Internet-Draft DMARC Extensions for DANE January 2016 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 Osterweil & Wiley Expires July 22, 2016 [Page 8] Internet-Draft DMARC Extensions for DANE January 2016 +---------+------------------------------+--------+-----------------+ | Tag | Ref | Status | Description | | Name | | | | +---------+------------------------------+--------+-----------------+ | danelhs | draft-osterweil-dmarc-dane- | curren | How is the LHS | | e | names | t | encoded into | | | | | DNS | | danelhs | draft-osterweil-dmarc-dane- | curren | How is canonica | | c | names | t | lization is | | | | | handled when | | | | | encoding lhs | | | | | into DNS | | danersp | draft-osterweil-dmarc-dane- | curren | What is a | | | names | t | receiving | | | | | policy for | | | | | signing (around | | | | | S/MIME using | | | | | DANE) for a | | | | | mail domain | | danerep | draft-osterweil-dmarc-dane- | curren | What is a | | | names | t | receiving | | | | | policy for | | | | | encryption | | | | | (around S/MIME | | | | | using DANE) for | | | | | a mail domain | | danessp | draft-osterweil-dmarc-dane- | curren | What is the | | | names | t | sending policy | | | | | for signing | | | | | (around S/MIME | | | | | w/ DANE) for a | | | | | mail domain | | danesep | draft-osterweil-dmarc-dane- | curren | What is the | | | names | t | sending policy | | | | | for encryption | | | | | (around S/MIME | | | | | w/ DANE) for a | | | | | mail domain | +---------+------------------------------+--------+-----------------+ Table 1: New tags 7. Security Considerations The tag-values specified in this document disambiguate important issues around DANE-based key learning. These values give mail administrators a new facility to securely announce their domain Osterweil & Wiley Expires July 22, 2016 [Page 9] Internet-Draft DMARC Extensions for DANE January 2016 policies around end-user signing and encryption. This work further enables key discovery for DANE protocols. 8. Normative References [I-D.ietf-dane-openpgpkey] Wouters, P., "Using DANE to Associate OpenPGP public keys with email addresses", April 2015. [I-D.ietf-dane-smime] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate Certificates with Domain Names For S/MIME", July 2013. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, DOI 10.17487/ RFC4846, July 2007, . [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, . [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . Osterweil & Wiley Expires July 22, 2016 [Page 10] Internet-Draft DMARC Extensions for DANE January 2016 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . Authors' Addresses Eric Osterweil Verisign Reston, VA USA Email: eosterweil@verisign.com Glen Wiley Verisign Reston, VA USA Email: gwiley@verisign.com Osterweil & Wiley Expires July 22, 2016 [Page 11]