Review of:
DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
Reviewed by:
D. Crocker
4 December 2007
The DKIM working group has followed its specification of a base method for
associating a responsible identity to an email, via cryptographic signing,
with the current draft, DKIM Sender Signing Practices (SSP). The SSP
specification describes itself as defining a mechanism "senders may use to
advertise how they sign their outgoing mail, and how verifiers should access
and interpret those results." That is, SSP permits potential DKIM signers to
publish statements about how they use DKIM, and also to publish directions for
DKIM validators (receivers) on how they are to handle a class of received
messages.
The SSP mechanism is to have a potential signer -- that is, the owner of a
domain name -- publish an SSP-specific DNS TXT record, in an SSP-specific
branch under the domain name. On the receive-side, the domain name under
which the DNS query is made is taken from the rfc2822.From <addr-spec> portion
of an address, in a received message.
By associating an organization's verifiable identity to a message, the
reputation of that organization can then be used by a message receiving
engine, for determining message handling, such as whether to deliver the
message to the designated recipient. This is what DKIM Base permits.
By contrast, SSP seeks to detect misbehaviors, specifically related to
unauthorized use of a domain in an RFC2822.From field <addr-spec>. SSP does
not seek to deal with other identity fraud, such as in the RFC2822.From
<display-name>, the Subject field, or in the message body.
In general, the draft needs to consider adoption incentives for receivers. My
guess is that such an analysis will show that there is a relatively small set
of publishers and receivers who are highly motivated to implement the more
advanced features -- advanced relative to earlier SSP drafts -- but that true,
Internet-scale adoption will be elusive for quite some time.
In my opinion, the draft should be broken into an initial core, with optional
extensions. The core should define the publication mechanism and the smallest
set of features that are deemed useful and likely to receive a broad base of
initial adoption. The extensions would target the smaller set of adopters who
are viewed as being strongly motivated for these enhancement. The core would
be appropriate for direct standardization, while the options would be
experimental.
BASIC ISSUES
============
1. Signer/Validator practices "negotiation" scope
SSP's description of itself as including "how verifiers should... interpret
those results" states a scope of protocol semantics that is new to the IETF;
the protocol is not constrained to "interpret" with respect to defining what
the published information means, but rather is meant to guide, or even
mandate, how the mail receive-side participant should handle messages.
I believe the IETF has not previously standardized a specification which
attempts to have one network participant dictate the internal operating
behaviors of another, outside of the protocol interaction itself. As such,
efforts in this direction need to be careful, modest and incremental.
There have been some Internet publication mechanisms used that might be
thought to be similar to SSP. Most are third-party, centrally controlled
attribute or quality databases. These are an entirely different
administrative and information models from the self-published directive nature
of SSP.
2. Unsigned vs. Mismatched Signature
The original SSP specification applied only to unsigned messages. The current
version includes mail that is signed but has different domains between the
DKIM i= attribute and the rfc2822.From field. Presumably, this new capability
overrides whatever reputation is associated with the message signer.
If a signer has a good reputation, then why is that not sufficient for
enabling delivery? In other words, with a signature of a domain with a good
reputation, what threats is SSP trying to protect against?
3. Scope and scale of query traffic
SSP originally was constrained to apply only to unsigned mail. The current
specification applies to unsigned messages *and* signed messages where the
DKIM i= domain name does not match the rfc2822.From <addr-spec> domain. This
is a considerable change in the nature -- and potentially a considerable
change in the amount of query traffic -- that SSP causes.
The draft does note that initial receive-side adopters of SSP will find no SSP
DNS record. However the draft does not address the adoption and use impact of
being expected to make a query that will almost always fail for a significant
number of years into the future.
4. Service Model
Although bits of Service Model description are in the document -- mostly the
Introduction -- the specification lacks a coherent description of its
operating framework and, instead, dives directly into normative detail, often
without providing an integrated view of the service.
5. DKIM-Signature d= vs. i= parameter use
Recent discussions about using DKIM Base have uncovered some confusion about
the semantics and role for the values of the d= and i= signature parameters.
In particular, which of them specifies the single identity that is the
validated "output" of a DKIM receive-side signature processor, as representing
the signer's declaration of a responsible identity?
From my reading of extended conversations on this issue, it is not yet
resolved. In looking at the way this issue is discussed, my best guess is
that it will not be resolved merely by discussion. That is, I think it will
require a few years of operational practice before the question is settled.
The current SSP specification chooses to use the i= parameter. At best this
ensures that that portion of SSP should be considered as experimental. At
worst, it is actually the wrong choice.
6. Signature Semantics
DKIM was devised to provide a means of declaring an (organization's) identity
that is taking "responsibility" for placing a message into the transit stream.
This is a very constrained semantic for the signature, and really pertains to
no more than a delivery decision.
In reviewing the apparent semantics of full SSP use, I believe it seeks to
move a DKIM signature, which uses the same domain name as is in the From
field, into the realm of declaring content to be valid. This is a much more
demanding semantic and, I believe, moves the DKIM/SSP service into direct
competition with S/MIME and PGP. At best, this seems entirely ill-advised.
At the least, it is considerably more ambitious than the initial functions
discussed for SSP. For an initial version of a standard, more ambitious means
more risky.
7. Resolution in the Face of Multiple From field Addresses
When there are multiple address in a message's rfc2822.From field, the SSP
specification arbitrarily declares that the first address shall be used for
SSP enforcement. Although multiple From addresses is rare, its use is valid
and, in particular, occurs when the content's authors want to communicate
something significant about the authorship. In light of that, arbitrarily
coercing which of the authors is allowed to submit the message is quite
troubling, especially since it is usually a subordinate author who does the
scut work of document maintenance and public posting.
Unfortunately, this is a problem for which there is no obvious solution. Since
SSP should not get into the business of changing who is permitted to post
valid mail, the issue does very much need better resolution.
8. Filter Engine vs. End-user as SSP Target
Human Factors ("usability") design is an arcane topic largely resolved only by
experimentation. Certainly effective design of user interfaces is a black
art. As a consequence, the IETF has made it a practice to avoid the topic
entirely. This issue came up repeatedly during the early -- and later -- days
of DKIM and was resolved by deciding that DKIM's target is the receive-side
delivery filtering engine, rather than the human recipient.
The current SSP has re-introduced a range of assumptions about use with human
recipients, and has used those assumptions for dictating specification
details. The specification needs to remove all consideration of human issues
or else to provide substantial empirical basis for its inclusion.
9. Threat Analysis
I believe the current specification pursues a narrow range of threats, without
there being a clear statement of what those threats are, and why they need
resolution, when other threats do not.
Given the previous work on threats, pertaining to DKIM (and SSP?) this could
well be a simple exercise. I am raising the issue, because I suspect that the
current work goes beyond what was previously analyzed.
DETAILED COMMENTS
=================
Abstract
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and
contents of messages by either Mail Transport Agents (MTAs) or Mail
User Agents (MUAs). The primary DKIM protocol is described in
Allman, et al. Expires March 20, 2008 [Page 1]
Internet-Draft DKIM SSP September 2007
[RFC4871].
This document describes the records that senders may use to advertise
how they sign their outgoing mail, and how verifiers should access
and interpret those results.
"...access and interpret those results." What "results"?
As for "interpreting", a basic question is whether the publisher of SSP
records is simply stating their own behavior or whether they are providing
direction to receivers. Language like "how verifiers should interpret those
results" does not have to mean the latter, but it comes close and does appear
to be what is intended, as one reads the rest of the document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Language and Terminology . . . . . . . . . . . . . . . . . . . 5
2.1. Terms Imported from DKIM Signatures Specification . . . . 5
2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5
2.3. Originator Address . . . . . . . . . . . . . . . . . . . . 5
2.4. Originator Domain . . . . . . . . . . . . . . . . . . . . 6
2.5. Alleged Signer . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Alleged Originator . . . . . . . . . . . . . . . . . . . . 6
2.7. Sender Signing Practices . . . . . . . . . . . . . . . . . 6
2.8. Originator Signature . . . . . . . . . . . . . . . . . . . 6
2.9. Suspicious . . . . . . . . . . . . . . . . . . . . . . . . 6
2.10. Third-Party Signature . . . . . . . . . . . . . . . . . . 7
2.11. Verifier Acceptable Third-Party Signature . . . . . . . . 7
3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 7
4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 8
4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 8
4.2. Publication of SSP Records . . . . . . . . . . . . . . . . 9
4.3. Record Syntax . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Sender Signing Practices Check Procedure . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.1. Fraudulent Sender Address . . . . . . . . . . . . . . . . 14
6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 15
B.1. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 15
B.2. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16
B.3. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 16
B.4. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Allman, et al. Expires March 20, 2008 [Page 3]
Internet-Draft DKIM SSP September 2007
1. Introduction
DomainKeys Identified Mail (DKIM) defines a mechanism by which email
messages can be cryptographically signed, permitting a signing domain
to claim responsibility for the introduction of a message into the
mail stream. Message recipients can verify the signature by querying
the signer's domain directly to retrieve the appropriate public key,
and thereby confirm that the message was attested to by a party in
possession of the private key for the signing domain.
However, the legacy of the Internet is such that not all messages
will be signed, and the absence of a signature on a message is not an
a priori indication of forgery. In fact, during early phases of
deployment it must be expected that most messages will remain
unsigned. However, some domains may choose to sign all of their
outgoing mail, for example, to protect their brand name. It is
highly desirable for such domains to be able to advertise that fact
to verifiers, and that messages claiming to be from them that do not
have a valid signature are likely to be forgeries. This is the topic
for sender signing practices.
This seems to ignore the potential for broken signatures, which produces
"unsigned" messages that are not forgeries.
Still, the above paragraph provides a very clean statement of scope:
"some domains may choose to sign all of their outgoing mail, for example,
to protect their brand name. It is highly desirable for such domains to be
able to advertise that fact to verifiers"
The paragraph would help readers by distinguishing this bit of text visually
and by holding the issue of forgery for a separate -- and better qualified --
commentary.
In the absence of a valid DKIM signature on behalf of the "From"
address [RFC2822], message verifiers implementing this specification
MUST determine whether messages from that sender are expected to be
signed, and what signatures are acceptable. In particular, whether a
Normative text in the Introduction?
I initially thought that the statement, here, provided a crisp statement
of scope, but then realized that the "signature on behalf of the From address"
left things unclear.
For one thing, it means that SSP will apply to some signed messages, and not
only to unsigned messages.
For another, it appears that the test to perform is with the DKIM i=
parameter. This can get a bit tricky. For example, since the DKIM base
specification does not require that the i= parameter directly relate to the
From field, this seems to carry an implied modification to DKIM base? So it
seems to require that i= be entirely redundant with (one of?) the rfc2822.from
address(es) in every detail?
As for "what signatures are acceptable", the implied, open-ended complexity in
this statement is huge. Think, for a moment, of just how varied the
description of 'acceptable' signatures could become.
Given that DKIM pertains to domains that are trusted, rather than to domains
that are untrusted, this line of SSP effort appears to be conflating the two
worlds.
domain signs all outbound email must be made available to the
verifier. Without such a mechanism, the benefit of message signing
Here is the normative "must" again. In any event, what does this must
sentence mean?
techniques such as DKIM is limited since unsigned messages will
always need to be considered to be potentially legitimate. This
A declaration of the limited utility of DKIM, without SSP, is gratuitous,
probably wrong, and probably counter-productive for early DKIM adoption.
determination is referred to as a Sender Signing Practices check.
Conceivably, such expressions might be imagined to be extended in the
future to include information about what hashing algorithms a domain
uses, what kind of messages might be sent (e.g., bulk vs. personal
vs. transactional), etc. Such concerns are out of scope of this
Conceivably, such expressions might be imagined to be extended to do just
about anything...
What is the purpose of adding this kind of hypothetical here?
Whatever the intent, it actually serves to distract the focus of the current
specification, by invoking issues that are entirely out of scope for a
specification.
It needs to be removed.
standard, because they can be expressed in the key record
("Selector") with which the signature is verified. In contrast, this
This appears to be raising the issue of what to publish via one kind of
record, versus another (and probably versus within the message.) That's a
useful conceptual design topic, but probably best dealt with on its own,
rather than as a secondary aspect of a hypothetical.
specification focuses on information which is relevant in the absence
of a valid signature. Expressions of signing practice which require
outside auditing are similarly out of scope for this specification
because they fall under the purview of reputation and accreditation.
What does "outside auditing" mean, here?
The detailed requirements for Sender Signing Practices are given in
[I-D.ietf-dkim-ssp-requirements], which the protocol described in
this document attempts to satisfy. This document refers extensively
to [RFC4871], which should be read as a prerequisite to this
document.
Allman, et al. Expires March 20, 2008 [Page 4]
Internet-Draft DKIM SSP September 2007
2. Language and Terminology
2.1. Terms Imported from DKIM Signatures Specification
Some terminology used herein is derived directly from [RFC4871].
Briefly,
o A "Signer" is the agent that signs a message. In many cases it
will correspond closely with the original author of the message or
an agent working on the author's behalf.
Why not simply say that it is the domain listed in the d= parameter of a DKIM
signature? Looking at the definition of d= and the definition of i=, it
appears that d= is the signer.
o A "Verifier" is the agent that verifies a message by checking the
actual signature against the message itself and the public key
published by the Alleged Signer. The Verifier also looks up the
Sender Signing Practices published by the domain of the Originator
Address if the message is not correctly signed by the Alleged
Originator.
Again: SSP is now not restricted to unsigned messages. It applies also to a
potentially very large class of signed messages. In effect, SSP now appears
to attempting to emulate SPF strictures of correlation among identity fields.
Question: Is DKIM for transit validation or is it for content authentication?
If the latter, then it truly has become competitive with S/MIME and PGP? If
the former, then why does SSP need to attempt such rigorous enforcement of
From field details?
o A "Selector" specifies which of the keys published by a signing
domain should be queried. It is essentially a way of subdividing
the address space to allow a single sending domain to publish
multiple keys.
2.2. Valid Signature
A "Valid Signature" is any signature on a message which correctly
verifies using the procedure described in section 6.1 of [RFC4871].
2.3. Originator Address
The "Originator Address" is the email address in the From header
field of a message [RFC2822], or if and only if the From header field
contains multiple addresses, the first address in the From header
field.
This means "Author", since RFC2822 uses the term Originator more broadly and
it does not seem advisable to have SSP define the term differently.
(FWIW, the email-arch draft is being changed to say 'author', also.)
NON-NORMATIVE RATIONALE: The alternative option when there are
multiple addresses in the From header field is to use the value of
the Sender header field. This would be closer to the semantics
indicated in [RFC2822] than using the first address in the From
header field. However, the large number of deployed Mail User
Agents that do not display the Sender header field value argues
against that. Multiple addresses in the From header field are
rare in real life.
Actually, the problem here is that the definition is a bit Procrustean and
effectively modifies RFC2821 and/or RFC2822, since it constrains who is
permitted to be listed as an author (or the order in which they can be listed)
and still post the message.
The document needs a single address here, so that having a From that lists
multiple actual authors is inconvenient. While it might or might not be
practical to arbitrarily choose the first author address, it is nonetheless
quite arbitrary. And arbitrary choices in situations like this suggest shaky
ground for the basic mechanism. At the least, it suggests that the scope of
application for the mechanism is limited. The limitation should simply be
stated, rather than hacked around.
The reference to display of addresses discloses a basic assumption in the SSP
work, namely that it pertains to what is displayed to users. This is vastly
different than determining deliverability of a message and, again, suggests
that SSP is attempting to declare the validity of particular content.
In any event, since SSP is declaring a choice on the basis of what is
displayed to users, where is the empirical basis for knowing that it will have
the desired effect? By the way, where is that desired effect stated in this
document?
Even when there is only one address in the From header field, this
address is chosen as the reference address for SSP lookups because
it represents the author of the message and is more widely
displayed by Mail User Agents as a result. The Sender header
Allman, et al. Expires March 20, 2008 [Page 5]
Internet-Draft DKIM SSP September 2007
field frequently has other meanings.
I'm not at all sure what precise "meanings" SSP is seeking, here, nor what
other "meanings" a Sender field can have. Please clarify.
2.4. Originator Domain
The "Originator Domain" is everything to the right of the "@" in the
Originator Address (excluding the "@" itself).
2.5. Alleged Signer
An "Alleged Signer" is the identity of the signer claimed in a DKIM-
Signature header field in a message received by a Verifier; it is
"alleged" because it has not yet been verified.
d= parameter?
2.6. Alleged Originator
An "Alleged Originator" is the Originator Address of a message
received by a Verifier; it is "alleged" because it has not yet been
verified.
SSP is stating that it verifies the From field?
2.7. Sender Signing Practices
"Sender Signing Practices" (or just "practices") consist of a
machine-readable record published by the domain of the Alleged
Originator which includes information about whether or not that
domain signs all of their email, and whether signatures from third
parties are sanctioned by the Alleged Originator.
2.8. Originator Signature
An "Originator Signature" is any Valid Signature where the signing
address (listed in the "i=" tag if present, otherwise its default
value, consisting of the null address, representing an unknown user,
followed by "@", followed by the value of the "d=" tag) matches the
Originator Address. If the signing address does not include a local-
part, then only the domains must match; otherwise, the two addresses
must be identical.
Hmmm... i=...
There is significant confusion about the semantics of d= vs. i=.
Having SSP make normative choices that rely on a particular resolution of that
issue, before there is significant field experience to establish the semantics
the operational world will use, is quite risky.
2.9. Suspicious
Messages that do not contain a valid Originator Signature and which
are inconsistent with a Sender Signing Practices check (e.g., are
received without a Valid Signature and the sender's signing practices
indicate all messages from the domain are signed) are referred to as
"Suspicious". The handling of such messages is at the discretion of
the Verifier or final recipient. "Suspicious" applies only to the
DKIM evaluation of the message; a Verifier may decide the message
should be accepted on the basis of other information beyond the scope
of this document. Conversely, messages not deemed Suspicious may be
This is the strongest indication that the SSP specification has moved from
describing sender-side practices to, instead, attempting to tell receive-side
validators how to behave.
A term like "suspicious" is emotionally charged. Given that breakage can (and
will) sometimes account for the condition being described, here, it would be
better to use a term that is descriptive of the situation, rather than having
it assert a qualitative assessment.
Allman, et al. Expires March 20, 2008 [Page 6]
Internet-Draft DKIM SSP September 2007
rejected for other reasons.
So, the term 'suspicious' will be applied to some acceptable messages and not
applied to some bogus messages?
2.10. Third-Party Signature
A "Third-Party Signature" is a Valid Signature which is not an
Originator Signature.
So everyone who handles a message, but is not the author, and signs it with
their own domain, is a third-party? This reinforces the suggestion that a
more neutral and precise term be used, rather than 'suspicious'. Starting
from the assumption that all "third party" signatures are "suspicious" is
misguided, since it is already likely that operators will be signing with
their own domain, even when the rfc2822 From is for one of their customer's
organizations.
2.11. Verifier Acceptable Third-Party Signature
A Verifier Acceptable Third-Party Signature is a Third-Party
Signature that the Verifier is willing to accept as meaningful for
the message under consideration. The Verifier may use any criteria
it deems appropriate for making this determination.
While it might seem an arbitrary criterion to use for this assessment, the
length of the term, here, should serve to suggest that its domain of discourse
is far beyond anything that should be covered in a first-attempt for a new
mechanism like this.
At the least, it mandates a fairly thorough discussion of the signer/validator
decision model into which it fits. In other words, the label makes clear that
this is a complex realm, yet we have no description of it in terms of likely
publishers and likely users of the published information.
3. Operation Overview
Sender Signing Practices checks MUST be based on the Originator
Address. If the message contains a valid Originator Signature, no
Sender Signing Practices check need be performed: the Verifier
Exactly. The original SSP was invoked when there was no signature. The
current SSP is invoked when the i= domain is not the same as the rfc2822.from
domain. Very different model.
SHOULD NOT look up the Sender Signing Practices and the message MUST
NOT be considered Suspicious.
Verifiers checking messages that do not have at least one valid
Originator Signature MUST perform a Sender Signing Practices check on
the domain specified by the Originator Address as described in
Section 4.4.
A Sender Signing Practices check produces one of four possible
results:
1. Some messages from this domain are not signed; the message MUST
NOT be considered Suspicious, even in the absence of a valid
signature. This is the default.
Which is the same as we get when there is no SSP. So why is it needed?
2. All messages from this domain are signed. Messages containing a
Verifier Acceptable Third-Party Signature MUST NOT be considered
Suspicious.
NON-NORMATIVE RATIONALE: Third-party signatures, since they
can potentially represent any domain, are considered more
likely to be abused by attackers seeking to spoof a specific
A third-party signature of a domain that has a good reputation is more likely
to represent spoofing???
This sounds like the enforcement of the Author domain on signing overrides any
reputation that might exist for the signer. Is that really what is intended?
address. It may therefore be desirable for verifiers to apply
other criteria outside the scope of this specification in
deciding to accept a given third-party signature. For
The sentence really gets to the core problem: Verifiers already use a vast
array of criteria and they have made clear they are going to continue to do
so. Yet SSP seems to be written with the belief that it can force changes to
that array, rather than merely making a friendly effort to add to the
repertoire of information that validators might choose to use.
Note that the specification is written so as to incur added query overhead for
nearly every message, even though, for virtually all initial occurrences, the
query will fail. What is the basis for believing that validators are willing
to incur this overhead?
example, a list of known mailing list domains used by
addresses served by the verifier might be specifically
considered acceptable third-party signers.
One of the problems with path-based registration is that it requires
registering mailing list servers. It appears that the above text is
attempting to impose that limitation on DKIM signing.
Allman, et al. Expires March 20, 2008 [Page 7]
Internet-Draft DKIM SSP September 2007
3. All valid messages from this domain are signed; the domain of the
Alleged Originator requests that only messages with valid
Originator Signatures be considered not Suspicious; Third-Party
Signatures are irrelevant. This practice would typically be used
"irrelevant"?
In any event, what is the basis for believing that there will be substantial
adoption of this feature by validators?
by domains which send only transactional email (i.e., do not use
mailing lists and such that are likely to break signatures) and
which wish to emphasize security over deliverability of their
messages. In the absence of a valid Originator Signature, the
message MUST be considered Suspicious.
4. The domain does not exist; the message MUST be considered
Suspicious.
Presumably "does not exist" means there is no DNS record. (Otherwise, the
phrase "does not exist" needs to be explained.)
Since virtually all initial queries will find that there is no DNS record,
this mandates treating virtually all mail as "suspicious" for some unknown
number of years/decades.
So what, exactly, is the behavior of a validator that is being specified,
for a message to be "suspicious"? For that matter, what does it mean for a
message NOT to be "suspicious"?
If the Sender Signing Practices record for the domain does not exist
but the domain does exist, Verifier systems MUST assume that some
messages from this domain are not signed and the message MUST NOT be
considered Suspicious.
I think the above text should be labeled #5, since it specifies a condition
different from #4?
4. Detailed Description
4.1. DNS Representation
Sender Signing Practices records are published using the DNS TXT
resource record type.
NON-NORMATIVE DISCUSSION: There has been considerable discussion
on the DKIM WG mailing list regarding the relative advantages of
TXT and a new resource record (RR) type. Many DNS server and
resolver implementations are incapable of quickly and easily
supporting new resource record types. For this reason, support of
TXT records is required whether a new RR type is defined or not.
However, without a "flag day" on which SSP TXT record support is
to be withdrawn, such support is likely to continue indefinitely.
As a result, this specification defines no new RR type for SSP.
Another alternative proposed by P. Hallam-Baker is the publication
of both a TXT record and, when implementations permit, a new RR,
referred to as XPTR, which gives the location from which SSP and
other policy information relating to a give domain can be
retrieved. This has the advantage of supporting a variety of
policies in a scalable manner, with better handling of wildcards
and centralized publication of policy records, with caching
advantages. However, the above implementation issues also apply
to XPTR, and an additional lookup is required to retrieve SSP via
the XPTR method. At the time of publication of this draft,
consensus on this proposal was unclear.
Allman, et al. Expires March 20, 2008 [Page 8]
Internet-Draft DKIM SSP September 2007
The RDATA for SSP resource records is textual in format, with
specific syntax and semantics relating to their role in describing
sender signing practices. The "Tag=Value List" syntax described in
section 3.2 of [RFC4871] is used. Records not in compliance with
that syntax or the syntax of individual tags described in Section 4.3
MUST be ignored (considered equivalent to a NODATA result) for
purposes of message disposition, although they MAY cause the logging
of warning messages via an appropriate system logging mechanism.
SSP records for a domain are published at a location in the domain's
DNS hierarchy prefixed by _ssp._domainkey; e.g., the SSP record for
example.com would be a TXT record that is published at
_ssp._domainkey.example.com.
While the sub-naming scheme is reasonable, why not merely have _ssp by itself,
as _ssp.example.com rather than _ssp._domainkey?
The two-level approach makes sense if there is any reasonable expectation of
very large numbers of underscore-delimited attribute space. Otherwise is
seems like unnecessary overhead. My own guess is that scaling is not an issue
here.
4.2. Publication of SSP Records
Sender Signing Practices are intended to apply to all mail sent from
"Intended"? In terms of what is specified, what does this mean?
the domain of an Alleged Originator, and to the greatest extent
possible, to all subdomains of that domain. There are several cases
that need to be considered in that regard:
o The domain itself
o Subdomains which may or may not be used for email
o Hostnames which may or may not be used for email
o Other named resource records in the domain
o Multi-level examples of the above, e.g., a.b.example.com
o Non-existent cases, i.e., a subdomain or hostname that does not
actually exist within the domain
By "not actually exist" I assume this refers to not being visible in the
public DNS?
Is public visibility the proper constraint for defining whether a
domain name exists?
Normally, a domain expressing Sender Signing Practices will want to
do so for both itself and all of its "descendents" (child domains and
hosts, at all lower levels). Domains wishing to do so MUST publish
SSP records as follows:
Publish an SSP record for the domain itself
Publish an SSP record for any existing subdomain
Note that since the lookup algorithm described below references the
immediate parent of the alleged originating domain, it is not
necessary to publish SSP records for every single-level label within
the domain. This has been done to relieve domain administrators of
the burden of publishing an SSP record for every other record in the
Allman, et al. Expires March 20, 2008 [Page 9]
Internet-Draft DKIM SSP September 2007
domain, which would be otherwise required.
Wildcards within a domain, including but not limited to wildcard MX
records, pose a particular problem. While referencing the immediate
parent domain allows the discovery of an SSP record corresponding to
an unintended immediate-child subdomain, wildcard records apply at
multiple levels. For example, if there is a wildcard MX record for
example.com, the domain foo.bar.example.com can receive mail through
the named mail exchanger. Conversely, the existence of the record
makes it impossible to tell whether foo.bar.example.com is a
legitimate name since a query for that name will not return an
NXDOMAIN error. For that reason, SSP coverage for subdomains of
domains containing a wildcard record is incomplete.
NON-NORMATIVE NOTE: Complete SSP coverage of domains containing
(or where any parent contains) wildcards generally cannot be
guaranteed.
4.3. Record Syntax
SSP records follow the "tag=value" syntax described in section 3.2 of
[RFC4871]. The SSP record syntax is a tag-list as defined in that
section, including the restriction on duplicate tags, the use of
white space, and case sensitivity.
Tags used in SSP records are as follows. Unrecognized tags MUST be
ignored. In the ABNF below, the FWS token is inherited from
[RFC2822] with the exclusion of obs-FWS. The ALPHA and DIGIT tokens
are imported from [RFC4234].
dkim= Outbound signing practices for the domain (plain-text;
REQUIRED). Possible values are as follows:
unknown The domain may sign some or all email.
all All mail from the domain is signed; unsigned email MUST be
considered Suspicious. The domain may send messages through
agents that may modify and re-sign messages, so email signed
with a Verifier Acceptable Third-Party Signature SHOULD NOT be
considered Suspicious.
I believe that "from the domain" is not rigorously defined in the specification.
I believe the definition being used here is that the domain in the
DKIM-Signature i= parameter must match the domain in the rfc2822.From field.
strict All mail from the domain is signed; messages lacking a
valid Originator Signature MUST be considered Suspicious. The
domain does not expect to send messages through agents that may
modify and re-sign messages.
This value appears to conflate three separate issues:
1. All mail with this domain in the From field will be signed by that domain.
2. No mail with this domain in the From field will be sent via mailing
lists or other Mediators (re-posting services.)
3. The owner of this domain considers non-delivery (including due to
broken signature) preferable over delivery of messages with this domain in the
From field, but lacking a valid signature with this domain in the i= parameter.
At a minimum, the document should have text that considers the range of mail
practices, such that this particular configuration of behaviors and needs is
only one of the set. That way, there is a serious context for assessing the
choice to have this particular, single flag, as representing a particular
multi-attribute set.
In terms of terminology choice, a more semantically useful label might be
something like "integrated". Many scenarios could be "strict", so that the
choice, here, does not convey much specific meaning. I suggest "integrated"
because I believe the flag applies to scenarios in which all aspects of the
sender's email content and operations are tightly integrated.
Allman, et al. Expires March 20, 2008 [Page 10]
Internet-Draft DKIM SSP September 2007
NON-NORMATIVE RATIONALE: Strict practices may be used by
entities which send only transactional email to individual
addresses and which are willing to accept the consequence of
having some mail which is re-signed appear suspicious in
return for additional control over their addresses. Strict
practices may also be used by entities which do not send
(and therefore do not sign) any email.
ABNF:
ssp-dkim-tag = "dkim" [FWS] "=" [FWS] ("unknown" /
"all" / "strict")
To repeat: Even if not specified into the set of parameter values, it would
be useful to have some text that explores the space of choices that these 3
values are chosen from.
handling= Non-compliant message handling request for the domain
(plain-text; OPTIONAL). Possible values are as follows:
For some reason, the above language seems awkward to me. I assume the meaning
is "Author domain request for handling of non-compliant messages"?
In any event, this again makes clear that SSP has moved from describing
'sender' practices into an attempt by a sender to dictate validator behaviors
when using sender practices information.
process Messages which are Suspicious from this domain SHOULD be
processed by the verifier, although the SSP failure MAY be
considered in subsequent evaluation of the message. This is
the default value.
deny Messages which are Suspicious from this domain MAY be
rejected, bounced, or otherwise not delivered at the option of
the verifier.
NON-NORMATIVE EXPLANATION: The "deny" practice is intended
for use by domains that value security over deliverability.
For example, a domain used by a financial institution to
send transactional email, which signs all of its messages,
might consider their concern about phishing messages
purporting to come from their domain to be higher than their
concern about some some legitimate messages not being
delivered. The "handling=deny" practice allows them to
express that concern in a way that can be acted upon by
verifiers, if they so choose.
ABNF:
ssp-handling-tag = "handling" [FWS] "=" [FWS] ("process" /
"deny")
t= Flags, represented as a colon-separated list of names (plain-text;
OPTIONAL, default is that no flags are set). Flag values are:
y The domain is testing signing practices, and the Verifier
SHOULD NOT consider a message suspicious based on the record.
I'll again make the long-standing observation that a "testing" bit permanently
burdens implementations with a mechanism that is useful only in the early
stages of the protocol. Again note that such a mechanism has not been needed
for previous Internet protocols.
Allman, et al. Expires March 20, 2008 [Page 11]
Internet-Draft DKIM SSP September 2007
s The signing practices apply only to the named domain, and not
to subdomains.
So this is intended to overcome the problem of not being able to use wildcards?
What is the query behavior that validators need to use, to discover this
record, when they start with a message having a deeply-nested From field
domain name?
ABNF:
ssp-t-tag = %x75 [FWS] "=" [FWS] ssp-t-tag-flag
0*( [FWS] ":" [FWS] ssp-t-tag-flag )
ssp-t-tag-flag = "y" / "s" / hyphenated-word
; for future extension
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-")
(ALPHA / DIGIT) ]
Unrecognized flags MUST be ignored.
4.4. Sender Signing Practices Check Procedure
Verifiers MUST produce a result that is semantically equivalent to
applying the following steps in the order listed. In practice,
several of these steps can be performed in parallel in order to
improve performance.
1. If a valid Originator Signature exists, the message is not
Suspicious, and the algorithm terminates.
2. The Verifier MUST query DNS for a TXT record corresponding to
the Originator Domain prefixed by "_ssp._domainkey.". If the
result of this query is a NOERROR response with one or more
answers which are syntactically-valid SSP responses, proceed to
step 7.
3. The Verifier MUST query DNS for an MX record corresponding to
the Originator Domain (with no prefix). This query is made only
to check the existence of the domain name and MAY be done in
parallel with the query made in step 2. If the result of this
query is an NXDOMAIN error, the message is Suspicious and the
algorithm terminates.
This seems to make clear that SSP has moved seriously into more general
aspects of receive-side analysis. At best, this is premature for this work.
NON-NORMATIVE DISCUSSION: Any resource record type could be
used for this query since the existence of a resource record
of any type will prevent an NXDOMAIN error. The choice of MX
for this purpose is because this record type is thought to be
the most common for likely domains, and will therefore result
in a result which can be more readily cached than a negative
result.
4. If the immediate parent of the Originator Domain is a top-level
domain (a domain consisting of a single element such as "com",
"us", or "jp"), then the message is not Suspicious (because no
Allman, et al. Expires March 20, 2008 [Page 12]
Internet-Draft DKIM SSP September 2007
SSP record was found) and the algorithm terminates. The
verifier MAY also compare the parent domain against a locally-
maintained list of known address suffixes (e.g., .co.uk) and
terminate the algorithm with a not Suspicious result if the
parent domain matches an entry on the list.
Specifying anything that attempts to use knowledge of domain name hierarchy
conventions is particularly ill-advised.
5. The Verifier MUST query DNS for a TXT record for the immediate
parent domain, prefixed with "_ssp._domainkey." If the result
of this query is a NOERROR response with one or more answers
which are syntactically-valid SSP responses, proceed to step 6.
Otherwise, the message is not Suspicious and the algorithm
terminates.
6. If the SSP "t" tag exists in the response and any of the flags
is "s" (indicating it should not apply to a subdomain), the
message is not Suspicious and the algorithm terminates.
7. If the SSP "t" tag exists in the response and any of the flags
is "y" (indicating testing), the message is not Suspicious and
the algorithm terminates.
8. If the value of the SSP "dkim" tag is "unknown", the message is
not Suspicious and the algorithm terminates.
9. If the value of the SSP "dkim" tag is "all", and one or more
Verifier Acceptable Third-Party Signatures are present on the
message, the message is not Suspicious and the algorithm
terminates.
10. The message is Suspicious and the algorithm terminates.
If any of the queries involved in the Sender Signing Practices Check
result in a SERVFAIL error response, the verifier MAY either queue
the message or return an SMTP error indicating a temporary failure.
This is a fairly complex decision tree, for an initial specification of a new
type of protocol.
5. IANA Considerations
IANA is requested to create a "DKIM selector name" registry and to
reserve the selector name "_ssp" to avoid confusion between DKIM key
records and SSP records.
6. Security Considerations
Security considerations in the Sender Signing Practices are mostly
related to attempts on the part of malicious senders to represent
themselves as other senders, often in an attempt to defraud either
Allman, et al. Expires March 20, 2008 [Page 13]
Internet-Draft DKIM SSP September 2007
the recipient or the Alleged Originator.
Additional security considerations regarding Sender Signing Practices
may be found in the DKIM threat analysis [RFC4686].
My guess is that the security issues for this specification are quite
substantial and that there needs to be quite a bit more effort to consider them.
6.1. Fraudulent Sender Address
[[Assuming 3rd party signature is based on Sender header field]] If
the Sender Signing Practices sanction third-party signing, an
attacker can create a message with a From header field of an
arbitrary sender and a legitimately signed Sender header field
6.2. DNS Attacks
An attacker might attack the DNS infrastructure in an attempt to
impersonate SSP records. However, such an attacker is more likely to
attack at a higher level, e.g., redirecting A or MX record lookups in
order to capture traffic that was legitimately intended for the
target domain. Domains concerned about this should use DNSSEC
[RFC4033].
Because SSP operates within the framework of the legacy e-mail
system, the default result in the absence of an SSP record is that
the domain does not sign all of its messages. Therefore, a DNS
attack which is successful in suppressing the SSP response to the
verifier is sufficient to cause the verifier to see unsigned messages
as non-suspicious, even when that is not intended by the alleged
originating domain.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html