Delegating DKIM Signing Authority
draft-kucherawy-dkim-delegate-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Murray Kucherawy , Dave Crocker | ||
| Last updated | 2014-06-07 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kucherawy-dkim-delegate-00
Network Working Group M. Kucherawy
Internet-Draft
Intended status: Experimental D. Crocker
Expires: December 9, 2014 Brandenburg InternetWorking
June 7, 2014
Delegating DKIM Signing Authority
draft-kucherawy-dkim-delegate-00
Abstract
DomainKeys Identified Mail (DKIM) permits a handling agent to affix a
digital signature to an email message, associating a domain name with
that message using cryptographic signing techniques. The digital
signature typically covers most of a message's original portions,
although the specific choices for content hashing are at the
discretion of the signer. DKIM signatures survive simply email
relaying but typically are invalidated by processing through
Mediators, such as mailing lists. For such cases, the signer needs a
way to indicate that a valid signature from some third party was
anticipated, and constitutes an acceptable handling of the message.
This enables a receiver to conclude that the content is legitimately
from that original signer, even though its original signature no
longer validates.
This document defines a mechanism for improving the ability to assess
DKIM validity for such messages.
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 December 9, 2014.
Copyright Notice
Kucherawy & Crocker Expires December 9, 2014 [Page 1]
Internet-Draft DKIM-Delegate June 2014
Copyright (c) 2014 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. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DKIM-Delegate Specification . . . . . . . . . . . . . . . . . 4
3.1. Design Summary . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Specification . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Considerations for Secondary Signatures . . . . . . . . . . . 6
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Detecting Header Changes . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 10
Kucherawy & Crocker Expires December 9, 2014 [Page 2]
Internet-Draft DKIM-Delegate June 2014
1. Background
DomainKeys Identified Mail [RFC6376] defines a mechanism whereby a
verified domain name can be attached to a message, using a
cryptographic signature. It does not, however, assert that this
domain name matches a domain name found anywhere else in the message.
DKIM signature survival is usually successful through basic email
relaying nodes. It also survives simple Mediators, such as mailbox
forwarding agents, because they only modify the message envelope and
do not modify the original message header or body. Transit through
other Mediators, such as mailing lists, is usually problematic,
because they modify portions of the message covered by the signature
and therefore invalidate it.
When a receiver needs to determine whether a message was legitimately
processed by a purported original signer, a mechanism is needed that
is more likely to survive transit through Mediators. This need is
especially strong for environments wishing to enforce policy linkage
between the author, the author's domain and specific email service
providers, such as when the latter two are the same. An example of
such a need is when that original signer publishes policies
concerning the use of its domain name. Examples are ADSP [RFC5617]
and DMARC [I-D.KUCHERAWY-DMARC-BASE]. These policies cannot be
applied properly when legitimate mail for the original signer's
domain cannot be validated by the final Receiver. The potential for
malfunction otherwise is described in Section 5.2 of [RFC6377].
The issues with mailing lists and similar re-mailing applications can
be resolved by a mechanism that permits the original signer's domain
("A") to indicate that some other domain ("B") is explicitly
permitted to re-sign content generated by "A", such that a Receiver
can observe signaling from both "A" and "B" that this relationship
exists.
An experimental attempt to do this appeared in [RFC6541]. The method
presented there imposes a burden on the original signing domain to
publish those relationships a priori, via the DNS. This proved
cumbersome with poor scaling properties. So, a mechanism that does
not have such an external dependency is preferred.
2. Definitions
Numerous terms used here, especially "Author", "Originator",
"Receiver", and "Recipient", are defined in [RFC5598]. DKIM-related
terminology, such as "Signing Domain", are taken from the DKIM
specification [RFC6376].
Kucherawy & Crocker Expires December 9, 2014 [Page 3]
Internet-Draft DKIM-Delegate June 2014
3. DKIM-Delegate Specification
An email header field, called "DKIM-Delegate", is defined. When
present, it asserts an ephemeral relationship between an original
message signing domain and a later intermediary (Mediator).
3.1. Design Summary
An "Original Signer" (typically the Originator serving the Author)
affixes two DKIM signatures to a message. One is of the usual type,
covering the entire message, and the second is tailored to better
survive transit through Mediators such as authorized mailing lists.
A DKIM-Delegate field is added to the message, to indicate that this
mechanism is in force; this is covered by the second signature (and
possibly, but not necessarily, the first). Optionally, a Mediator
also signs the message, to provide a reliable indication of handling
by the Mediator. If a Receiver finds that the Original Signer's
"normal" signature does not validate or is missing, it can perform
DKIM-Delegate evaluation.
In combination with DKIM signatures, this mechanism can aid a
receiver in assessing whether the message was legitimately handled by
the intermediary and whether the message was likely to have had a
legitimate signature by the original signing domain, even when that
original signature became invalid. This makes it possible to
identify such messages separately from those without these
assurances, and thus permits treating the latter with more
skepticism.
3.2. Specification
The specific mechanism operates as follows:
1. A "Primary" DKIM Signature is affixed to a message by a handling
agent, identifying the Originator's domain and using typical
signing choices, such as covering the entire message content in
the body hash. (That is, it does not use the "l=" tag.)
2. The signer adds a DKIM-Delegate header field identifying the
Originator's domain. It can also identify the specific
domain(s) with which it wishes to claim an ephemeral
relationship; absent this indication, the list of candidate
domains is implicit from elsewhere in the message header (see
below).
3. The signer affixes a "Secondary" DKIM signature that is
configured so as to better survive transit through the delegated
domain(s). The distinctive characteristic of a Secondary
Kucherawy & Crocker Expires December 9, 2014 [Page 4]
Internet-Draft DKIM-Delegate June 2014
signature is that its hashes cover less of the message; it also
might use more permissive canonicalization and/or have an
especially short expiration time. The signature MUST cover the
DKIM-Delegate header field, in order to validate its use for the
message. Suggestions for details of a Secondary signature are
discussed in Section 4.
4. An authorized Mediator SHOULD affix its own, normal DKIM
signature to the message.
5. The Receiver attempts to validate the primary signature affixed
by the original signer. If it is valid, the requirements of
this profile are satisfied (and the algorithm terminates here).
6. The Receiver attempts to validate the Secondary (delegation)
signature affixed by the original signer. If it is not valid
(or not found), the requirements of this profile cannot be
satisfied (and the algorithm terminates here).
7. The Receiver confirms that the Secondary signature header hash
includes at least the DKIM-Delegate header field, and that the
"d=" value in the Secondary signature matches the "d=" value in
the DKIM-Delegate field. If either is not true, the
requirements of this profile cannot be satisfied (and the
algorithm terminates here).
8. If the DKIM-Delegate field includes a list of domain names to
which delegation of re-signing authority is claimed, call this
set "D".
9. If the DKIM-Delegate signature does not include such a list, the
Receiver collects all header fields that were covered by the
header hash of the Secondary DKIM signature and that contain
recipient addresses. These can be found in that signature's
"h=" tag. The obvious examples are the To and Cc fields (if
present). The Receiver extracts the set of domain names from
the collected header fields, and calls this set "D".
10. The Receiver performs normal validation checks of all other DKIM
signatures on the message that include the entire message body
in their body hashes, and stores the set of domains from passing
signatures in set "S".
11. If the intersection of "D" and "S" is not empty, the
requirements of this profile are satisfied; otherwise, the
requirements are not satisfied.
Kucherawy & Crocker Expires December 9, 2014 [Page 5]
Internet-Draft DKIM-Delegate June 2014
3.3. Syntax
The content of the DKIM-Delegate header field is a tag-list as
defined in Section 3.2 of [RFC6376]. The valid tags are:
d= Author domain (plain-text; REQUIRED). This value names the domain
of the Author, which is delegating signing authority to one or
more other domains.
t= Delegation target (plain-text; OPTIONAL). This value is a comma-
separated list of domain names to which the authority to sign on
behalf of the Author domain is being delegated. When not present,
this list is inferred from the domain names present in the
recipient fields (To, Cc) of the header.
As with DKIM itself, any other tag MUST be ignored.
4. Considerations for Secondary Signatures
The Secondary (delegation) signature MUST cover at least the DKIM-
Delegate field and the visible recipient fields of the message, but
might not cover any of the content. Under this profile, domains that
appear in the explicit delegation list (or are otherwise inferred
from the recipient header fields) are permitted to alter and re-send
the content.
Delegated domains SHOULD sign the message. However, receivers MAY
accept a Secondary signature for messages lacking a delegated
signature if the receiver can otherwise determine that the message
was handled through a delegated domain.
Original signers need to tailor the secondary signature to best
survive transit through the designated Mediators. Settling on a
common signing profile for these delegation "tokens" is likely to
change with experience.
A reasonable example signature profile could cover the following
header fields:
o From (required by DKIM)
o To and Cc (contain Receiver addresses)
o Message-Id (binds the signature to a specific message)
o Date (binds the signature to a specific date and time)
Kucherawy & Crocker Expires December 9, 2014 [Page 6]
Internet-Draft DKIM-Delegate June 2014
o DKIM-Delegate (signals to participating receivers that an
ephemeral delegation of signing authority is in effect)
Subject, though normally covered by signatures as per Section 5.4 of
[RFC6376], can be omitted for a Secondary signature if the original
signer anticipates legitimate alteration of it by a Mediator. See
also Section 5.1.
The Secondary signature might cover the message content, but allow
for legitimate Mediator modifications by including an "l=" tag in the
signature. This would require the Mediator to restict its
alterations to involve appended content only. Hence the Secondary
signature can use an "l=" value reflecting the entire message as
generated by the Author, or "0" (zero) allowing a complete
reformatting of the message. Obviously the latter grants the
Mediator considerable latitude in what it will ultimately emit, while
the former is much more constrained. The original signer of the
message can choose whichever is more appropriate for its own policies
and requirements.
This use of DKIM's "l=" value assumes messages sent to the Mediator
that are not part of a multipart message structure, as described in
Multipurpose Internet Mail Extensions (MIME; see [RFC2045]). It
might not be possible to select a practical signing length for
messages in other than the basic message format.
The expiration time on the Secondary signature needs to be long
enough to permit evaluation by receivers of the re-submitted message,
yet short enough to limit the potential for unauthorized replay
attacks. A good choice is a small number of days or even hours.
5. Discussion
The use of the Primary signature ensures that if the original message
arrives unmodified, the Receiver is assured of its legitimacy as
having been generated and sent by the original signer, irrespective
of what Mediator handled it.
Mediators, such as mailing list software, commonly make adjustments
to a message prior to re-submitting it for transfer to final
recipients. Adjustments often include prepending list-identifying
material to the Subject field, or appending URIs and such to the
message body referring Receivers to further information about the
list itself. This will almost always invalidate the Primary
signature, so downstream receivers cannot be sure (via DKIM, at
least) where the message originated.
Kucherawy & Crocker Expires December 9, 2014 [Page 7]
Internet-Draft DKIM-Delegate June 2014
5.1. Detecting Header Changes
During the development of DKIM, consideration was given to the notion
of using the "z=" tag (if present) to identify changes to the header
made in transit that render a signature invalid. Ultimately it was
decided that a signature should be considered invalid even if
analysis of the content of "z=" could be used to confirm that the
change made in transit was innocuous. The content of "z=" was meant
to be used only as a debugging tool by humans.
Under this use, if the Subject header field was included in the
header hash, it may be useful to use "z=" (if present) to detect
changes made to the Subject field, if any. If those changes appear
to be trivial, such as the insertion of a prefix string at the front
of the header field's original value, the Primary and/or Secondary
signature could be re-attempted with the original Subject field
value. If the re-attempt succeeds, the verifier could decide that
this profile's requirements have been satisfied.
6. Security Considerations
Use of this header field (and DKIM as described here) amounts to an
ephemeral granting of the ability for the first Receivers (the
Mediators named in the To and Cc fields) to generate content that the
ultimate Receivers will consider valid on behalf of the Author. A
compromised Mediator can thus replace the original content in its
entirety while still satisfying this profile.
Section 8.2 [RFC6376] discusses the risks of using "l=" tags when
generating signatures. The "l=" tag and its implications were
discussed at length during the development of DKIM, and its use today
is not popular because it opens up the possibility of replay-type
exploits where legitimate, signed messages are co-opted, modified,
and then sent as spam.
Use of "l=" here is advocated only for the specific use cases this
document seeks to address, namely survivability of Originator
signatures through modifying Mediators such as lists. It is believed
that the exposure thus created is tolerable, in particular because a
Mediator signature without "l=" is required for this profile to be
satisfied, and the exposure created by use of "l=" in the Secondary
signature is constrained by a short signature expiration time.
7. IANA Considerations
IANA is requested to make the following new entry in the Permanent
Message Header Field Names registry, per [RFC3864]:
Kucherawy & Crocker Expires December 9, 2014 [Page 8]
Internet-Draft DKIM-Delegate June 2014
Header field name: DKIM-Delegate
Applicable protocol: mail ([RFC5322])
Status: Experimental
Author/Change controller: IETF
Specification document(s): [this document]
Related information:
Requesting review of any proposed changes and additions to
this field is recommended.
8. References
8.1. Normative References
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul,
"Registration Procedures for Message
Header Fields", BCP 90, RFC 3864,
September 2004.
[RFC6376] Crocker, D., Hansen, T., and M.
Kucherawy, "DomainKeys Identified Mail
(DKIM) Signatures", STD 76, RFC 6376,
September 2011.
8.2. Informative References
[I-D.KUCHERAWY-DMARC-BASE] Kucherawy, M., Ed. and E. Zwicky, Ed.,
"Domain-based Message Authentication,
Reporting and Conformance (DMARC)",
I-D draft-kucherawy-dmarc-base.
[RFC2045] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[RFC5598] Crocker, D., "Internet Mail
Architecture", RFC 5598, July 2009.
[RFC5617] Allman, E., Fenton, J., Delany, M., and
J. Levine, "DomainKeys Identified Mail
(DKIM) Author Domain Signing Practices
(ADSP)", RFC 5617, August 2009.
[RFC6377] Kucherawy, M., "DomainKeys Identified
Mail (DKIM) and Mailing Lists", BCP 167,
RFC 6377, September 2011.
[RFC6541] Kucherawy, M., "DomainKeys Identified
Kucherawy & Crocker Expires December 9, 2014 [Page 9]
Internet-Draft DKIM-Delegate June 2014
Mail (DKIM) Authorized Third-Party
Signatures", RFC 6541, February 2012.
Appendix A. Example
[To Be Completed]
Appendix B. Acknowledgments
The authors wish to acknowledge Steve Atkins, Barry Leiba, (other
names) for their comments during the development of this document.
Authors' Addresses
Murray S. Kucherawy
EMail: superuser@gmail.com
D. Crocker
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale 94086
USA
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net
Kucherawy & Crocker Expires December 9, 2014 [Page 10]