draft-ietf-dkim-ssp-requirements-00.txt   draft-ietf-dkim-ssp-requirements-01.txt 
DKIM Working Group M. Thomas DKIM Working Group M. Thomas
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational August 10, 2006 Intended status: Informational September 15, 2006
Expires: February 11, 2007 Expires: March 19, 2007
Requirements for a DKIM Signing Practices Protocol Requirements for a DKIM Signing Practices Protocol
draft-ietf-dkim-ssp-requirements-00 draft-ietf-dkim-ssp-requirements-01
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 February 11, 2007. This Internet-Draft will expire on March 19, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
DomainKeys Identified Mail [DKIM] provides a cryptographic mechanism DomainKeys Identified Mail [DKIM] [I-D.ietf-dkim-base] provides a
for domains to assert responsibility for the messages they sign. A cryptographic mechanism for domains to assert responsibility for the
related mechanism would allow an administrator ot publish various messages they sign. A related mechanism would allow an administrator
statements about their email accountability practices. This draft to publish various statements about their email accountability
defines the requirement for this additional mechanism. practices. This draft defines the requirement for this additional
mechanism.
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].
Table of Contents Table of Contents
1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Use Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Use Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Scenario 1: Bigbank.example.com . . . . . . . . . . . . . 6 4.1. Scenario 1: Bigbank.example.com . . . . . . . . . . . . . 7
4.2. Scenario 2: DKIM Signing Complete . . . . . . . . . . . . 7 4.2. Scenario 2: DKIM Signing Complete State . . . . . . . . . 8
4.3. Scenario 3: Outsourced First Party Signing . . . . . . . . 7 4.3. Scenario 3: Outsourced First Party Signing . . . . . . . . 8
4.4. Scenario 4: Resent Original Mail . . . . . . . . . . . . . 9
4.5. Scenario 5: Incremental Deployment of Signing . . . . . . 9
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Discovery Requirements . . . . . . . . . . . . . . . . . . 9 5.1. Discovery Requirements . . . . . . . . . . . . . . . . . . 11
5.2. Transport requirements . . . . . . . . . . . . . . . . . . 9 5.2. Transport requirements . . . . . . . . . . . . . . . . . . 11
5.3. Practice and Expectation Requirements . . . . . . . . . . 10 5.3. Practice and Expectation Requirements . . . . . . . . . . 12
5.4. Extensibility and Forward Compatibilty Requirements . . . 11 5.3.1. Negative Commentary . . . . . . . . . . . . . . . . . 12
5.4. Extensibility and Forward Compatibilty Requirements . . . 15
6. Security Requirements . . . . . . . . . . . . . . . . . . . . 12 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 22
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 4, line 12 skipping to change at page 5, line 12
demonstrated, along with reasonable plausibility that they do not demonstrated, along with reasonable plausibility that they do not
contradict more well agreed upon requirements. contradict more well agreed upon requirements.
2. Definitions 2. Definitions
o Domain Holder: the entity that ultimately controls the contents of o Domain Holder: the entity that ultimately controls the contents of
the DNS subtree starting at the domain, either directly or by the DNS subtree starting at the domain, either directly or by
delegation via NS records it controls. delegation via NS records it controls.
o First Party Address: For DKIM, a first party address is defined to o First Party Address: For DKIM, a first party address is defined to
be the RFC2822.From address in the message header; a first party be the [RFC2822].From address in the message header; a first party
address is also known as a Author address address is also known as an Author address
o First Party Signature: For DKIM, a first party signature is a o First Party Signature: a first party signature is a valid
valid signature where the domain tag (d=) matches (as defined in signature where the domain tag (d= or the more specific identity
[DKIM]) the first party address i= tag) matches the first party address. "Matches" in this
context is defined in [I-D.ietf-dkim-base]
o Third Party Signature: For DKIM, a third party signature is a o Third Party Signature: a third party signature is a valid
valid signature that does not qualify as a First Party Signature. signature that does not qualify as a First Party Signature. Note
Note that a DKIM third party signature does is not required to that a DKIM third party signature does is not required to
correspond to a third party address such as Sender or Listid, etc. correspond to a third party address such as Sender or Listid, etc.
o DKIM Signer Complete: the state where the domain holder believes o DKIM Signer Complete: the state where the domain holder believes
that all legitimate mail purportedly from the domain was sent with that all legitimate mail purportedly from the domain was sent with
a valid DKIM signature. a valid DKIM signature.
o The Protocol: in this document, The Protocol is used as o The Protocol: in this document, The Protocol is used as
placeholder for a protocol that will meet the requirements set in placeholder for a protocol that will meet the requirements set in
this draft. this draft.
3. Introduction 3. Introduction
The DomainKeys Identified Mail working group is chartered to create a The DomainKeys Identified Mail working group is chartered to create a
base signing mechanism for email. This work is contained in base signing mechanism for email. This work is contained in
draft-ietf-dkim-base-04.txt. In addition there are two other [I-D.ietf-dkim-base]. In addition there are two other documents
documents draft-ietf-dkim-overview-00.txt and [I-D.ietf-dkim-overview] and [I-D.ietf-dkim-threats] which give an
draft-ietf-dkim-threats-03.txt which give an overview and a threat overview and a threat analysis of the chartered work. This draft
analysis of the chartered work. This draft reflects the requirements reflects the requirements for the last part of the chartered work to
for the last part of the chartered work to define a protocol to define a protocol to publish DKIM signing practices.
publish DKIM signing practices.
While the base signing document defines a mechanism for signing and While the base signing document defines a mechanism for signing and
verifying DKIM signatures, there has been a great deal of interest in verifying DKIM signatures, there has been a great deal of interest in
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 generally there is no a this is an especially difficult problem since there is generally no a
priori knowledge of other domains so the safe assumption is the priori knowledge of a sending domain's practices. If a protocol
lowest common denominator which is no authentication at all. Thus a could be developed for a domain to publish its DKIM signing
protocol needs to be developed which can allow a DKIM message practices, a message verifier could take that into account when it
verifier to determine the DKIM posture of the domain for messages it receives a unsigned piece of email.
receives which arrive without a valid DKIM signature.
This draft is organized into two main sections: a Usage Scenario This draft is organized into two main sections: a Usage Scenario
section which attempts to describe some common usage scenarios that section which attempts to describe some common usage scenarios that
DKIM is likely to be deployed in and the problems that are not solved DKIM is likely to be deployed in and the problems that are not solved
by DKIM alone. The second is the Requirements that arise because of by DKIM alone. The second is the Requirements that arise because of
those usage scenarios, in addition more basic protocol requirements. those usage scenarios, in addition to more basic protocol
requirements.
4. Use Scenarios 4. Use Scenarios
The email world is a diverse world with many deployment scenarios. The email world is a diverse world 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. Scenario 1: Bigbank.example.com
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, the 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 guarantee that their mail is kind of mail would like the ability to give better guarantees that
always from them. The first step is, of course, to use DKIM-base to mail sent in their name is with the consent of the domain holder.
sign all of their outgoing mail so that a receiver can make a The first step is, of course, to use DKIM-base to sign all of the
positive determination that the mail is from the domain holder in outgoing mail so that a receiver can make a determination that the
question. mail is from the domain holder in question.
The problem with this scenario is that a receiver in the general case The problem with this scenario is that a receiver in the general case
doesn't know what the practices are for a given domain, or what their doesn't know what the practices are for a given domain, or what their
expectations are for unsigned mail. An information service which expectations are for unsigned mail. An information service which
allowed a receiver to query for those practices and expectations allowed a receiver to query for those practices and expectations
could be useful to close the gap where an attacker merely sends could be useful to close the gap where an attacker merely sends
unsigned mail to exploit a bid down attack. It is assumed that unsigned mail to exploit a bid down attack. It is assumed that
receivers would use this information to treat such questionable mail receivers would use this information to treat such questionable mail
with prejudice. with prejudice.
Note that for the foreseeable future, DKIM signature breakage for Note that for the foreseeable future, DKIM signature breakage for
unrestricted use patterns (ie with users and especially where users unrestricted use patterns (ie with users and especially where users
are members of mailing lists) will likely suffer occassional damage are members of mailing lists) will likely suffer occasional damage in
in transit. While probably not a large percentage of total traffic, transit. While probably not a large percentage of total traffic, the
the kind (quality) of breakage may be significant for certain usage kind (quality) of breakage may be significant for certain usage
patterns. As such, this scenario defines a more limited situation patterns. As such, this scenario defines a more limited situation
where the risk of a legitimate piece of mail being mislabeled as where the risk of a legitimate piece of mail being mislabeled as
unsigned outweights the risk of illegitimate mail being delivered in unsigned outweights the risk of illegitimate mail being delivered in
the eyes of the sender. the eyes of the sender.
1. A purportedly sends to B with a missing or broken DKIM signature 1. Mail with a [RFC2822].From A purportedly sends to B with a
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 acceptable state of
affairs. affairs.
4.2. Scenario 2: DKIM Signing Complete 4.2. Scenario 2: DKIM Signing Complete State
After auditing their outgoing mail and deploying DKIM signing for all After auditing their outgoing mail and deploying DKIM signing for all
of their legitimate outgoing mail, a domain could be said to be DKIM 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 signing complete. That is, the domain has to the best of its ability
insured that all mail legitimately purporting to have come from that insured that all mail legitimately purporting to have come from that
domain contained a valid DKIM signature. Given the likelihood of domain contained a valid DKIM signature. Given the likelihood of
signature damage in the current mail infrastructure as noted above, a signature damage in the current mail infrastructure as noted above, a
domain can fit the DKIM signing complete scenario without wanting to domain can fit the DKIM signing complete scenario without wanting to
take the risks associated with the more narrow scope of use in the 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 previous scenario. A receiver, on the other hand, may be able to
take advantage of the knowledge the domain's practice of signing all take advantage of the knowledge the domain's practice of signing all
mail in order to use it to bias filters against the unexpected mail in order to use it to bias filters against the unexpected
arrival of a piece of unsigned or damaged in transit mail. arrival of a piece of unsigned or damaged in transit mail.
4.3. Scenario 3: Outsourced First Party Signing 4.3. Scenario 3: Outsourced First Party 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 to be able to enumerate a list of domains holder to have the ability delegate to other entities the ability to
that should be treated as equivalent to a first party signature from sign for the domain holder with either a first party signature or the
the domain holder itself. One obvious use scenario is a domain equivalent. One obvious use scenario is a domain holder for a small
holder for 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 That said, DKIM uses DNS to store selectors. Thus there is always
the ability for a domain holder to delegate all or parts of the the ability for a domain holder to delegate all or parts of the
_domainkey subdomain to a third party of the domain holder's _domainkey subdomain to a third party of the domain holder's
choosing. That is, the domain holder can always set a NS record for choosing. That is, the domain holder may be able to set a NS record
_domainkey.example.com to, say, an email provider who manages that for _domainkey.example.com to, say, an email provider who manages
namespace. There is also the ability for the domain holder to that namespace. There is also the ability for the domain holder to
partition its namespace into subdomains to further constrain how partition its namespace into subdomains to further constrain how
third parties. For example, a domain holder could delegate only third parties. For example, a domain holder could delegate only
_domainkey.benefits.example.com to a third party to further constrain _domainkey.benefits.example.com to a third party to constrain the
the third party to only be able to sign messages on behalf of the third party to only be able to produce valid signatures in the
benefits subdomain. benefits.example.com subdomain.
There have been concerns expressed about how well this would scale There have been concerns expressed about how well this would scale
when the third party is, say, a large ISP that signs for thousands of when the third party is, say, a large ISP that signs for thousands of
domains. There has been concern about how well this would work for domains. There has been concern about how well this would work for
multiple delegations. Lastly, using NS delegations requires that the multiple delegations. Another concern is that not all DNS providers
signer actively cooperate with the domain for whom it is signing. give the ability to specify delegations. Lastly, using NS
That is, it requires that the signer actively manage the _domainkey delegations requires that the signer actively cooperate with the
delegation for the domain holder. A domain holder would not, for domain for whom it is signing. That is, it requires that the signer
example, be able to make a statement that ISP.com signing on its actively manage the _domainkey delegation for the domain holder. A
behalf was acceptable without ISP.com's cooperation. This by domain holder would not, for example, be able to make a statement
extension also applies to other third parties that a domain might that ISP.com signing on its behalf was acceptable without ISP.com's
like to effectively "whitelist" such as mailing lists that re-sign cooperation. This by extension also applies to other third parties
mail that the domain holder holds in esteem. that a domain might like to effectively "whitelist" such as mailing
lists that re-sign mail that the domain holder holds in esteem.
4.4. Scenario 4: Resent Original Mail
Resent mail is a common occurrence in many scenarios in the email
world of today. For example, Alice sends a DKIM signed message with
a published practice of signing all messages sent from Alice's domain
to Bob's mailing list in another domain. Bob, being a good net
citizen, wants to be able to take his part of the responsibility of
the message in question, so he DKIM signs the message.
Note that this scenario is completely orthogonal to whether Alice's
signature survived Bob's mailing list: Bob merely wants to assert his
part in the chain of accountability for the benefit of the ultimate
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
trustworthiness of the handlers. It also has the side benefit that
remailers that are not friendly to DKIM first party signatures (ie,
break them) can still be potentially assessed by the receiver based
on the receiver's opinion of the signing domains that actually
survived.
4.5. Scenario 5: Incremental Deployment of Signing
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
practice for its given the complexities of the user population,
outsourced vendors sending on its behalf, etc. This leaves open an
exploit that high-value mail must be classified to the least common
denominator of the published practices. It would be desirable to
allow a domain holder to publish a list of exceptions which would
have a stronger practices statement.
In this situation, bigbank.example.com might be ready to say that
statements@bigbank.example.com is always signed, but the rest of the
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
of other local parts. Using the same example of
statements@bigbank.example.com being a transactional kind of email
which would like to publish very strong practices, mixed in with the
rest of the user population local parts which may go through mailing
lists, etc, for which a less strong statement is appropriate. 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. Requirements 5. 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
skipping to change at page 9, line 30 skipping to change at page 11, line 30
2. Discovery mechanism MUST converge in a deterministic number of 2. Discovery mechanism MUST converge in a deterministic number of
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; also though
"deterministic" doesn't specify how many exchanges, the "deterministic" doesn't specify how many exchanges, the
expectation is "few".] expectation is "few".]
3. Discovery mechanism MUST NOT overload semantics of existing DNS 3. Discovery mechanism MUST NOT overload semantics of existing DNS
resource records where name space collisions are possible. 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 5.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).
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.
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.
4. Multiple, geographically and topologically diverse servers must 4. Multiple geographically and topologically diverse servers must be
be supported for high availability supported for high availability
5.3. Practice and Expectation Requirements 5.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 domain holder of its intended externally viewable behavior. to the [RFC2822].From domain holder of its intended externally
An Expectation combines with a Practice to convey what the domain viewable behavior. An Expectation combines with a Practice to convey
holder considers the likely outcome of the survivability of the what the domain holder considers the likely outcome of the
Practice at a receiver. For example, a Practice that X is true when survivability of the Practice at a receiver. For example, a Practice
it leaves the domain, and an Expectation that it will|will-not|may| that X is true when it leaves the domain, and an Expectation that it
may-not remain true for some/all receivers. 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 2. The Protocol MUST be able to publish a Practice that the domain
doesn't send mail. doesn't send mail.
3. The Protocol MUST be able to publish a Practice that the 3. The Protocol MUST be able to publish a Practice that the
domain's signing behavior is "DKIM Signing Complete" domain's signing behavior is "DKIM Signing Complete"
4. The Protocol MUST be able to publish an Expectation that a 4. The Protocol MUST be able to publish an Expectation that a
skipping to change at page 10, line 39 skipping to change at page 12, line 39
[Informative Note: the DKIM Signing Complete Practice seems [Informative Note: the DKIM Signing Complete Practice seems
to be a pre-requisite for this Expectation] to be a pre-requisite for this Expectation]
5. [PROVISIONAL] A domain MUST be able to delegate responsibility 5. [PROVISIONAL] A domain MUST be able to delegate responsibility
for signing its messages to a non-related domain in such a way for signing its messages to a non-related domain in such a way
that it does not require active participation by the non-related that it does not require active participation by the non-related
domain. That is, the published information MUST have a way to domain. That is, the published information MUST have a way to
specify the domains that are allowed to sign on its behalf. specify the domains that are allowed to sign on its behalf.
6. Practices and Expectations MUST be presented as an information 5.3.1. Negative Commentary
1. Scaling Concerns for DNS: the addition of third party
signers begs the question of how that information is stored
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
understood: the mechanism for delegating zones within DNS is
a very well understood problem which well understood
threats. The threats involved with another form of
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,
and quite a bit less for this, is there harm if we don't do
this now? That is, can it extended later if needed based on
much more experience?
4. Concerns about conflation of responsibility and/or
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
the less complexity aspect of its billing: one of the
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
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:
- An ISP signs for both a.com and mailinglist.com
- mailinglist.com sends a piece of mail From:
president@a.com, Sender: list@mailinglist.com
- ISP signs the message with d=ISP.com
- The receiver at this point has no idea who ISP.com was
signing on behalf of because they are both
legitimately signed by ISP.com
The attack is essentially identical: it only requires that
mailinglist.com spoof the From: address to whatever other
customer of ISP.com. That is, mailinglist.com can be any
example.com with bad intentions. Worse, is that the ISP
will ordinarily have no clue as to whether its customers are
running mailing lists or not, so it would not have the
ability "legitimate" From: spoofing (ie, a real mailing
list) from illegitimate spoofing.
6. [PROVISIONAL] The protocol MUST have the ability to provide
practices and expecations keyed off of the local part of the
[RFC2822].From address. As with all provisional requirements,
this requirement must not be in conflict with other
requirements, including DNS considerations, etc.
[INFORMATIVE NOTE: this requirement seems to have rather weak
support. It's mainly been added so that it can be issue-
tracked. /mat]
7. Practices and Expectations MUST be presented as an information
service from the sender to be consumed as an added factor to the service from the sender to be consumed as an added factor to the
receiver's local policy. In particular a Practice or receiver's local policy. In particular, a Practice or
Expectation MUST NOT specify any particular disposition stance Expectation MUST NOT mandate any disposition stance on the
that the receiver should follow. receiver.
7. If the Discovery process would be shortened by publication of a 8. If the Discovery process would be shortened by publication of a
"null" practice, the protocol SHOULD provide a mechanism to "null" practice, the protocol SHOULD provide a mechanism to
publish such a practice. publish such a practice.
[INFORMATIVE NOTE: there seems to be widespread consensus [INFORMATIVE NOTE: there seems to be widespread consensus
that a "neutral" or "I sign some mail" practice is useless to that a "neutral" or "I sign some mail" practice is useless to
receivers. However, a null practice may help to cut short receivers. However, a null practice may help to cut short
the policy lookup mechanism if it's published, and if that the policy lookup mechanism if it's published, and if that
the case it seems worthwhile. Also, a null policy may have the case it seems worthwhile. Also, a null policy may have
some forensic utility, such as gaging the number of domains some forensic utility, such as gaging the number of domains
considering/using DKIM for example.] considering/using DKIM for example.]
8. The Protocol is not required to publish a Practice of any/all 9. There is no requirement that The Protocol publish a Practices of
unreleated third parties that MUST NOT sign on the domain any/all third parties that MUST NOT sign on the domain holder's
holder's behalf. 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.]
9. The Protocol MUST NOT be required to be invoked if a valid first 10. The Protocol MUST NOT be required to be invoked if a valid first
party signatures is found. party signature is found.
10. [PROVISIONAL] A domain holder MUST be able to publish a Practice 11. [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 [INFORMATIVE NOTE: this is to counter a bid down attack; some
comments indicated that this need only be done if the comments indicated that this need only be done if the
algorithm was considered suspect by the receiver; I'm not algorithm was considered suspect by the receiver; I'm not
sure that I've captured that nuance correctly] sure that I've captured that nuance correctly]
12. Given the considerations in scenario 4, the protocol MUST NOT
provide a mechanism which impugns the mere existence of third
party signatures in a message. A corrolary of this requirement
is that the protocol MUST NOT in any way tie practices of first
party signers with third party signers.
[INFORMATIVE NOTE: the main thrust of this requirement is
that practices should only be published for that which the
publisher has control, and should not restate what is
ultimately the local policy of the receiver.]
5.4. Extensibility and Forward Compatibilty Requirements 5.4. Extensibility and Forward Compatibilty Requirements
1. The Protocol MUST NOT extend to any other than DKIM for email at 1. The Protocol MUST NOT extend to any other than DKIM for email at
this time. this time.
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 3. [PROVISIONAL] The Protocol MUST be able to extend for new
skipping to change at page 12, line 14 skipping to change at page 16, line 14
6. Security Requirements 6. 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 order of a constant. particular any amplification must be O(1).
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 7. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
skipping to change at page 15, line 7 skipping to change at page 19, line 7
8. Security Considerations 8. 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 9. Acknowledgements
free to good home still free to good home
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail (DKIM)
Signatures", draft-ietf-dkim-base-04 (work in progress),
July 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
10.2. Informative References 10.2. Informative References
[I-D.ietf-dkim-overview]
Hansen, T., "DomainKeys Identified Mail (DKIM) Service
Overview", draft-ietf-dkim-overview-01 (work in progress),
June 2006.
[I-D.ietf-dkim-threats]
Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work
in progress), May 2006.
Author's Address Author's Address
Michael Thomas Michael Thomas
Cisco Systems Cisco Systems
606 Sanchez St 606 Sanchez St
San Francisco, California 94114 San Francisco, California 94114
USA USA
Phone: +1-408-525-5386 Phone: +1-408-525-5386
Fax: +1-408-525-5386 Fax: +1-408-525-5386
 End of changes. 45 change blocks. 
109 lines changed or deleted 287 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/