Subject: [APPS-REVIEW] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)

From: Dave Crocker <[email-masked]>
Date: Mon, 03 Dec 2007 15:12:24 -0800

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

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review