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 ::= [ <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; "
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,
<http://www.rfc-editor.org/info/rfc4846>.
[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, <http://www.rfc-editor.org/info/rfc5751>.
[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,
<http://www.rfc-editor.org/info/rfc6376>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<http://www.rfc-editor.org/info/rfc7208>.
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,
<http://www.rfc-editor.org/info/rfc7489>.
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]