draft-ietf-dkim-ssp-requirements-01.txt   draft-ietf-dkim-ssp-requirements-02.txt 
DKIM Working Group M. Thomas DKIM Working Group M. Thomas
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational September 15, 2006 Intended status: Informational September 2006
Expires: March 19, 2007 Expires: March 5, 2007
Requirements for a DKIM Signing Practices Protocol Requirements for a DKIM Signing Practices Protocol
draft-ietf-dkim-ssp-requirements-01 draft-ietf-dkim-ssp-requirements-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 19, 2007. This Internet-Draft will expire on March 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
DomainKeys Identified Mail [DKIM] [I-D.ietf-dkim-base] provides a DomainKeys Identified Mail [DKIM] [I-D.ietf-dkim-base] provides a
cryptographic mechanism for domains to assert responsibility for the cryptographic mechanism for domains to assert responsibility for the
messages they sign. A related mechanism would allow an administrator messages they handle. A related mechanism would allow an
to publish various statements about their email accountability administrator to publish various statements about their DKIM signing
practices. This draft defines the requirement for this additional practices. This draft defines the requirement for this mechanism.
mechanism.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Use Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 7 4. SSP Problem Scenarios . . . . . . . . . . . . . . . . . . . . 8
4.1. Scenario 1: Bigbank.example.com . . . . . . . . . . . . . 7 4.1. Problem Scenario 1: All Mail Signed with DKIM . . . . . . 8
4.2. Scenario 2: DKIM Signing Complete State . . . . . . . . . 8 4.2. Problem Scenario 2: Illegitimate Domain Name Use . . . . . 9
4.3. Scenario 3: Outsourced First Party Signing . . . . . . . . 8 4.3. Problem Scenario 3: Domain Sends No Mail . . . . . . . . . 10
4.4. Scenario 4: Resent Original Mail . . . . . . . . . . . . . 9
4.5. Scenario 5: Incremental Deployment of Signing . . . . . . 9
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. SSP Deployment Scenarios . . . . . . . . . . . . . . . . . . . 11
5.1. Discovery Requirements . . . . . . . . . . . . . . . . . . 11 5.1. Deployment Scenario 1: Outsourced Signing . . . . . . . . 11
5.2. Transport requirements . . . . . . . . . . . . . . . . . . 11 5.2. Deployment Scenario 2: Determinism in Lookup Mechanism . . 11
5.3. Practice and Expectation Requirements . . . . . . . . . . 12 5.3. Deployment Scenario 3: Resent Original Mail . . . . . . . 11
5.3.1. Negative Commentary . . . . . . . . . . . . . . . . . 12 5.4. Deployment Scenario 4: Incremental Deployment of
5.4. Extensibility and Forward Compatibilty Requirements . . . 15 Signing . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Deployment Scenario 5: Transport Scenarios . . . . . . . . 12
5.6. Deployment Scenario 6: Human Legibility of Practices . . . 13
5.7. Deployment Scenario 7: Cryptographic Downgrade Attacks . . 13
5.8. Deployment Scenario 8: Extensibility . . . . . . . . . . . 13
5.9. Deployment Scenario 9: Security . . . . . . . . . . . . . 13
6. Security Requirements . . . . . . . . . . . . . . . . . . . . 16 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Discovery Requirements . . . . . . . . . . . . . . . . . . 15
6.2. Transport requirements . . . . . . . . . . . . . . . . . . 16
6.3. Practice and Expectation Requirements . . . . . . . . . . 16
6.4. Extensibility and Forward Compatibility Requirements . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Security Requirements . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Preface 1. Preface
The purpose of this draft is get out into the open a range of issues The purpose of this draft is get out into the open a range of issues
related to the perceived need for a signing practices information related to the perceived need for a signing practices information
service primarily focused on DKIM. This document is intended to service primarily focused on DKIM. This document is intended to
document well-agreed upon problems and requirements, in addition to document well-agreed upon problems and requirements, in addition to
less well-agreed upon requirements in an attempt to capture the issue less well-agreed upon requirements in an attempt to capture the issue
as well as generalize the requirement as much as possible. These as well as generalize the requirement as much as possible. These
latter requirements will be noted as "[PROVISIONAL]" to indicate that latter requirements will be noted as "[PROVISIONAL]" to indicate that
skipping to change at page 6, line 27 skipping to change at page 7, line 27
a signing practices protocol. The most pressing case seems to be the a signing practices protocol. The most pressing case seems to be the
bid down attack inherent with almost all systems that allow optional bid down attack inherent with almost all systems that allow optional
authentication: how does a receiver know whether or not it should authentication: how does a receiver know whether or not it should
expect a message to contain authentication information? For email expect a message to contain authentication information? For email
this is an especially difficult problem since there is generally no a this is an especially difficult problem since there is generally no a
priori knowledge of a sending domain's practices. If a protocol priori knowledge of a sending domain's practices. If a protocol
could be developed for a domain to publish its DKIM signing could be developed for a domain to publish its DKIM signing
practices, a message verifier could take that into account when it practices, a message verifier could take that into account when it
receives a unsigned piece of email. receives a unsigned piece of email.
This draft is organized into two main sections: a Usage Scenario This draft is organized into two main sections: a Problem and
section which attempts to describe some common usage scenarios that Deployment Scenario section which describes the problems that The
DKIM is likely to be deployed in and the problems that are not solved Protocol is intended to address as well as the deployment issues
by DKIM alone. The second is the Requirements that arise because of surrounding the base problems. The second section is the
those usage scenarios, in addition to more basic protocol Requirements that arise because of those scenarios.
requirements.
4. Use Scenarios 4. SSP Problem Scenarios
The email world is a diverse world with many deployment scenarios. The email world is a diverse place with many deployment scenarios.
This section tries to outline some usage scenarios that it is This section tries to outline some usage scenarios that it is
expected that DKIM signing/verifying will take place in, and how a expected that DKIM signing/verifying will take place in, and how a
new protocol might be helpful to clarify the relevance of DKIM signed new protocol might be helpful to clarify the relevance of DKIM signed
mail. mail.
4.1. Scenario 1: Bigbank.example.com 4.1. Problem Scenario 1: All Mail Signed with DKIM
After auditing their outgoing mail and deploying DKIM signing for all
of their legitimate outgoing mail, a domain could be said to be DKIM
signing complete. That is, the domain has to the best of its ability
insured that all mail legitimately purporting to have come from that
domain contains a valid DKIM signature.
A receiver in the general case doesn't know what the practices are
for a given domain, or what their expectations are for unsigned mail.
Thus the receiver is at a disadvantage in that it does not know if it
should expect mail to be signed from a given domain or not. This
knowledge gap leads to a trivially exploitable bid-down attack where
the attacker merely sends unsigned mail; since the receiver doesn't
know the practices of the signing domain, it cannot treat the message
any more harshly for lack of a valid signature.
An information service which allowed a receiver to query for the
practices and expectations of the sending domain when no valid
signature is found could be useful in closing this gap. A receiver
could use this information to treat such questionable mail with
varying degrees of prejudice.
Note that for the foreseeable future, DKIM signature breakage for
unrestricted use patterns (eg where users are members of mailing
lists, etc) will likely suffer occasional non-malicious signature
failure in transit. While probably not a large percentage of total
traffic, the kind (quality) of breakage may be a significant concern
for those usage patterns. This scenario defines where the sender
cannot set any expectation as to whether an individual message will
arrive intact.
Even without that expectation, a receiver may be able to take
advantage of the knowledge that the domain's practice is to sign all
mail and bias filters against unsigned or damaged in transit mail.
This information should not be expected to be used in a binary yes/no
fashion, but instead as a data point among others in a filtering
system.
1. Mail with a [RFC2822].From A purportedly sends to B with a
missing or broken DKIM signature from A
2. B would like to know whether that is an expected state of
affairs.
3. A provides information that it signs all outgoing mail, but
places no expectation on whether it will arrive with an intact
signature.
4. B could use this information to bias its filters such that it
looks somewhat more suspicious.
4.2. Problem Scenario 2: Illegitimate Domain Name Use
There seems to be a class of mail -- mostly transactional mail from There seems to be a class of mail -- mostly transactional mail from
high value domains -- that are the target of phishing attacks. In high value domains -- that are the target of phishing attacks. In
particular, the phishing scams forge the [RFC2822].From address in particular, many phishing scams forge the [RFC2822].From address in
addition to spoofing much of the content to trick unsuspecting users addition to spoofing much of the content to trick unsuspecting users
into revealing sensitive information. Domain holders sending this into revealing sensitive information. Domain holders sending this
kind of mail would like the ability to give better guarantees that kind of mail would like the ability to give an enhanced guarantee
mail sent in their name is with the consent of the domain holder. that mail sent in their name should always arrive with the provable
The first step is, of course, to use DKIM-base to sign all of the consent of the domain holder.
outgoing mail so that a receiver can make a determination that the
mail is from the domain holder in question.
The problem with this scenario is that a receiver in the general case From a receiver's standpoint, knowing that a domain not only signs
doesn't know what the practices are for a given domain, or what their all of its mail, but also expects that legitimate mail from the
expectations are for unsigned mail. An information service which domain will be received with a valid signature is quite interesting.
allowed a receiver to query for those practices and expectations This assertion from the signing domain is quite a bit stronger than
could be useful to close the gap where an attacker merely sends the assertion in Problem Scenario 1; even though a signer can never
unsigned mail to exploit a bid down attack. It is assumed that know the true path mail will take before delivery, the implication is
receivers would use this information to treat such questionable mail that if the message is lacking a valid signature the message is
with prejudice. either malicious or is the responsibility of the signing domain to
avoid whatever broke the signature.
Note that for the foreseeable future, DKIM signature breakage for [Informative Note: in terms of a receiving filter, one may choose
unrestricted use patterns (ie with users and especially where users to treat scenario 2 much more harshly than scenario 1; where
are members of mailing lists) will likely suffer occasional damage in scenario 1 looks odd, scenario 2 looks like something is very
transit. While probably not a large percentage of total traffic, the wrong]
kind (quality) of breakage may be significant for certain usage
patterns. As such, this scenario defines a more limited situation
where the risk of a legitimate piece of mail being mislabeled as
unsigned outweights the risk of illegitimate mail being delivered in
the eyes of the sender.
1. Mail with a [RFC2822].From A purportedly sends to B with a 1. Mail with a [RFC2822].From A purportedly sends to B with a
missing or broken DKIM signature from A missing or broken DKIM signature from A
2. B would like to know whether that is an acceptable state of 2. B would like to know whether that is an expected state of
affairs. affairs.
4.2. Scenario 2: DKIM Signing Complete State 3. A provides information that it signs all outgoing mail, but
places an expectation that it should arrive with an intact
signature, and that the receiver should be suspicious if it does
not.
After auditing their outgoing mail and deploying DKIM signing for all 4. B could use this information to bias its filters such that it
of their legitimate outgoing mail, a domain could be said to be DKIM looks much more suspicious.
signing complete. That is, the domain has to the best of its ability
insured that all mail legitimately purporting to have come from that
domain contained a valid DKIM signature. Given the likelihood of
signature damage in the current mail infrastructure as noted above, a
domain can fit the DKIM signing complete scenario without wanting to
take the risks associated with the more narrow scope of use in the
previous scenario. A receiver, on the other hand, may be able to
take advantage of the knowledge the domain's practice of signing all
mail in order to use it to bias filters against the unexpected
arrival of a piece of unsigned or damaged in transit mail.
4.3. Scenario 3: Outsourced First Party Signing 4.3. Problem Scenario 3: Domain Sends No Mail
A domain may not intend to send mail at all. In such a case, it
could be advantageous for a receiver to know the domain's intent and
would be likely to treat such mail very suspiciously. It has been
noted that a solution to Problem Scenario 2 could potentially be used
to emulate this practice. In reality, they are close but not
precisely the same semantics. That is, a piece of email purporting
to come from a domain which claims to send none is illegitimate on
its face, whereas there may be some lingering doubt with Problem
Scenario 2 given the possibility in deployments between whether one
should publish scenario 1 and 2, etc.
5. SSP Deployment Scenarios
Given the problems enumerated above for which we'd like The Protocol
to provide information to recipients, there are a number of scenarios
that are not related to the problems that are to be solved, per se,
but the actual mechanics of implementing/deploying the information
service that The Protocol would provide.
5.1. Deployment Scenario 1: Outsourced Signing
Many domains do not run their own mail infrastructure, or may Many domains do not run their own mail infrastructure, or may
outsource parts of it to third parties. It is desirable for a domain outsource parts of it to third parties. It is desirable for a domain
holder to have the ability delegate to other entities the ability to holder to have the ability delegate to other entities the ability to
sign for the domain holder with either a first party signature or the sign for the domain holder. One obvious use scenario is a domain
equivalent. One obvious use scenario is a domain holder for a small holder from a small domain that needs to have the ability for their
domain that needs to have the ability for their outgoing ISP to sign outgoing ISP to sign all of their mail on behalf of the domain
all of their mail on behalf of the domain holder. Other use holder. Other use scenarios include outsourced bulk mail for
scenarios include outsourced bulk mail for marketing campaigns, as marketing campaigns, as well as outsourcing various business
well as outsourcing various business functions such as insurance functions such as insurance benefits, etc.
benefits, etc.
That said, DKIM uses DNS to store selectors. Thus there is always 5.2. Deployment Scenario 2: Determinism in Lookup Mechanism
the ability for a domain holder to delegate all or parts of the
_domainkey subdomain to a third party of the domain holder's
choosing. That is, the domain holder may be able to set a NS record
for _domainkey.example.com to, say, an email provider who manages
that namespace. There is also the ability for the domain holder to
partition its namespace into subdomains to further constrain how
third parties. For example, a domain holder could delegate only
_domainkey.benefits.example.com to a third party to constrain the
third party to only be able to produce valid signatures in the
benefits.example.com subdomain.
There have been concerns expressed about how well this would scale The Protocol's client will generally be deployed on incoming mail
when the third party is, say, a large ISP that signs for thousands of streams to provide the information as proposed in the problem
domains. There has been concern about how well this would work for scenarios. As such, it is envisioned that the RFC2822.From address
multiple delegations. Another concern is that not all DNS providers would be used as a basis for the lookup. In particular, the domain
give the ability to specify delegations. Lastly, using NS part of the address would be consulted in some manner to fetch the
delegations requires that the signer actively cooperate with the published information. There is a fairly trivial attack against a
domain for whom it is signing. That is, it requires that the signer naive use of this algorithm which is called the subdomain attack:
actively manage the _domainkey delegation for the domain holder. A that is, a domain needs to not only publish a policy for a given DNS
domain holder would not, for example, be able to make a statement label it controls, but it also may need to protect all subdomains of
that ISP.com signing on its behalf was acceptable without ISP.com's that label as well. If this characteristic is not met, an attacker
cooperation. This by extension also applies to other third parties would need only create a possibly fictitious subdomain which was not
that a domain might like to effectively "whitelist" such as mailing covered by The Protocol's information service
lists that re-sign mail that the domain holder holds in esteem.
4.4. Scenario 4: Resent Original Mail In widening the scope to have the possibility of all subdomains
inherit the parent practice, a number of algorithms could be employed
-- all seemingly with their own set of engineering tradeoffs. A
common theme in the production of this draft was that the number of
lookups, on average should be small, and that the discovery process
should always be bound to some small finite number of queries.
5.3. Deployment Scenario 3: Resent Original Mail
Resent mail is a common occurrence in many scenarios in the email Resent mail is a common occurrence in many scenarios in the email
world of today. For example, Alice sends a DKIM signed message with world of today. For example, Alice sends a DKIM signed message with
a published practice of signing all messages sent from Alice's domain a published practice of signing all messages to Bob's mailing list.
to Bob's mailing list in another domain. Bob, being a good net Bob, being a good net citizen, wants to be able to take his part of
citizen, wants to be able to take his part of the responsibility of the responsibility of the message in question, so he DKIM signs the
the message in question, so he DKIM signs the message. message, perhaps corresponding to the Sender address.
Note that this scenario is completely orthogonal to whether Alice's Note that this scenario is completely orthogonal to whether Alice's
signature survived Bob's mailing list: Bob merely wants to assert his signature survived Bob's mailing list: Bob merely wants to assert his
part in the chain of accountability for the benefit of the ultimate part in the chain of accountability for the benefit of the ultimate
receivers. It would be useful for this practice to be encouraged as receivers. It would be useful for this practice to be encouraged as
it gives a more accurate view of who handled the message, and the it gives a more accurate view of who handled the message. It also
trustworthiness of the handlers. It also has the side benefit that has the side benefit that remailers that are not friendly to DKIM
remailers that are not friendly to DKIM first party signatures (ie, first party signatures (ie, break them) can be potentially assessed
break them) can still be potentially assessed by the receiver based by the receiver based on the receiver's opinion of the signing
on the receiver's opinion of the signing domains that actually domains that actually survived.
survived.
4.5. Scenario 5: Incremental Deployment of Signing 5.4. Deployment Scenario 4: Incremental Deployment of Signing
As a practical matter, it may be difficult for a domain to roll out As a practical matter, it may be difficult for a domain to roll out
DKIM signing such that they can publish the DKIM Signing Complete DKIM signing such that they can publish the DKIM Signing Complete
practice for its given the complexities of the user population, practice given the complexities of the user population, outsourced
outsourced vendors sending on its behalf, etc. This leaves open an vendors sending on its behalf, etc. This leaves open an exploit that
exploit that high-value mail must be classified to the least common high-value mail such as in Problem Scenario 2 must be classified to
denominator of the published practices. It would be desirable to the least common denominator of the published practices. It would be
allow a domain holder to publish a list of exceptions which would desirable to allow a domain holder to publish a list of exceptions
have a stronger practices statement. which would have a stronger practices statement.
In this situation, bigbank.example.com might be ready to say that For example, bigbank.example.com might be ready to say that
statements@bigbank.example.com is always signed, but the rest of the statements@bigbank.example.com is always signed, but the rest of the
domain, say, is not. Another situation is that the practices of some domain, say, is not. Another situation is that the practices of some
address local parts in a given domain are not the same as practices address local parts in a given domain are not the same as practices
of other local parts. Using the same example of of other local parts. Using the same example of
statements@bigbank.example.com being a transactional kind of email statements@bigbank.example.com being a transactional kind of email
which would like to publish very strong practices, mixed in with the which would like to publish very strong practices, mixed in with the
rest of the user population local parts which may go through mailing rest of the user population local parts which may go through mailing
lists, etc, for which a less strong statement is appropriate. It lists, etc, for which a less strong statement is appropriate.
should be said that DKIM, through the use of subdomains, can already
support this kind of differentiation. That is, in order to publish a
strong practice, one only has to segregate those cases into different
subdomains. For example: *@accounts.bigbank.example.com would
publish a strong practice while *@bigbank.example.com could publish a
more permissive practice.
5. Requirements It should be said that DKIM, through the use of subdomains, can
already support this kind of differentiation. That is, in order to
publish a strong practice, one only has to segregate those cases into
different subdomains. For example: *@accounts.bigbank.example.com
would publish a strong practice while *@bigbank.example.com could
publish a more permissive practice.
5.5. Deployment Scenario 5: Transport Scenarios
Email service provides an any-any mesh of potential connections: all
that is required is the publication of an MX record and a SMTP
listener to receive mail. Thus the use of The Protocol is likely to
fall into two main scenarios, the first of which are large, well
known domains who are in constant contact with one another. In this
case caching of records is essential for performance, including the
caching of the non-existence of records (ie, negative caching).
The second main scenario is when a domain exchanges mail with a much
smaller volume domain. This scenario can be both perfectly normal as
with the case of vanity domains, and sadly a vector for those sending
mail for anti-social reasons. In this case we'd like the burden to
The Protocol querier to be low, since many of the lookups will not
provide a useful answer. Likewise, it would be advantageous to have
upstream caching here as well so that, say, a mailing list exploder
on a small domain does not result in an explosion of queries back at
the root server for the small domain.
5.6. Deployment Scenario 6: Human Legibility of Practices
While The Protocol records are likely to be primarily consumed by an
automaton, for the foreseeable future they are also likely to be
inspected by hand. It would be nice to have the practices stated in
a fashion which is also intuitive to the human inspectors.
[Author's $.02: it's been amply demonstrated that simple human
readable labels are often misconstrued. Opaque symbols do have
the advantage that you need to consult the definition to determine
its meaning rather than just intuiting what it "ought" to mean.
/mat]
5.7. Deployment Scenario 7: Cryptographic Downgrade Attacks
There is a downgrade attack possible where a DKIM signature is hashed
with a previously acceptable but now insecure hash algorithm. This
could allow attackers to send their chosen text which is apparently
signed by the targeted domain. It would be advantageous for a domain
to publish what the allowable signing/hashing algorithms are to
prevent this downgrade attack.
5.8. Deployment Scenario 8: Extensibility
While this document pertains only to requirements surrounding DKIM
signing practices, it would be beneficial for the protocol to be able
to extend to other protocols.
5.9. Deployment Scenario 9: Security
The protocol must be able to withstand life in a hostile open
internet environment. These include DoS attacks, and especially DoS
attacks that leverage themselves through amplification inherent in
the protocol. In addition, while a useful protocol may be built
without strong source authentication provided by the information
service, a path to strong source authentication should be provided by
the protocol, or underlying protocols.
6. Requirements
This section defines the requirements for The Protocol. As with most This section defines the requirements for The Protocol. As with most
requirements drafts, these requirements define the MINIMUM requirements drafts, these requirements define the MINIMUM
requirements that a candidate protocol must provide. It should also requirements that a candidate protocol must provide. It should also
be noted that The Protocol must fulfill all of the requirements. be noted that The Protocol must fulfill all of the requirements.
[Informative Note: it's not clear to the author that all of the [Informative Note: it's not clear to the author that all of the
provisional requirements can fulfill the harder requirements. If provisional requirements can fulfill the harder requirements. If
this is determined to be true, the provisional requirement should this is determined to be true, the provisional requirement should
either be dropped or the harder requirements revised] either be dropped or the harder requirements revised]
5.1. Discovery Requirements 6.1. Discovery Requirements
1. Discovery mechanism MUST be rooted in DNS. Receivers need a means of obtaining information about a sender's DKIM
practices. This requires a means of discovering where the
information is and what it contains.
2. Discovery mechanism MUST converge in a deterministic number of 1. The author is the first-party sender of a message, as specified
in the [rfc2822].From field. The Protocol's information is
associated with the author's domain name and is published
subordinate to that domain name.
2. In order to limit the cost of its use, any query service
supplying The Protocol's information must provide a definitive
responsive within a small, deterministic number of query
exchanges. exchanges.
[Informative Note: this, for all intents and purposes is a [Informative Note: this, for all intents and purposes is a
prohibition on anything that might produce loops; also though prohibition on anything that might produce loops or result in
"deterministic" doesn't specify how many exchanges, the extended delays and overhead; also though "deterministic"
expectation is "few".] doesn't specify how many exchanges, the expectation is "few".]
3. Discovery mechanism MUST NOT overload semantics of existing DNS [Refs: Deployment Scenario 2]
resource records where name space collisions are plausible. For
the purposes of this requirement, neither an underscore prefixed
namespace nor a new resource record type are considered
plausible.
5.2. Transport requirements 3. The Protocol's publishing mechanism MUST be defined to produce
unambiguous semantics, particularly with respect to other
information that might share the publication mechanism.
[Informative note: An example of ambiguity is sharing resource
record types within a common DNS leaf. Hence, uniquely
defined leaf names or uniquely defined resource record types
will ensure unambiguous reference.]
[Refs: Deployment Scenario 2]
6.2. Transport requirements
1. Widespread deployment of the transport layer would be highly 1. Widespread deployment of the transport layer would be highly
desirable, especially if riding on top of a true transport layer desirable, especially if riding on top of a true transport layer
(eg, TCP, UDP). (eg, TCP, UDP).
[Refs: Deployment Scenario 5, 8]
2. A low-cost query/response in terms of latency time and the number 2. A low-cost query/response in terms of latency time and the number
of packets involved is highly desirable. of packets involved is highly desirable.
[Refs: Deployment Scenario 5]
3. If the infrastructure doesn't provide caching (ala DNS), the 3. If the infrastructure doesn't provide caching (ala DNS), the
records retrieved will need time-to-live values to allow querying records retrieved will need time-to-live values to allow querying
verifiers to maintain their own caches. Existing caching verifiers to maintain their own caches. Existing caching
infrastructure is, however, highly desirable. infrastructure is, however, highly desirable.
[Refs: Deployment Scenario 5]
4. Multiple geographically and topologically diverse servers must be 4. Multiple geographically and topologically diverse servers must be
supported for high availability supported for high availability
5.3. Practice and Expectation Requirements [Refs: Deployment Scenario 5, 8]
6.3. Practice and Expectation Requirements
In this section, a Practice is defined as a true statement according In this section, a Practice is defined as a true statement according
to the [RFC2822].From domain holder of its intended externally to the [RFC2822].From domain holder of its intended externally
viewable behavior. An Expectation combines with a Practice to convey visible behavior. An Expectation combines with a Practice to convey
what the domain holder considers the likely outcome of the what the domain holder considers the likely outcome of the
survivability of the Practice at a receiver. For example, a Practice survivability of the Practice for a receiver. For example, a
that X is true when it leaves the domain, and an Expectation that it Practice that X is true when it leaves the domain, and an Expectation
will|will-not|may|may-not remain true for some/all receivers. that it will|will-not|may|may-not remain true for some/all receivers.
1. The Protocol MUST be able to make Practices and Expectation 1. The Protocol MUST be able to make Practices and Expectation
assertions about the [RFC2822].From address in the context of assertions about the [RFC2822].From address in the context of
DKIM. The Protocol will not make assertions about other DKIM. The Protocol will not make assertions about other
addresses for DKIM at this time. addresses for DKIM at this time.
2. The Protocol MUST be able to publish a Practice that the domain [Refs: Problem Scenario 1,2]
doesn't send mail.
3. The Protocol MUST be able to publish a Practice that the
domain's signing behavior is "DKIM Signing Complete"
4. The Protocol MUST be able to publish an Expectation that a
verifiable First Party DKIM Signature should be expected on
receipt of a message.
[Informative Note: the DKIM Signing Complete Practice seems
to be a pre-requisite for this Expectation]
5. [PROVISIONAL] A domain MUST be able to delegate responsibility
for signing its messages to a non-related domain in such a way
that it does not require active participation by the non-related
domain. That is, the published information MUST have a way to
specify the domains that are allowed to sign on its behalf.
5.3.1. Negative Commentary
1. Scaling Concerns for DNS: the addition of third party 2. [PROVISIONAL] The Protocol MUST be able to publish a Practice
signers begs the question of how that information is stored which is indicative that domain doesn't send mail.
in the DNS if that is the repository (which seems pretty
likely). The naive approach of just encoding them into one
resource record could quite plausiblely exceed the maximum
DNS UDP MTU which would be highly undesirable. Other
approaches have been suggested, but they seemingly trade off
complexity, number of lookups, non-deterministic completion,
etc.
2. Alternate mechanism to NS delegation, and threats not well [Refs: Problem Scenario 3]
understood: the mechanism for delegating zones within DNS is 3. If the Discovery process would be shortened by publication of a
a very well understood problem which well understood "null" practice, the protocol SHOULD provide a mechanism to
threats. The threats involved with another form of publish such a practice.
indirection are far less clear, though undoubtably present.
There is a great deal of concern that (re)discovering those
threats, deciding whether they are valid, whether they need
to mitigated, etc, etc are a worthwhile exercise given that
this provides minimal functionality over what currently
exists with DKIM base.
3. The seems to be a strong consensus for most of requirements, [INFORMATIVE NOTE: there seems to be widespread consensus
and quite a bit less for this, is there harm if we don't do that a "neutral" or "I sign some mail" practice is useless to
this now? That is, can it extended later if needed based on receivers. However, a null practice may help to cut short
much more experience? the policy lookup mechanism if it's published, and if that's
the case it seems worthwhile. Also, a null policy may have
some forensic utility, such as gaging the number of domains
considering/using DKIM for example.]
4. Concerns about conflation of responsibility and/or [Refs: Deployment Scenario 2]
reputation: there are concerns of adding to the confusion
about who is taking responsibility for what. Is it the d=
domain in the DKIM-signature? Is it the domain in the From:
address? Is it both? Is it neither? Keeping this simple
by using the NS delegation mechanism would not raise these
interesting, if not thorny questions.
5. It's not clear that this requirement actually delivers on 4. The Protocol MUST be able to publish a Practice that the
the less complexity aspect of its billing: one of the domain's signing behavior is "DKIM Signing Complete"
attractions of this requirement is that there would be
little or no interaction required between the first party
and the designated third party signer. Given the security
issues with this approach, it is not clear that the
interaction required between the first and third parties are
any less onerous.
6. Security Threat with DKIM base, a first party signer can [Refs: Problem Scenario 1]
always clarify which address it is signing on behalf of by
using the i= tag. That is, when there's ambiguity between,
say, From: and Sender: the signer has the ability to clarify
which address the signature was on behalf of if it so
desires. For a third party signature, there is no clarity
since the signature by definition has no relationship to the
origination addresses.
A legitimate flow follows: 5. The Protocol MUST be able to publish an Expectation that a
verifiable First Party DKIM Signature should be expected on
receipt of a message.
- An ISP signs for both a.com and mailinglist.com [Refs: Problem Scenario 2]
- mailinglist.com sends a piece of mail From: 6. Practices and Expectations MUST be presented in the Protocol
president@a.com, Sender: list@mailinglist.com syntax using as intuitive a descriptor as possible. For
- ISP signs the message with d=ISP.com example, p=? would be better represented as p=unknown.
- The receiver at this point has no idea who ISP.com was [Refs: Deployment Scenario 6]
signing on behalf of because they are both
legitimately signed by ISP.com
The attack is essentially identical: it only requires that 7. The Protocol MUST NOT invent a different means of allowing
mailinglist.com spoof the From: address to whatever other affiliated parties to sign on a domain's behalf. Because DKIM
customer of ISP.com. That is, mailinglist.com can be any uses DNS to store selectors, there is always the ability for a
example.com with bad intentions. Worse, is that the ISP domain holder to delegate all or parts of the _domainkey
will ordinarily have no clue as to whether its customers are subdomain to an affiliated party of the domain holder's
running mailing lists or not, so it would not have the choosing. That is, the domain holder may be able to set a NS
ability "legitimate" From: spoofing (ie, a real mailing record for _domainkey.example.com to, say, an email provider who
list) from illegitimate spoofing. manages that namespace. There is also the ability for the
domain holder to partition its namespace into subdomains to
further constrain how third parties. For example, a domain
holder could delegate only _domainkey.benefits.example.com to a
third party to constrain the third party to only be able to
produce valid signatures in the benefits.example.com subdomain.
Last, a domain holder can even use CNAME's to delegate
individual leaf nodes.
6. [PROVISIONAL] The protocol MUST have the ability to provide 8. [PROVISIONAL] The protocol MUST have the ability to provide
practices and expecations keyed off of the local part of the practices and expectations keyed off of the local part of the
[RFC2822].From address. As with all provisional requirements, [RFC2822].From address. As with all provisional requirements,
this requirement must not be in conflict with other this requirement must not be in conflict with other
requirements, including DNS considerations, etc. requirements, including DNS considerations, etc.
[INFORMATIVE NOTE: this requirement seems to have rather weak [INFORMATIVE NOTE: this requirement seems to have rather weak
support. It's mainly been added so that it can be issue- support. It's mainly been added so that it can be issue-
tracked. /mat] tracked. /mat]
7. Practices and Expectations MUST be presented as an information [Refs: Deployment Scenario 4]
service from the sender to be consumed as an added factor to the
receiver's local policy. In particular, a Practice or
Expectation MUST NOT mandate any disposition stance on the
receiver.
8. If the Discovery process would be shortened by publication of a 9. Practices and Expectations MUST be presented as an information
"null" practice, the protocol SHOULD provide a mechanism to service from the signing domain to be consumed as an added
publish such a practice. factor to the receiver's local policy. In particular, a
Practice or Expectation MUST NOT mandate any disposition stance
on the receiver.
[INFORMATIVE NOTE: there seems to be widespread consensus [Refs: Problem Scenario 1, 2, 3]
that a "neutral" or "I sign some mail" practice is useless to
receivers. However, a null practice may help to cut short
the policy lookup mechanism if it's published, and if that
the case it seems worthwhile. Also, a null policy may have
some forensic utility, such as gaging the number of domains
considering/using DKIM for example.]
9. There is no requirement that The Protocol publish a Practices of 10. There is no requirement that The Protocol publish a Practices of
any/all third parties that MUST NOT sign on the domain holder's any/all third parties that MUST NOT sign on the domain holder's
behalf. This should be considered out of scope. behalf. This should be considered out of scope.
[INFORMATIVE NOTE: this is essentially saying that the [INFORMATIVE NOTE: this is essentially saying that the
protocol doesn't have to concern itself with being a protocol doesn't have to concern itself with being a
blacklist repository.] blacklist repository.]
10. The Protocol MUST NOT be required to be invoked if a valid first [Refs: Problem Scenario 1-2]
11. The Protocol MUST NOT be required to be invoked if a valid first
party signature is found. party signature is found.
11. [PROVISIONAL] A domain holder MUST be able to publish a Practice [Refs: Deployment Scenario 2]
12. [PROVISIONAL] A domain holder MUST be able to publish a Practice
which enumerates the acceptable cryptographic algorithms for which enumerates the acceptable cryptographic algorithms for
signatures purportedly from that domain. signatures purportedly from that domain.
[INFORMATIVE NOTE: this is to counter a bid down attack; some [Refs: Deployment Scenario 7]
comments indicated that this need only be done if the
algorithm was considered suspect by the receiver; I'm not
sure that I've captured that nuance correctly]
12. Given the considerations in scenario 4, the protocol MUST NOT 13. The protocol MUST NOT provide a mechanism which impugns the
provide a mechanism which impugns the mere existence of third existence of non-first party signatures in a message. A
party signatures in a message. A corrolary of this requirement corollary of this requirement is that the protocol MUST NOT link
is that the protocol MUST NOT in any way tie practices of first practices of first party signers with the practices of third
party signers with third party signers. party signers.
[INFORMATIVE NOTE: the main thrust of this requirement is [INFORMATIVE NOTE: the main thrust of this requirement is
that practices should only be published for that which the that practices should only be published for that which the
publisher has control, and should not restate what is publisher has control, and should not meddle in what is
ultimately the local policy of the receiver.] ultimately the local policy of the receiver.]
5.4. Extensibility and Forward Compatibilty Requirements [Refs: Deployment Scenario 3]
1. The Protocol MUST NOT extend to any other than DKIM for email at 6.4. Extensibility and Forward Compatibility Requirements
this time.
1. The Protocol MUST NOT extend to any other protocol than DKIM for
email at this time. The Protocol SHOULD be able to extend for
protocols other than DKIM.
[Refs: Deployment Scenario 8]
2. The Protocol MUST be able to add new Practices and Expectations 2. The Protocol MUST be able to add new Practices and Expectations
within the existing discovery/transport/practices in a backward within the existing discovery/transport/practices in a backward
compatible fashion. compatible fashion.
3. [PROVISIONAL] The Protocol MUST be able to extend for new [Refs: Deployment Scenario 8]
protocols signed by DKIM
4. [PROVISIONAL] The Protocol MUST be able to extend for protocols
other than DKIM
6. Security Requirements 7. Security Requirements
1. Minimize DoS potential: The Protocol for a high-value domain is 1. Minimize DoS potential: The Protocol for a high-value domain is
potentially a high-value DoS target, especially since the potentially a high-value DoS target, especially since the
unavailability of The Protocol's record could make unsigned unavailability of The Protocol's record could make unsigned
messages less suspicious. messages less suspicious.
2. Amplification Attacks: The Protocol MUST NOT make highly 2. Amplification Attacks: The Protocol MUST NOT make highly
leveraged amplification or make-work attacks possible. In leveraged amplification or make-work attacks possible. In
particular any amplification must be O(1). particular any amplification must be O(1).
[Author's question: is it really O(1)? or O(n)?]
[Refs: Deployment Scenario 9]
3. Authenticity: The Protocol MUST have the ability for a domain 3. Authenticity: The Protocol MUST have the ability for a domain
holder to provide The Protocol's data such that a receiver can holder to provide The Protocol's data such that a receiver can
determine that it is authentically from the domain holder with a determine that it is authentically from the domain holder with a
large degree of certainty. The Protocol may provide means which large degree of certainty. The Protocol may provide means which
provide less certainty in trade off for ease of deployment. provide less certainty in trade off for ease of deployment.
7. IANA Considerations [Refs: Deployment Scenario 9]
8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
8. Security Considerations 9. Security Considerations
This draft defines requirements for a new protocol and the security This draft defines requirements for a new protocol and the security
related requirements are defined above. There is an expectation that related requirements are defined above. There is an expectation that
The Protocol will not always be required to have source The Protocol will not always be required to have source
authentication of the practices information which is noteworthy. authentication of the practices information which is noteworthy.
9. Acknowledgements 10. Acknowledgments
still free to good home Due to flipping in the market and raising interest rates, this home
is no longer free. Dave Crocker and Jim Fenton helped me raise the
walls on this draft and are accorded a room at the inn. The inn is
not yet full, however.
10. References 11. References
10.1. Normative References 11.1. Normative References
[I-D.ietf-dkim-base] [I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail (DKIM) Allman, E., "DomainKeys Identified Mail (DKIM)
Signatures", draft-ietf-dkim-base-04 (work in progress), Signatures", draft-ietf-dkim-base-04 (work in progress),
July 2006. July 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
10.2. Informative References 11.2. Informative References
[I-D.ietf-dkim-overview] [I-D.ietf-dkim-overview]
Hansen, T., "DomainKeys Identified Mail (DKIM) Service Hansen, T., "DomainKeys Identified Mail (DKIM) Service
Overview", draft-ietf-dkim-overview-01 (work in progress), Overview", draft-ietf-dkim-overview-01 (work in progress),
June 2006. June 2006.
[I-D.ietf-dkim-threats] [I-D.ietf-dkim-threats]
Fenton, J., "Analysis of Threats Motivating DomainKeys Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work
in progress), May 2006. in progress), May 2006.
 End of changes. 84 change blocks. 
282 lines changed or deleted 388 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/