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

From: Dave Crocker <[email-masked]>
Date: Mon, 03 Dec 2007 15:37:04 -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
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 4 Dec 2007 04:23:27 -0000

>      DKIM Sender Signing Practices  (draft-ietf-dkim-ssp-01)

Wow, thanks for a very thorough review.

The biggest problem with this draft is that it goes way beyond
defining a protocol.

Part of it describes the way that senders publish statements about
their sending practices and the way that receivers can look for those
statements, which is fine, but the rest attempts to tell receivers
what to do with mail they have received, which is not.

It really needs to back up and define how a sender publishes its
policy, how a recipient can look up a policy if it wants to do so,
then stop.  That's all they need to interoperate.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 3 Dec 2007 23:55:45 -0500

> then stop.  That's all they need to interoperate.
-1

While senders certainly can't dictate receiver policy, giving an indication of 
what they expect to have happen is perfectly reasonable and reduces 
uncertainty.

Scott K

---

From: John Levine <[email-masked]>
Date: 4 Dec 2007 05:40:27 -0000

> While senders certainly can't dictate receiver policy, giving an
> indication of what they expect to have happen is perfectly
> reasonable and reduces uncertainty.

Uncertainty about what?  You can be 100% certain that if you've
published your policies in SSP, any receiver who cares to know about
them can look them up.

No matter what you do, you don't get certainty about their internal
filtering practices any more than you get certainty about whether
their internal delivery practices use POP, IMAP, or Baudot paper tape.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Dec 2007 0:52:43 -0500

>their internal delivery practices use POP, IMAP, or Baudot paper tape.
Agreed.  That's why I said you can't dictate receiver policy.  It's because 
you can't and we all know that.

Reduced uncertainty about what the sender intended.  We've been through 
this before, so there's no need to tell me that is valueless.  I disagree 
and I doubt on another round through it either of us will convince the 
other.

Ever since the SSP work was deferred at the start of the working group, my 
expectation was weald get either no SSP or one that was seriously watered 
down.  I'm still waiting to see if this group manages to produce something 
worth deploying.

Scott K

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 4 Dec 2007 09:38:37 +0100

Scott Kitterman wrote:
 
> I'm still waiting to see if this group manages to produce something 
> worth deploying.

BTW, after Dave's review I actually looked into the SSP draft again,
and found that we're talking about less than 25 bytes, if the bogus
[FWS] and the ts-flags are trashed.  

For some of Dave's objections like "why the 1st author, why ignore
the sender" (chiming in: why ignore PRA while at it) I'd say indeed,
why.  For his objection that the sender can't be different from all
author addresses I've no clue what he's up to, we discussed the case
of mailing lists only a week ago, and everybody (but me) apparently
agreed that this is as it is.  IMO it's therefore a SHOWSTOPPER for
2821bis 3.9, and maybe for the complete "2821 to DS now" movement.

A big part of Dave's other objections concerned issues with likely
pointless DNS queries, odd wildcard emulations, and trimming crude
_ssp._domainkeys labels.

For *25* bytes (adding an ssp tag 29) I'd know where to find a DNS
record complete with its own registered type, wildcard compatible
(as far as it's at all possible), and not causing additional look
ups for "some" receivers.

 Frank

---

From: "Patrick Peterson" <[email-masked]>
Date: Tue, 4 Dec 2007 02:18:51 -0800

My comments inline below. They can be summarized as follows:
1. SSP does not dictate receiver behavior. SSP bends over backwards to
state receiver behavior is at receivers' discretion. If someone can find
someplace where SSP dictates receiver behavior please identify it so it
can be fixed.

2. Some IETF particiants believe certain SSP statements such as "strict"
and "deny" are not useful SSP constructs for them. Some are explicit
that these constructs would not be used by their own mail servers.
However there is a large part of the Internet community that desires
these constructs. The brilliance of "strict" and "deny as defined in SSP
is that a strict/deny proponent like myself can build a system using the
strict/deny data provided by other strict/deny proponents' SSP records
AND strict/deny opponents can simply publish "unknown", "all" and
"process" policies and then use their discretion to ignore results
related to strict/deny. Everybody wins! I believe it would be an epic
mistake for the strict/deny opponents to prevent others from utilizing
these capabilities. I have no desire to prevent someone from ignoring
strict/deny at their discretion; why can't I have a syntax I desire to
state strict/deny for those who will use it?

pat

PS: SSP does not dicatate receiver behavior :)

> Internet-scale adoption will be elusive for quite some time.
I strongly disagree. There are a significant number of large receivers
that are highly motivated to adopt the draft. Take one example: Y! has
been public about their work with PayPal to ensure non-delivery of
unsigned or invalidly signed DK messages. (I know this is DK but the
incentive of SSP is the same for DK or DKIM.) I have been very public
about IronPort's desire to implement SSP based on the proxied desires of
our customers. The 100 US Financial Services Roundtable companies (BITS)
have also been public about their desires in this area.

> be appropriate for direct standardization, while the options would be
Again disagree. I feel the extensions are critical.

> mandate, how the mail receive-side participant should handle messages.
This is not true. draft-ietf-dkim-ssp-01 states:
"deny  Messages which are Suspicious from this domain MAY be
         rejected, bounced, or otherwise not delivered at the option of
         the verifier."
There is no mandate here.

> efforts in this direction need to be careful, modest and incremental.
Again, there is obviously no dictation here. The ability for a sender to
state a policy in such a manner that certain receivers find it most
beneficial but in a way that does not constrain other receivers is a
benefit, not a limitation.

> reputation, what threats is SSP trying to protect against?
Reputation systems are designed by organizations to optimize delivering
good mail and stopping bad mail. They will design the reputation system
however they see fit to achieve this goal. The market dynamics and
innovation will define reputation systems' design, not SSP. Hypothetical
statements about how reputation systems may develop aren't relevant to
SSP>
 
> discussed for SSP.  For an initial version of a standard, 
I have no idea what "declaring content to be valid" means.

For example, I can sign a DKIM message with SSP and this DKIM message
with matching i= and From domains can state "2+2=5". Certainly I'm not
validating the content here?

I think you mean something else.

References to S/MIME and PGP are unclear and irrelevant. I was unable to
follow this thread on the list a few weeks ago.

Let's determine what the requirements are and build a system to meet
those requirements rather than state "this design moves into the realm
of blah where blah is undefined."

> that are untrusted, this line of SSP effort appears to be 
DKIM applies to both. I can determine bankofamerica.com is trusted and
bankofamerica.cl is untrusted. I can use DKIM to authenticate the use of
each of these domains and then apply my trusted and untrusted logic
accordingly.
 
> probably wrong, and probably counter-productive for early 
I disagree. For domains which are forged regularly DKIM without SSP is
limited IMHO.

> validators how to behave.
Receiver-side validators are explicitly *not* being told how to behave.
Their behavior is at their discretion. Some receivers may use this SSP
information and it shouldn't be denied to them based on a clearly
misreading of "discretion" for "dictating". I think many will use this
information beneficially.

> it assert a qualitative assessment.
"suspicious" may be emotionally charged but "Suspicious" should not be.
capitalized "Suspicious" means something very specific in the SSP
document

> applied to some bogus messages?
First the term "suspicious" is irrelevant. The term "Suspicious" is at
play.
Some acceptable messages will be "Suspicious" because they will be
unsigned or have a broken signature. That's ok because the receiver can
term them "Suspicious" and then, at their discretion, deem them
acceptable and deliver them.
Some bogus messages will have valid DKIM signatures and matching SSP
policies. Such a message from an *untrustworthy* domain like
bankofamerica.cl is not "Suspicious" but is bogus.
 
> when using sender practices information.
Again, nothing is being dicated. The receiver has their full discretion.

---

From: "Patrick Peterson" <[email-masked]>
Date: Tue, 4 Dec 2007 02:27:42 -0800

> what to do with mail they have received, which is not.
For the 1000th time this is simply not true. Repeatedly stating SSP
"dicates receiver behavior", "tells receivers what to do", etc doesn't
make it true.

I found two statements that advise receivers. They state:
"The handling of such messages is at the discretion of the Verifier or
final recipient." (Suspicious definition)
"Messages which are Suspicious from this domain MAY be rejected,
bounced, or otherwise not delivered at the option of the verifier."
(deny)

Here is the text from SSP that defines this guidance to receivers:

2.9.  Suspicious

[There are other mentions of when to declare a message Suspicious but I
reference the instructions to the receiver found here in the
definition.]

4.3 Record Syntax
...

> then stop.  That's all they need to interoperate.
Many disagree. How about we let people publish their strict/deny
preferences and those who wish to look up a policy and do nothing else
to interoperate simply ignore strict/deny as allowed by SSP?

pat

---

From: "Patrick Peterson" <[email-masked]>
Date: Tue, 4 Dec 2007 02:36:16 -0800

> their internal delivery practices use POP, IMAP, or Baudot paper tape.
Not to speak for Scott K but I do not believe he was saying senders
expected certainty about internal filtering. SSP explicitly says this is
not the case.

Here's my spin:
As a sender the ability for me to state my desired (NOT DICTATED)
receiver policy increases the likelihood that this policy will be
considered and honored.
Senders that cannot state a desired (NOT DICTATED) receiver policy are
guaranteed such a policy will not be considered nor honored.

I desire a SSP that allows senders to state strict/deny. I care not a
whit what others do with such a policy but I feel it is beneficial
because senders want to state such policies and I can build a better
receiving system that takes it into account. Why should this be withheld
from the Internet because others think it's not useful for them?

pat

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 04 Dec 2007 13:03:27 -0000

> The biggest problem with this draft is that it goes way beyond

True. Essentially. we have standards track documents and we have BCP (Best  
Current Practice) documents, and indeed SSP could have been published as a  
standards/BCP pair. However, I accept that including BCP material in a  
standards track document is often more convenient and is reasonable  
*provided* it is clearly delineated from the normative stuff.

So SSP can clearly define, Normatively, what signers can say in their SSP  
records, and in what notation, and can say what their statements "mean"  
(that is, the semantics). Thus SSP supplies a mechanism for signers to  
transmit information with defined meaning to verifiers (and anyone else  
who cares to look at it); and defining such mechanisms is exactly what  
IETF standards are all about.

But it has no business whatsoever making normative statements about what  
verifiers are to do, so wording of the form "Verifiers MUST" is quite out  
pf place - that is BCP material.

{Actually, RFC 2119 does admit, in its usual woolly sort of way, that  
MUST/SHOULD/MAY might be interpreted differently in non-standard  
documents, so you might define those words as having a different  
interpretation in BCP sections.}
> what to do with mail they have received, which is not.

What it does (or should do) is to define, Normatively, what SSP signers  
can say. That seems to cover two areas:

    1. This is what we *do* (or do not do) when signing (or not) things.
    2. This is what we *advise* (or even "expect") verifiers to do with the  
information we provide.
> then stop.  That's all they need to interoperate.

But that is going too far. It covers my #1, but not my #2, which includes  
important stuff such as the 'strict' and 'deny' features.

And I am still happy to see BCP material which then, essentially,  
describes ways in which verifiers are "expected" to apply the "advice".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Tue, 04 Dec 2007 08:54:33 -0500

> from the Internet because others think it's not useful for them?

+1.  It really can't be that simple?  Could it?  I mean, why would I 
bother to the extremes of processing a DKIM header/body if the end 
result is indeterminate?  Its like getting a gun without bullets!

Mr. Levine is correct about one thing - SSP has been made overly complex 
to the point it is pretty a sure bet it is guaranteed to fail (not pass 
IETF certification).

In theory, there is two fundamental ideas here:

      - You sign, you expect me to check, you get judged!

      - if you don't sign, and you want me to check a policy
        and find that you were supposed too, you get judged!

But once you watered it down, then you begin to reduce the payoff and 
worth of the system. It becomes only beneficial in specialized 
operations with a high potential of abuse outside that specialization.

Oh..

PS: SSP does not dictate receiver behavior  :)

and the irony is that raw DKIM *does* dictate receive behavior!

The Receiver either processes DKIM or it doesn't.  But if it does, there 
is a militant inherent policy of "Ignore if Failure."  Forget that it 
was ever signed.

IMO, this inherent DKIM policy  defies logic and this makes SSP even 
harder to work out.  It is the #1 flaw of the system and in my book, 
possibly the ultimate consideration if DKIM will become widely adopted 
or not.  It policy, done to appease the mailing list people, will 
continue to be a thorn on DKIM's side until it is resolved or addressed 
by some means.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com

---

From: Hector Santos <[email-masked]>
Date: Tue, 04 Dec 2007 09:13:42 -0500

> continue to be a thorn on DKIM's side until it is resolved or addressed 

What that means, that SSP should of been designed to look at three DKIM 
possible results:

     1 - NOT SIGNED
     2 - SIGNED AND SUCCESSFUL
     3 - SIGNED BUT FAILURE

#1 and #3 are really not the same as DKIM wants it to be.  Although SSP 
is allowed to do a SSP check for #1 and #3, any final classifications 
performed are dependent on those two states, including any future 
desirable reporting system based on it.

      "Report: This message was never signed."
      "Report: This message was signed and successful"
      "Report: This message was signed but it failed to be validated."

DKIM "ignore if failure" simply makes everything more complicated for 
any augmented policy-based or reputation-based add-on technology.  That 
high potential realistic state simply can not be ignored.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: [email-masked] (Wietse Venema)
Date: Tue, 4 Dec 2007 10:12:25 -0500 (EST)

Perhaps an analogy from a different but familiar world will help.

Consider DKIM or SSP as broadcast radio transmissions (or TV if
you must). The point is that it is a UNIDIRECTIONAL thing.  The
sender doesn't know if anyone is receiving the signal, and they
certainly can't force anyone to listen (or watch their TV program).

Likewise, the sender of DKIM-enabled email doesn't know if the
receiver implements DKIM or SSP, and they certainly can't force
them to implement unenforceable statements that say "deny".

DKIM and SSP have no more "enforcement" power than broadcast radio.
You don't know who "receives" the signal and you certainy can't
force them to do anything with it.

With the DKIM and SSP broadcast model, you can define the format
of the signal and its meaning. That's all. If you want to control
the receiver and "deny" mail, then you need a fundamentally different
model.

	Wietse

---

From: "J D Falk" <[email-masked]>
Date: Tue, 4 Dec 2007 11:22:16 -0500

Charles Lindsey suggested:

> But that is going too far. It covers my #1, but not my #2, which
> includes important stuff such as the 'strict' and 'deny' features.
> 

A fine idea -- except, how do we list Best Current Practices when there
are no current practices yet?

--
J.D. Falk
Receiver Products
Return Path

---

From: "J D Falk" <[email-masked]>
Date: Tue, 4 Dec 2007 11:26:04 -0500

Wietse analogized:

> You don't know who "receives" the signal and you certainy can't force
> them to do anything with it.
> 
> With the DKIM and SSP broadcast model, you can define the format of
the
> signal and its meaning. That's all. If you want to control the
receiver
> and "deny" mail, then you need a fundamentally different model.

The same could be said about email today, yet there's an entire industry
built up around senders of email trying to convince receiving sites to
treat their messages in particular ways.  Senders of email /want/
certainty, and what we've seen so far is that they'll leap on even the
slightest hint that they're about to get it.  SSP will be no different.

On the other side, many potential implementors really really want to
know that they can reject all unsigned mail from a particular domain.
Seems to me that that's the important part here.  I'm not sure anything
else is going to matter.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Dec 2007 08:38:30 -0800

> overrides whatever reputation is associated with the message signer.

   This is hardly new. In fact, this train has long since left this
   station as it's in rfc5016:

5.3:

    2.  SSP MUST provide a concise linkage between the [RFC 2822].From and
        the identity in the DKIM i= tag, or its default if it is missing
        in the signature.  That is, SSP MUST precisely define the
        semantics of what qualifies as a first party signature.

          Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.

   I don't know why this is being brought up again after it was discussed
   and issue tracked for the requirements.

> reputation, what threats is SSP trying to protect against?

   SSP doesn't dictate outcome. Never has, never will.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 4 Dec 2007 08:50:17 -0800

On Dec 3, 2007, at 3:37 PM, Dave Crocker wrote:

> 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 desire here is to qualify the From header for transactional  
messages.

> 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.

A policy statement that can be applied more broadly, where benefits  
extend beyond just qualifying the From header, would suit more than  
transactional messages.  Adding Scope to policy could more broadly  
apply to all originating headers when handling "normal" messages.   
This policy could also clarify what is implied by use of the i=  
parameter.

The current use of the i= parameter is clumsy.  Matching the i=  
parameter precludes use of a g= restricted keys from signing Sender  
headers to spoof a From header.  The ALL or STRICT assertions must  
constrain the i= parameter to disqualify restricted keys not signing  
the From header.  Adding scope can eliminate these constraints.

Attempts at providing a minimal set of assertions has lead to this  
very sub-optimal policy mechanism this is only suitable for  
transactional messages.  Most domains use the full set of originating  
headers.  There is also a need to partition policy to suit how email  
is being used.  Who is signing is the place to establish such a  
partition.  Users SHOULD NOT see well-known domains use other domains  
to establish different policies.  Policy partitions can transparent by  
introducing Scope and a TPA-SSP label.  These two changes offer  
significant benefits.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Dec 2007 08:51:46 -0800

> change in the amount of query traffic -- that SSP causes.

   This has not changed in years. Maybe you've just become aware of it.
   And the problem here remains with unsigned traffic. Third party
   signatures are very rare beasts.

> number of years into the future.

   There is a trivial mechanism that can cut down SSP lookups to almost
   nothing: don't query domains from which you've never received a valid
   DKIM signature.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Dec 2007 08:55:07 -0800

> what to do with mail they have received, which is not.

   At this point, making sweeping condemnations is pointless. If you want
   something in the draft changed, suggest specifics. Better yet: use the
   ISSUE mechanism for which Eliot is still paying attention, I believe.

		Mike

---

From: Hector Santos <[email-masked]>
Date: Tue, 04 Dec 2007 12:11:46 -0500

J D Falk wrote:
 >> of the signal and its meaning. That's all. If you want to
 >> control the receiver and "deny" mail, then you need a
 >> fundamentally different model.

> Seems to me that that's the important part here.  I'm not sure anything

+1, thank you.

I just wish the note, it isn't the idea of rejection per se, but rather 
dissemination - i.e, getting a better handle of what is being received 
to assist in any classification process.

If receivers are expected to go to the expense and extremes of adding 
the overhead to watch and process DKIM messages, there must be a payoff, 
a reason to justify it all.  Conversely, the same is true for senders. 
If they are going into the expense and extremes of carefully signing 
their mail which now comes with some new ambiguous "responsibility" (not 
to be taken lightly) they too would want to have a payoff behind it all.

-- 
Sincerely

Hector Santos, CTO

---

From: John Levine <[email-masked]>
Date: 4 Dec 2007 17:32:13 -0000

>   nothing: don't query domains from which you've never received a valid

My network gets tons of fake mail from HSBC UK and no real mail from
them since none of my North American users have an account there.  How
would I be able to tell that it should have been signed?

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Dec 2007 09:49:02 -0800

> would I be able to tell that it should have been signed?

   If nobody cares about HSBC UK, why should you?

   In any case, this strikes me as a tempest in a well stirred teapot.
   The load on DNS is similar to SPF/SIDF and the world has continued its
   normal rotation.

		Mike

---

From: Hector Santos <[email-masked]>
Date: Tue, 04 Dec 2007 12:47:28 -0500

> the receiver and "deny" mail, then you need a fundamentally different

Yes Wietse.

Thank you for highlighting the simple broadcaster/receiver model. It was 
very appropiate.

If I may fine tune (excuse the TV pun) the model....

The new "technology" added to the electronic broadcast are with the new 
XYZ (DKIM) markings in the bit, byte or packet streams (analog or digital).

Only new compliant receiver boxes are capable of deciphering or making 
any use of the XYZ markings in the stream or piggybacking on the stream.

Now, what is the purpose of the new XYZ markings in the broadcast 
signals?

That depends on who is doing it and way:

  - Is this an Information based marking?
  - Is this a new control-based marking?

If we step aside a second using a real model, the TV satellite and cable 
industry also faced both design questions.

   - Informational - improved receivers gives you fancier menu, it
                     addressed the ergonomics of the user experience.

   - Controls - improved receivers allow the vendors to leverage new
                subscription models, including helping them to secure
                against pirating. This migh also include logic that
                leverages new BI-DIRECTIONAL communications hardware.

So who will want this?

Well, the vendors (senders) will be tickled pink if they can get 
everyone to purchase or license a new receiver box.  That way the vendor 
profit margins are improved in the name of improving the quality of the 
user experience/service. New feedback information will help in direct 
marketing ideas.

How about users?

Well, I will venture to say only the users who don't want the additional 
controls will be those with illegal subscriptions. So they will stay 
away from any new receiver boxes if they don't have to.  But they might 
desire the neat new GUI boxes because it now allows them to do all kinds 
of other stuff, i.e. PVR.  Vendors know the power of marketing, so they 
will entire these users and also migh offer some amnesty (Upgrade) program.

So yes, indeed, the model is very appropriate for DKIM.

However, the differences are these:

The new XYZ/DKIM markings is a standard and not proprietary.  That means 
other broadcasting vendors, including broadcasting sniffing pirates can 
do the same thing and might be able to use to this to exploit 
"something" about this new XYY/DKIM markings and know logic it is know 
to allow or offer.

So how we resolve this?

Policy and authorization (SSP) concepts.

Within the XYZ/DKIM broadcasting markings is a FEEDBACK bit that tells 
the receiver how/where to double check the originality of the XYZ 
packet.  This will require a BI-DIRECTIONAL concept and usually it back 
to the original holder.

Now my new receiver box is getting true signals from the vendor I am 
paying money too and I don't have to worry about getting fraudulent 
broadcasting that might try to do something harmful to my system or my 
interrupt my watching (reading) entertainment.  I will get silly marque 
messages on the TV screen trying to sell me something.

Here's the irony:

       Everyone is doing this in the telecommunications world
       including broadcasting, DSL, Cable, Mobil market with
       new bi-directional feedback capabilities now possible.

Its about time we catch up with it in the EMAIL world too.

-- 
Sincerely

Hector Santos, CTO

---

From: Jim Fenton <[email-masked]>
Date: Tue, 04 Dec 2007 10:10:37 -0800

Charles Lindsey wrote:
> But it has no business whatsoever making normative statements about
> what verifiers are to do, so wording of the form "Verifiers MUST" is
> quite out pf place - that is BCP material.

Somehow, we need to tell verifiers what they need to do in order to
implement this specification.  Nobody is saying that verifiers MUST
implement SSP at all, but rather that if they want to implement SSP,
this is how they MUST do it.  Of course, verifiers are free to implement
some other SSP-like thing, even one that acts on SSP records, but I feel
we need to provide some precision in the thing we're calling SSP.

-Jim

---

From: "J D Falk" <[email-masked]>
Date: Tue, 4 Dec 2007 13:23:38 -0500

>        new bi-directional feedback capabilities now possible.

But, they're not doing it with an infinite number of senders and an
infinite number of receivers.

---

From: Hector Santos <[email-masked]>
Date: Tue, 04 Dec 2007 13:34:17 -0500

Wietse,

One other thing about the different, DKIM is not really a "ECHO/PUBLIC" 
concept. Its more direct mail with a complexity of mailing list as well.

Its funny that you bring this up.  I don't know if others remember 
Planet Connect (http://www.planetc.com) but in the early 90s' it was one 
the first commercially viable satellite based broadcasting "Mail and 
File" distribution systems. It was one the first ways before PPP 
connectivity was broadly viable to offer high bandwidth distribution of 
both internet and fidonet data.

It broadcasted:

     Usenet newgroups
     Fidonet Echo Mail (MAIL BONE)
     Fidonet Echo File (FILE BONE)

I can't recall the subscription model, but its receiver box including 
some "key" concept that control the subscription process and what data 
is dechipered.  If I recall, it was only unidirectional as with all 
early satellite broadcasting system and who used a phone line for any 
feedback requirement.

At the user end, typically a Mail Hub with its own subscribers using 
UUCP/SLIP or FTP or FIDONET, it only collected the data of group 
interest, discarding the rest.  If a member subscribed to a newsgroup or 
fido echo, it included the item for the collection.

Now, it could it been used to send direct mail? or a mailing list 
broadcast using a DKIM data encryption system?

Well, on the creation side. I will need an outbound wire (SMTP) to the 
PC site who would broadcast it.  As part of the broadcast, it could 
encrypt the email with the subscriber PC key.

Putting aside security issues, it is theoretically possible for my 
receiver box will see this email packets and will automatically decrypt 
only those DKIM emails belonging only to this box.

In this case, the PC service will do all the DKIM validation and SSP 
checking before the PC subscriber encryption and broadcast takes place.

Of cause today, the encryption part is not required because the ISP site 
(SMTP receivers) will direct/hold mail for MUA subscriber pick up.  No 
broadcasting concept.

The SMTP receivers can do the DKIM/SSP checking and the end-users don't 
have to worry about it.

--
HLS

Hector Santos wrote:
> Now, what is the purpose of the new XYZ markings in the broadcast signals?
> 

-- 
Sincerely

Hector Santos, CTO

---

From: [email-masked] (Wietse Venema)
Date: Tue, 4 Dec 2007 13:30:27 -0500 (EST)

Hector Santos:
[ Charset ISO-8859-1 unsupported, converting... ]
> Thank you for highlighting the simple broadcaster/receiver model. It was 

By the way, I neglected to clarify my remark about fundamentally
different model, so I will take the opportunity to correct that.

Current email is primarily push technology. The problem therefore
is authenticating the pusher.

A fundamentally different model would be pull-based.  For example,
to receive mail from my bank, I would pull it from their website.
I wouldn't have to worry if the mail is spoofed (it came from the
bank's website, I have their DNS name and SSL cert), and the bank
could easily claim that all other mail in their name is a forgery.

Note that pull-based email technology is immune to the problems of
forwarding, mailing list munging and third-party signatures.

One implementation is for the bank to send a tiny email message
with just a token, plus a plain old URL for legacy mail clients.
As in early MIME days, legacy clients show ugly stuff to the user.
Smart MTAs (or MUAs) would handle the download step transparently.

There's nothing revolutionary in this. It's just basic application
of a different email distribution model. In fact, that model can
be built on top of the existing one.

	Wietse

---

From: John L <[email-masked]>
Date: Tue, 4 Dec 2007 13:47:44 -0500 (EST)

>  If nobody cares about HSBC UK, why should you?

Uh, because SSP is supposed to be able to help me tell that it's a phish?

I can't believe you're saying that I should just deliver phishes if I 
don't think anyone's likely to fall for them, but it's hard to assign a 
different meaning to your question.

As it happens, lots of people around here have HSBC US accounts, the two 
banks' branding is nearly identical, and it's not absurd to worry that if 
someone put HSBC US account info into the HSBC UK phish, the bad guys 
would be able to make use of it.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Tue, 04 Dec 2007 10:55:30 -0800

>   ISSUE mechanism for which Eliot is still paying attention, I believe.

Indeed I am.  All you need to do to create an issue is to send a note to
this list with the subject "NEW ISSUE" and I will track it.

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Tue, 4 Dec 2007 11:00:00 -0800

On Dec 4, 2007, at 9:49 AM, Michael Thomas wrote:

> John Levine wrote:
>>> There is a trivial mechanism that can cut down SSP lookups to  
>>> almost nothing: don't query domains from which you've never  
>>> received a valid  DKIM signature.
>>
>> My network gets tons of fake mail from HSBC UK and no real mail  
>> from them since none of my North American users have an account  
>> there.  How would I be able to tell that it should have been signed?
>

While clearly not a homogeneous world, a great many our customers care.

> The load on DNS is similar to SPF/SIDF and the world has continued  
> its  normal rotation.

A single SSP record should have equal, and often significantly less  
overhead than SPF/SIDF (as typically used).  An SSP transaction would  
be several orders of magnitude less than exploited macro expansions of  
SPF records.  :^(

That said, DKIM itself introduces a significant resource overhead.  A  
well-known domain would be able to vouch for unknown domains when TPA- 
SSP is used.  Conversely, TPA-SSP records also permit a common signing  
domain to be authorized by thousands of less well-known domains.  This  
ability might be important when DKIM signatures are selectively  
evaluated, due to just DKIM's base overhead.

Many systems are currently overwhelmed by abuse.  Eyes may roll when  
suggesting addition of a resource intensive DKIM process.  It is very  
likely resources needed for DKIM will be used selectively.  There must  
be a bang for the buck.  Those who ferret out phish may not understand  
every corner of world.  The current SSP policy statement can help  
train how these filters should operate, without being checked when  
every message is received.  Anti-phishing often needs to examine  
content look and feel, where SSP policy assertion might help prevent  
some false positives.  On its own, even when expressed as Strict, this  
SSP policy will not prevent phishing.  Strict policy can raise the  
bar, but without TPA-SSP, this Strict policy will likely create an  
unfortunate proliferation of email-addresses using some sub-domain of  
the otherwise well-known domain.  A profusion of domain names will  
create more confusion for the average user and likely making them more  
prone.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Dec 2007 11:04:42 -0800

John L wrote:
> banks' branding is nearly identical, and it's not absurd to worry that 
> if someone put HSBC US account info into the HSBC UK phish, the bad guys 

   This assumes that SSP tries to solve the lookalike domain problem.
   It doesn't.

		Mike

---

From: Hector Santos <[email-masked]>
Date: Tue, 04 Dec 2007 14:04:32 -0500

Yes, is this true.

In this case, the Source (Your bank) is the originator and that is all 
you need to worry about as to *whom* is the mail server (bank) and who 
is the mail receiver (you).

But in the general sense, an "ISP" who is also "ESP" these days, so he 
can offer:

    - SMTP routing services (for downlink host, business accounts)
    - POP3 pickup service (for user accounts)
    - WEB Mail Server (for user accounts)

The ISP/ESP can do the DKIM/SSP for the user accounts, and it MAY do the 
same for the hosting accounts. But also offer a passthru service for the 
hosting accounts, with the idea the hosting accounts will do the final 
DKIM/SSP processing.

So you need to look at the DKIM/SSP service features that an SMTP vendor 
may offer in her product for ISP/ESP to use these to offer/sell these 
services or a typical host will use.

--
HLS

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Tue, 4 Dec 2007 11:15:07 -0800

> be built on top of the existing one.

Agreed.

Here is a draft aimed at doing just that.  IPR issues might require  
this to model BURL's IMAP rather than HTTP.

http://www.ietf.org/internet-drafts/draft-otis-smtp-tbr-ext-00.txt

This could help deal with possible replay abuse where obligations for  
delivery can be postponed. DKIM signed messages still offer recipients  
somewhat transitory evidence to a third-party who originated the  
message.  (Within the realm often needed to report an immediate  
problem)  S/MIME would be less transitory of course.

-Doug

---

From: John L <[email-masked]>
Date: Tue, 4 Dec 2007 14:21:53 -0500 (EST)

>  This assumes that SSP tries to solve the lookalike domain problem.

Can we review the last couple of messages, please?

You said that a way to avoid making useless SSP lookups was only look up a 
domain if you've previously seen a signed message from it.

I said, I get a bunch of messages purporting to be from a bank I've never 
seen before.  This isn't lookalike, this uses the actual domain (in this 
case hsbc.co.uk) but since I've never seen any mail from them before, good 
or bad, I won't do the lookup and I'll never know that their SSP says they 
sign all their mail.

You then said well, if it's not a bank your users use, why do you care? 
I still have trouble reading that as other than deliver the phish if you 
don't think your users will be fooled.

How exactly is your heuristic supposed to work?

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Dec 2007 11:34:01 -0800

John L wrote:
> You said that a way to avoid making useless SSP lookups was only look up 
> a domain if you've previously seen a signed message from it.
> 
> I said, I get a bunch of messages purporting to be from a bank I've 
> never seen before.  This isn't lookalike, this uses the actual domain 
> (in this case hsbc.co.uk) but since I've never seen any mail from them 
> before, good or bad, I won't do the lookup and I'll never know that 
> their SSP says they sign all their mail.

   You said:

   hsbc.co.uk != hsbc.com. That they have layer 8+ ties to one another
   is not a problem SSP is trying to solve.

		Mike

---

From: John L <[email-masked]>
Date: Tue, 4 Dec 2007 14:38:38 -0500 (EST)

>  is not a problem SSP is trying to solve.

Right.  So forget that digression.

>> or bad, I won't do the lookup and I'll never know that their SSP says they 

Apparently, detecting forgery of exact domain names isn't a problem that 
SSP is trying to solve either, unless you already happen to know that the 
domain signs their mail.

I get a bunch of mail purporting to be from some bank.  You said that 
since I've never seen any signed mail from them, don't bother to look up 
their SSP.  Huh?

R's,
John

---

From: Eric Allman <[email-masked]>
Date: Tue, 04 Dec 2007 12:19:40 -0800

I'm going to reply to this message twice.  This is a short note, but 
given the size of your critique and the fact that we got less than 24 
hours to look at it before the meeting, I'm planning on doing a more 
detailed reply later.

Briefly, please consider Patrick Peterson's response dated 12/4 
02:18:51 AM to be included here.  I agree with the gist of everything 
he and other people such as Scott and Wietse have to say.

* Several places you compare this version (unfavorably) to "the 
original SSP specification".  Which one would that be?  There was 
_policy in DK, and some stuff in draft-allman-dkim-base that got 
pulled out, but I don't recall anything that got further than a very 
rough draft.

* You obviously dislike the way SSP handles multiple From field 
addresses, and yet you offer no alternative.  I don't like it either, 
but just complaining isn't constructive.  I will point out that using 
Sender: was considered and rejected, so unless we want to reexamine 
that, that's not the answer either.

* I agree with the folks who say that "Suspicious" is simply a 
defined term in this document, and (as in any contract) it doesn't 
necessarily carry the connotative baggage of broader language.  None 
the less I'm not wedded to that word; we can call it "Orange" if we 
want.

* Several places you refer to reputation.  But if I recall correctly 
we explicitly avoided using that word, at least in part because it's 
only one of a number of mechanisms.  Making an assumption that SSP 
will be backed up by reputation dramatically expands the scope of the 
document in a way that doesn't seem productive.

* You seem to think that doing SSP lookups on third-party signatures 
will increase traffic dramatically.  I don't think that's at all 
clear.  By far the majority of the SSP traffic in the short run will 
be for messages that have no signature at all.  In the longer run it 
comes down to what percentage of email traffic is one-to-some (i.e., 
a first-party signature) vs. how much goes through mailing lists or 
other cases that would have third-party signatures.  Of course, the 
majority of email will be spam/phishes, and that's a bit harder to 
predict since they change so fast, but my first guess is that most of 
it will be unsigned and hence require an SSP lookup anyway.

* You suggest moving _ssp out of the _domainkey subdomain.  However, 
I think it's worthwhile having it there in the event that the 
_domainkey subdomain is delegated.  It seems logical to keep 
everything together.

* You seem to think that declaring messages that come from domains 
that are not accessible (i.e., a reply would fail with NXDOMAIN) 
"make(s) it clear that SSP has moved seriously into more general 
aspects of receive-side analysis."  However, this step is required to 
make the algorithm work; without it there is an obvious security 
hole.  However, I do agree that a flowchart would help.  I think I 
have a fairly current around somewhere already, but it's not in ASCII.

OK, that's it for comments for now.  And really, this /is/ the short 
version.

eric

---

From: Hector Santos <[email-masked]>
Date: Tue, 04 Dec 2007 16:48:38 -0500

Eric Allman responding to Dave's Review:

> * Several places you compare this version (unfavorably) to "the original 
> SSP specification".  Which one would that be?  There was _policy in DK, 
> and some stuff in draft-allman-dkim-base that got pulled out, but I 
> don't recall anything that got further than a very rough draft.

Personally, I thought the original "draft" was very clear and concise. 
It simply lacked the 3rd party issues.

> * Several places you refer to reputation.  But if I recall correctly we 
> explicitly avoided using that word, at least in part because it's only 
> one of a number of mechanisms.  Making an assumption that SSP will be 
> backed up by reputation dramatically expands the scope of the document 
> in a way that doesn't seem productive.

+1

> will increase traffic dramatically.  I don't think that's at all clear.  
> By far the majority of the SSP traffic in the short run will be for 
> messages that have no signature at all.  In the longer run it comes down 
> to what percentage of email traffic is one-to-some (i.e., a first-party 
> signature) vs. how much goes through mailing lists or other cases that 
> would have third-party signatures.  Of course, the majority of email 
> will be spam/phishes, and that's a bit harder to predict since they 
> change so fast, but my first guess is that most of it will be unsigned 
> and hence require an SSP lookup anyway.

+1,

There is a double edge sword here and I think it all depends on the type 
of policy domains begin or leans towards using, which is why I had an 
"itch" with the "SSP only required if no signature" and "Ignore if 
Failure" concept.

The logical and reasonable premise is:

    Short Run --> More SSP lookups
    Long Run  --> Less SSP Lookups

The long run will include a higher rate of fraud, especially if there is 
relaxed policies which is the default, hence, most likely the long run 
will include more or equal me amount unsigned fraud attempts. IOW, the 
bad guy does not have to adapt to anything related to DKIM or relaxed 
policies.

The more stronger policies exist, theoritcally we will get less fraud. 
However, two things might occur with the bad: a) Since there are more 
stronger policies, all he needs to do is create a fake signature. It 
doesn't have to be correct, and b) begin to target non-supportive 
DKIM/SSP systems.

Therefore, IMO, there might be a tendency to do an SSP first in all 
cases (of course, the better system will cache this) to address the long 
run potential of higher fraud.

IOW, short or long run, if the majority are relaxed policies, the bad 
guy doesn't had to anything. He doesn't need to adapt.  We only begin to 
see a shift, a change in pattern as the policies become stronger.

> * You seem to think that declaring messages that come from domains that 
> are not accessible (i.e., a reply would fail with NXDOMAIN) "make(s) it 
> clear that SSP has moved seriously into more general aspects of 
> receive-side analysis."  However, this step is required to make the 
> algorithm work; without it there is an obvious security hole.  However, 
> I do agree that a flowchart would help.  I think I have a fairly current 
> around somewhere already, but it's not in ASCII.

+1, the same applies to DKIM in the long run.  The more DKIM signatures, 
the more potential for NXDOMAIN key lookups.

This is partly why an upfront SSP lookup can assist in the process.

The whole theory of DKIM success is based on the premise that in the 
long run, it will be standard practice to have DKIM "VALID" signatures 
in the majority of messages.

The theory breaks down when the long run includes a signficant amount of 
invalid signatures.

So SSP or no SSP, there will be a drastic overhead problem in HASH 
computation.

In my view, the optimization will make it prudent that:

    - SSP is lookup first, and
    - we have stronger policies.

The only argument against SSP being looked first, is when we have 
network wide design assumption of:

       invalid signatures <<<<< valid signatures.

But what if the long run shows?

       invalid signatures > valid signatures.

-- 
Sincerely

Hector Santos, CTO

---

From: Dave Crocker <[email-masked]>
Date: Tue, 04 Dec 2007 14:12:36 -0800

Michael Thomas wrote:
>> 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.
> 
> This has not changed in years. Maybe you've just become aware of it. And
> the problem here remains with unsigned traffic. Third party signatures are
> very rare beasts.

The requirement to have i= match From domain was added between the -02 and -03 
versions, sometime during Fall 06 and Winter 07.

On reviewing the working group archive, I have not succeeded in finding any 
discussion either of changing the SSP paradigm to apply to signed message or 
of the problematic selection of the rfc2822.From field, rather than 
rfc2822.Sender field domain.

I recall making a point a number of times in the working group, verifying that 
the group agreed that SSP applied (only) to unsigned messages.

>> 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.
> 
> nothing: don't query domains from which you've never received a valid DKIM
> signature.

You are suggesting that a problematic design which imposes undue overhead is 
remedied by a hack that has no long-term experience?

(By contrast, a design that relies on caching would be using a well-understood 
and accepted mechanism which is accepted as altering query dynamics reliably, 
though not perfectly.)

d/			
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Dec 2007 14:18:44 -0800

Dave Crocker wrote:
> The requirement to have i= match From domain was added between the -02 
> and -03 versions, sometime during Fall 06 and Winter 07.
> 
> On reviewing the working group archive, I have not succeeded in finding 
> any discussion either of changing the SSP paradigm to apply to signed 
> message or of the problematic selection of the rfc2822.From field, 
> rather than rfc2822.Sender field domain.
> 
> I recall making a point a number of times in the working group, 
> verifying that the group agreed that SSP applied (only) to unsigned 
> messages.

RFC 5016, section 5.3 requirement #1:

  1.  SSP MUST be able to make practices and expectation assertions
        about the domain part of a [RFC 2822].From address in the context
        of DKIM.  SSP will not make assertions about other addresses for
        DKIM at this time.

I just checked and this requirement has been in the requirements since
the very first draft. If you objected, it apparently didn't get much
consensus.

> (By contrast, a design that relies on caching would be using a 
> well-understood and accepted mechanism which is accepted as altering 
> query dynamics reliably, though not perfectly.)

The current SSP draft does make use of DNS caching, and it doesn't
seem to be any more onerous than SPF/SIDF -- probably less. We've
been running it for a year and a half and haven't noticed anything
even remotely alarming about it.

		Mike

---

From: Jim Fenton <[email-masked]>
Date: Tue, 04 Dec 2007 14:29:12 -0800

Dave Crocker wrote:
>>> messages
> On reviewing the working group archive, I have not succeeded in
> finding any discussion either of changing the SSP paradigm to apply to
> signed message or of the problematic selection of the rfc2822.From
> field, rather than rfc2822.Sender field domain.
>

>From draft-allman-dkim-ssp-00.txt, dated July 9, 2005, section 1
paragraph 3:

   In the absence of a valid DKIM signature on behalf of the "From"
   address [RFC2822], the verifier of a message MUST determine whether
   messages from a particular sender are expected to be signed, and what
   signatures are acceptable.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Tue, 04 Dec 2007 15:26:40 -0800

Michael Thomas wrote:
>> message or of the problematic selection of the rfc2822.From field, rather
>> than rfc2822.Sender field domain.
>> 
>> I recall making a point a number of times in the working group, verifying
>> that the group agreed that SSP applied (only) to unsigned messages.
> 
> 
> 1.  SSP MUST be able to make practices and expectation assertions about the
> domain part of a [RFC 2822].From address in the context of DKIM.  SSP will
> not make assertions about other addresses for DKIM at this time.
> 
> I just checked and this requirement has been in the requirements since the
> very first draft. If you objected, it apparently didn't get much consensus.

That relates to using .From.  How does it related to the application of SSP 
for signed messages, and where is the indication that this implication was 
understood by the community?

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 04 Dec 2007 15:30:27 -0800

Jim Fenton wrote:
> In the absence of a valid DKIM signature on behalf of the "From" address
> [RFC2822], the verifier of a message MUST determine whether messages from a
> particular sender are expected to be signed, and what signatures are
> acceptable.

What's proving interesting is how completely the implication of this seems to 
have been missed by quite a few participants.

I'l continue to repeat that I haven't found the working group discussion of 
this implication.

d/

-- 

   Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 04 Dec 2007 17:45:47 -0600

Hi!

I'm sure others will make more intelligent comments but I have a few 
that I'd like to offer.

First, text in the SSP draft states repeatedly that receivers are free 
to dispose of their messages as they see fit so I think that certain and 
frequent comments in the Review to the contrary are incorrect.

> In general, the draft needs to consider adoption incentives for 
> receivers.  

SSP offers itself as a means to detect unauthorized domain use.  That is 
sufficient incentive for adoption by 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 --

I don't know what you consider "the more advanced features" but I can 
speak with some authority for small receivers and they would welcome the 
unauthorized domain use detection capability which SSP provides.

> 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.

No, no.  Let's resist this urge.  The "smallest set of features that are 
deemed useful" etc are what many believe the existing draft already is - 
so there's nothing to split out.

 > the protocol is not constrained to "interpret" with respect to defining
> what the published information means, but rather is meant to guide, or even

There are several statements within the document to the contrary.  How 
do you reconcile those with your assertion above?

> administrative and information models from the self-published directive 
> nature of SSP.

You're speaking here of BL's and SPF.  The existence and ubiquitous use 
of which is absolute proof of at least three things:  1. the idea of 
offering input into receive side filters is not unprecedented  2. the 
network infrastructure is very robust with respect to queries 3. the 
world has embraced the concept of DNS-based input into the message 
decision making matrix.  Those are precisely the criterion upon which we 
can reliably presume the mechanical and adoptive success of SSP.

> The original SSP specification applied only to unsigned messages. 

Not sure what you mean by "original SSP specification" but you state 
this more than once in your Review.  I believe this to be errant but 
it's not interesting.  Whatever changes may have occurred were 
accomplished through the WG process and so were not done in secret.

> 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?

Perhaps it is sufficient and when it is, there are some steps in the SSP 
algorithm (all steps after step 1) which are a waste of time/resources. 
  I've struggled with this myself and am not altogether satisfied.  An 
easy optimization would be to add "Verifier Acceptable Third-Party 
Signatures (VATPS)" to the text of step 1. But, I don't think this 
problem amounts to the receiver being "told what to do" by the domain 
owner.  In other words, SSP's requirement that the algorithm in 4.4 
continue beyond step 1 even when a VATPS is detected early is an 
inefficiency in the algorithm.  If a receiver knows that they are always 
going to accept messages with a VATPS, then queries to determine whether 
the policy of the From domain agrees with this practice are pointless. 
Now, Jim will have something to say to clarify this issue further I'm 
sure (hoping) :)

> 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.

What is the significance of this observation?  The DNS infrastructure 
has proven to be very robust and there are routinely now a half-dozen or 
more queries performed on each and every message received these days. 
If the DNS infrastructure is incapable of scaling for one more query per 
  message then I suggest we've got much bigger problems to be working on 
than this WG is tasked with.  Is there something especially negative 
about a failed query that I don't understand?

> 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.

I see absolutely no basis for such a belief.  Please explain.  Please 
define both "content" and "valid".

 > 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.

What are these assumptions?

Arvel

---

From: Steve Atkins <[email-masked]>
Date: Tue, 4 Dec 2007 16:43:08 -0800

On Dec 4, 2007, at 3:45 PM, Arvel Hathcock wrote:

> Hi!
>
> I'm sure others will make more intelligent comments but I have a  
> few that I'd like to offer.
>
> First, text in the SSP draft states repeatedly that receivers are  
> free to dispose of their messages as they see fit so I think that  
> certain and frequent comments in the Review to the contrary are  
> incorrect.
>
> SSP offers itself as a means to detect unauthorized domain use.   
> That is sufficient incentive for adoption by receivers.

It doesn't provide a reliable means to detect unauthorized domain  
use. That alone is sufficient reason for receivers (and many senders)  
to be skeptical about deployment.

How unreliable it is we don't know yet, but until we have more  
operation experience with DKIM it's reasonable to assume the worst.

If it starts being deployed and we discover that the SSP false- 
positive rate is too high we'll lose a huge amount of time rolling  
back deployment of SSPv1 and working on a more realistic SSPv2.

The SSP false-positive rate will be driven primarily by the DKIM  
false-negative rate. As that's a critical piece of data needed to  
complete the SSP design to a level of quality suitable for widespread  
deployment the wisest course of action would seem to be to wait until  
we have wider DKIM deployment and more DKIM operational experience,  
and then to gather that data.

(In parallel with gathering that data we could also take more time to  
deal with some of the other issues with SSP semantics in a broader  
forum, with more input from from real-world senders and receivers,  
rather than the small subset currently looking at it).

Cheers,
   Steve

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Dec 2007 19:20:58 -0500

>have been missed by quite a few participants.
I seem to have missed the discussion where anyone but you is suprised by 
this.  If one is going to distinguish between originator signatures and 
others, then this requirement pretty obviously follows.

Scott K

---

From: "Patrick Peterson" <[email-masked]>
Date: Tue, 4 Dec 2007 17:53:58 -0800

> to be skeptical about deployment.
Myself and many others believe it offers a means to detect unauthorized
domain use that justifies its use. I believe it is reliable "enough" but
of course it's not 100% reliable.

We disagree on this point but this isn't a problem at all as we can both
have our way with SSP:
- I encourage and support skeptics like yourself to avoid use of
strict/deny policies and to disregard the use of strict/deny policies.
- I encourage those agreeing with Arvel, myself and many others to use
strict/deny policies as appropriate as a means to detect unauthorized
domain use.

Everyone can make their own decision about the applicability and utility
of this technique and vote with their SSP policies.

Take strict/deny policies away from your mail stream but please don't
take strict/deny away from proponents' mail stream because you don't
think it's reliable enough. 

> operation experience with DKIM it's reasonable to assume the worst.
* see comment below
 
> back deployment of SSPv1 and working on a more realistic SSPv2.
No. If someone chooses a strict/deny policy and it has a high
false-positive rate receivers can simply ignore it as you are planning
to do. If someone deploys strict/deny and finds it has a high
false-positive rate they can change to unknown/process.

A change in SSP policy is all that's necessary, not a new SSPv2.
 
> and then to gather that data.
* taken together with unreliable comment above...
Yahoo and PayPal have done the largest scale implementation of a
back-channel strict/deny for DK. PayPal spoke at MAAWG on their success
and said he had business benefit. The false positives would be much
lower with DKIM than with DK.

Other banks have deployed DKIM and found the FP rate to be acceptable to
them based on their criteria.

I believe the DKIM interoperability summit is the largest test of this
kind and results were encouraging. There was no official pronouncement
or false positive measurement but I believe the results didn't leave
anyone to believe driving the FP rate to an acceptable level was not
possible in the near future.

Here's the closest thing I found to a DKIM reliability pronouncement:
http://dkim.org/news/DKIM%20Interop%20Event%20PR%2011_06_07.htm
"We have demonstrated that DKIM is easy to add to an email service and
that its use of cryptographic technology provides a strong basis for
knowing received email really is associated with the organization that
claims to have sent it." - Dave Crocker (quote excerpt)
"We learned a lot by participating; not the least of which is that DKIM
just works," said Arvel Hathcock, Founder and CEO of Alt-N Technologies,
and host of the event. "The testing performed by all participants
revealed no significant barriers to adoption or use."

http://altnblogs.com/arvel/
Finally, I was struck by just how well this DKIM stuff actually does
work. It really does deliver as advertised and we found no significant
technological problems which would hinder adoption or deployment.

If you have better data on DKIM reliability please share.

Of course if you think it's unreliable then publish unknown/process for
mail you send and ignore SSP for mail you receive.

pat

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Dec 2007 18:12:11 -0800

> others, then this requirement pretty obviously follows.

+1, and I had the dubious distinction of having to go through the
thousands of mail messages. I can't imagine that there is anything
new under the sun on this topic.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 4 Dec 2007 19:42:50 -0800

On Dec 4, 2007, at 4:43 PM, Steve Atkins wrote:

> complete the SSP design to a level of quality suitable for  
> widespread deployment the wisest course of action would seem to be  
> to wait until we have wider DKIM deployment and more DKIM  
> operational experience, and then to gather that data.

Any domain asserting All or Strict will also likely cause false- 
positives when their domain signs for headers other than the From but  
the From also contains their domain.  A domain dedicated to  
transactional messages could ensure other headers are not signed  
(perhaps by deprecating i= parameter use to make all signatures  
ambiguous within the domain).  This domain could also ensure only  
trustworthy entities hold their private keys.  One wonders whether  
keys should have had a scope assertion to constrain which headers are  
qualified to be signed.  The header scope assertion could be placed  
within SSP with a negligible increase in overhead.  As it is now, SSP  
will be checked in the case where the From header is not signed.  An  
SSP scope could indicate whether an exception should be made.

If a key is restricted with g=, a signature for anything other than  
the From could be noted and serve as a filtering input.  It seems  
doubtful, in the general case, rejecting or placing these messages  
into a junk folder will be the best choice.  As it is now, poor  
treatment of these messages is likely become common.  This issue may  
also prevent domain's wishing to assure recipients, to be unable to  
consistently use the i= parameter. :^(

A key or SSP scope policy could indicate only From headers are valid,  
and applied as a follow-on solution when ignoring i= parameters prove  
problematic.  Being generous in what is accepted for valid signatures  
from the From domain seems like the best solution.

John Levine's suggestion of using i= identities as opaque identities  
is very attractive, but this also prevents a domain of ever indicating  
they sign everything when the definition of signed MUST include  
matches with the i= parameter.  Perhaps there should be a draft  
created to offer a u= extension to hold opaque identifiers.  This  
would offer a consistent signed location where the domain and  
identifier are assured to be related.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 05 Dec 2007 12:54:41 -0000

> are no current practices yet?

The particular practices I have in mind are those already in the draft,  
but currently confusingly described by the use of 2119-like MUSTard.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 05 Dec 2007 13:07:56 -0000

> we need to provide some precision in the thing we're calling SSP.

Then do not use "MUST" language when speaking of verifiers. Or,  
alternatively, include wording of the form:

"This document describes processes for what verifiers are expected to do  
in order to achieve what the signers intend.

But these descriptions are not Normative since there is no compulsion on  
verifiers to follow those processes exactly as described, or even at all.  
Therefore, use of the terms "MUST" and "SHOULD" in these descriptions  
merely indicate the steps verifiers need to take if they want to claim  
adherence to the particular set of processes described here."

That essentially modifies the interpretations given in RFC 2119 (and 2119  
already implies that such modifications are appropriate in non-normative  
contexts).

There may be better ways to express all this.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 5 Dec 2007 08:35:31 -0500

> There may be better ways to express all this.

How would doing this work change what verifiers do after the RFC is deployed?

Scott K

---

From: John Levine <[email-masked]>
Date: 5 Dec 2007 13:53:54 -0000

>How would doing this work change what verifiers do after the RFC is deployed?

Probably not much, but it will help rein in unwarranted expectations
by senders that publishing SSP will affect what happens to their mail.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 5 Dec 2007 09:18:09 -0500

> by senders that publishing SSP will affect what happens to their mail.
It sounds like a lot of work to say the same thing to me.  I don't think 
increasing the quantity and type of ways that the draft says it doesn't 
mandate what receivers will do is a value added use of anyone's time.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Wed, 05 Dec 2007 10:46:13 -0800

[Who is apps-review, and why are they rejecting messages? If this is
  intended as an apps area review where only Dave gets to post, that's
  a problem.]

> to attempting to emulate  SPF strictures of correlation among identity 

   If SSP is going to have any utility whatsoever, it cannot be defeated
   by the mere act of signing a message from any random domain. Period.
   That would be completely and utterly useless, and a complete joke to
   create such a specification. When a domain says that it signs all of
   its mail, it means just that. It doesn't mean that maybe on every
   third thursday that some other domain might sign the mail. It means
   that the domain in question signs its own mail with its own
   signatures. That means that you have to know which domain a piece of
   mail is purporting to be from. The address chosen in the requirements
   in RFC5016 is the rfc2822.From address. This was not controversial.
   Why we're rehash that non-argument now is beyond me.

 > Question:  Is DKIM for transit validation or is it for content

   This is a false dilemma.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Dec 2007 11:08:34 -0800

Mike,

Michael Thomas wrote:
> intended as an apps area review where only Dave gets to post, that's a 
> problem.]

Apps review is an existing mechanism.  I participate in it.  Others
participate in it.  I used it exactly the same way I have used it for previous
reviews I have done, except cc'ing the wg rather than the authors.  I didn't
create the mechanism.  I used it specifically because it is an established
capability.

That said, I think the list I posted to is used to record the review, rather
than for on-going discussion, so I have removed it from the cc list.

If you dislike the mechanism, feel free to direct comments about it to the
Apps area directors.

>> 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.
> 
> If SSP is going to have any utility whatsoever, it cannot be defeated by 
> the mere act of signing a message from any random domain.

There is quite a lot implied by saying "defeated".

Perhaps you could explain the operational, threat and protection models that
substantiates your assessment.  I am pretty sure it has not been clearly
documented.  It seems pretty clear to me that the models require a homogeneous
and reliable end-to-end service, with considerable cooperation among all
senders and receivers, with no signature breakage.

In any event, it is worth commenting on the reasons that the reputation of the
random domain that does sign are rendered irrelevant.  (I asked this before
but have not seen a response.)

Period. That
> would be completely and utterly useless, and a complete joke to create such
>  a specification. When a domain says that it signs all of its mail, it
> means just that. It doesn't mean that maybe on every third thursday that
> some other domain might sign the mail. It means that the domain in question
>  signs its own mail with its own signatures. That means that you have to 
> know which domain a piece of mail is purporting to be from. The address 
> chosen in the requirements in RFC5016 is the rfc2822.From address. This was
>  not controversial. Why we're rehash that non-argument now is beyond me.

Because the mechanism is problematic and the choice of From is problematic.

>> Question:  Is DKIM for transit validation or is it for content 

No it is not. In fact it is basic and salient.

Perhaps the difference between the two is not clear to you?

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 5 Dec 2007 19:24:11 -0000

>   by the mere act of signing a message from any random domain. Period.

Well, OK.  That sounds like a request to remove the language about
Verifier Acceptable Third-Party Signatures, since the sender has no
idea what signing domains the verifier would consider acceptable.
I'll be happy to send in an issue request referring to the specific
sections in the draft.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Wed, 05 Dec 2007 11:32:13 -0800

> I'll be happy to send in an issue request referring to the specific

   Absolutely. That is, in fact, what issue 1512 is about. Any text
   trying to say what receivers do with non-first party signatures
   should be removed as out of scope, IMO.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 05 Dec 2007 11:33:48 -0800

Dave Crocker wrote:
>>> 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.
>>
>> by the mere act of signing a message from any random domain.
> 

Defeated. Utterly. Trivially. It would be the equivalent to the
IETF trying to standardize an 8 bit encryption scheme.

> senders and receivers, with no signature breakage.

mtcc.com SSP: p=strict;

From: [email-masked]
DKIM-Signature: i=[email-masked];
Subject: phish is yummy

If you're going to say that this signature qualifies as acceptable for
the above SSP record, then you have created a security hole that renders
SSP utterly useless.

> but have not seen a response.)

Useless to whom? The SSP protocol? Yes, it's completely useless as
that signature doesn't emanate from that domain. If you're talking
about a receiver in general, that is completely out of scope of SSP;
the receiver is entitled to attach as much (ir)relevance to that
signature as it sees fit.

>>  signs its own mail with its own signatures. That means that you have 
>> to know which domain a piece of mail is purporting to be from. The 
>> address chosen in the requirements in RFC5016 is the rfc2822.From 
>> address. This was

Problematic? It's central, and well documented in RFC5016.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Dec 2007 11:38:20 -0800

Michael Thomas wrote:
> +1, and I had the dubious distinction of having to go through the thousands
> of mail messages. I can't imagine that there is anything new under the sun
> on this topic.

Well, I reviewed the archives for the period during which i= was added and 
could not find discussion of it.  So I'm glad to hear you've done a more 
thorough review.  This means that you can point me to the archives of the 
working group consideration of the issue?

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Wed, 05 Dec 2007 15:31:00 -0500

> Problematic? It's central, and well documented in RFC5016.

It unfortunate the people you acknowledged in RFC 5016 as providing 
substantial review, never really did agreed or never really thoroughly 
understand it.

So much time wasted.

Nearly 2+ years ago the original SSP-01, by far, the clearer functional 
specification, even a 6 year old can understand, biggest hole was the 
3rd party issue. Today, the same thing.

IMV, I should probably just focus on making DKIM/SSP a 1st party 
signature system as this is the only common ground nearly everyone, if 
not all, agrees with. And if some one wishes to propose a 3rd party 
signature after the 1st party system in in practice, it can then be 
revisited.

We need to provide the highest benefit possible for DKIM/SSP so that the 
market can gain the confidence in implementing and adopting it, relying 
on it - confidently with no ambiguity.  That can only be done with a 1st 
party signature system in place - first.  The 3rd party stuff is far too 
complicated. Too many loop holes, too many security threats, too much 
trouble that will bring down DKIM/SSP with it.

Of course, my opinion.

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 5 Dec 2007 20:30:53 +0100

Michael Thomas wrote:

> Who is apps-review, and why are they rejecting messages?

<http://www.standardstrack.com/ietf/apps-review/>

Like GenArt, only apps.  

> If this is intended as an apps area review where only 
> Dave gets to post, that's a problem.

Sometimes I read the GenArt list (it's on GMane) but I
think I've no business to post there.  A tool for the
general area director.  And apps-review is a tool for
one or both apps ADs.  

 Frank

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Dec 2007 12:54:42 -0800

> IETF trying to standardize an 8 bit encryption scheme.

Unfortunately, SSP is defeated out of the box, even with all of its specified 
features intact.

I publish a strict record.  I therefore want receivers to take note of all 
mail that has my domain in the From field but is not signed by that domain.

On day one, for all intents and purposes, no recipient server on the Internet 
is going to make the query for this, and hence the mechanism is "defeated".

At very best, it will be quite a few years (5-10 years seems typical, for 
popular enhancements to email) before a large number of receiving servers make 
the query, and there will remain a substantial percentage of receivers failing 
to query essentially forever.

So the strict requirements of the strict mode have to be considered in the 
face of massive non-adoption, pretty much forever.

Contrast this with the view that this feature is quite useful among a small, 
cooperative collection of services that have agreed to use it.

While this is not Internet scale -- by which I mean broad adoption with 
massive breadth of use and no prior arrangement among the users -- it is a 
perfectly credible capability, albeit one that needs to be treated as a 
specialized facility, rather than a general one.

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 5 Dec 2007 21:26:05 -0000

>the above SSP record, then you have created a security hole that renders

It rather depends on my opinion of hacker.com.  I agree that
signatures from unknown domains are uninteresting, something that's
the same with or without SSP.  But if I have reason to trust
hacker.com, I'm done, I'm not going to check anything else.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 5 Dec 2007 16:49:11 -0500

On Wednesday 05 December 2007 13:46, Michael Thomas wrote:
> > to a

+1.  It's pretty obvious that it has to be this way.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 5 Dec 2007 16:56:44 -0500

On Wednesday 05 December 2007 15:54, Dave Crocker wrote:
> Unfortunately, SSP is defeated out of the box, even with all of its
> specified features intact.
>
> On day one, for all intents and purposes, no recipient server on the
> Internet is going to make the query for this, and hence the mechanism is
> "defeated".
>
So all protocols that involve any kind of network exchange to work are 
defeated and useless and the IETF should stop writing them?  That's the 
logical conclusion one can draw from this perspective.  It's equally true of 
all protocols the day they are minted.

It's been clear you've had your mind made up about the utility of SSP since 
before the working group started.  It'd be nice if you tried to be 
constructive.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Wed, 05 Dec 2007 14:26:10 -0800

> hacker.com, I'm done, I'm not going to check anything else.

   Yes, but that should be outside of the scope of SSP. I think
   we are agreeing though even if it pains both of us :)

		Mike

---

From: Jim Fenton <[email-masked]>
Date: Wed, 05 Dec 2007 16:01:21 -0800

[Adding issue number to the subject so we know what we're talking about.]

> the above SSP record, then you have created a security hole that renders
With p=strict and no other Originator Signature present, the message is
indeed Suspicious.  If the verifier is following the spec, it is always
Suspicious.

You may have intended to present the example with p=all.  In this case,
the message may or may not be Suspicious, at the discretion of the
verifier.  This is what is meant by "Verifier acceptable".  If the
verifier knows something good about the signer (maybe it's ietf.org
instead of hacker.com), it might decide that the message is not
Suspicious.  It's up to the verifier.

So there are three cases:

p=unknown => message is not Suspicious
p=all => message is not Suspicious if an Originator Signature is present
or another signature is present that is acceptable to the verifier
p=strict => message is Suspicious unless an Originator Signature is present

It might be argued that we should allow the verifier to make a decision
based on other criteria in the p=all case.  I see SSP as an adjunct to
DKIM, and not other mechanisms, and the [not] Suspicious result as an
input to later stages of filtering, but I'd be interested in the group's
opinion on that.

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Wed, 05 Dec 2007 17:58:54 -0800

> Suspicious.  It's up to the verifier.

I actually meant it the way I wrote it because that's what Dave seems
to be saying an acceptable state of affairs for either strict or all. My
point is that it not acceptable for SSP qua SSP, though a receiver can 
decide
to trust hacker.com's signature in *both* cases and there's nothing that
we can or should do about that.

Which is a long winded version of that third party signatures are completely
orthogonal to SSP. "All" should just mean "I sign all of my mail". No
more, no less.

       Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 05 Dec 2007 20:33:16 -0600

> Well, I reviewed the archives for the period during which i= was added
 > and could not find discussion of it.  So I'm glad to hear you've done
 > a more thorough review.  This means that you can point me to the
 > archives of the working group consideration of the issue?

I wouldn't waste any more time chasing this.  Even if no such archive 
exists, what is that but evidence that this issue is idiosyncratic or 
has been deemed utterly unremarkable?

Also, let us reject the title of this thread and thereby strip away it's 
illegitimate claim of "paradigm change".  The burden of proof is on 
those who assert that such a change has occurred.  It certainly has not.

The notion that "DKIM-Base is for signed mail while DKIM-SSP is for 
unsigned (only)" has never been thinking in accord with any draft of SSP 
which I remember reading or implementing.  And it's clearly out of step 
with where we are today.

Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 05 Dec 2007 20:49:34 -0600

> we need to provide some precision in the thing we're calling SSP.

Exactly right!  Please, Jim, keep it up.

Folk on this list are confusing what the protocol states MUST be done in 
order to be implemented with what the protocol's algorithm states MUST 
be done to a message.  Any protocol has to have language with respect to 
the former.  This protocol has NO language with respect to the latter.

There is nothing that needs to be done here.

Arvel

---

From: John Levine <[email-masked]>
Date: 6 Dec 2007 03:03:00 -0000

> Which is a long winded version of that third party signatures are
> completely orthogonal to SSP. "All" should just mean "I sign all of
> my mail". No more, no less.

+1

R's,
John

PS: Mike and I agree on something! Alert the media!

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 05 Dec 2007 21:04:40 -0600

> hacker.com, I'm done, I'm not going to check anything else.

Correct, correct, correct!  In this cause we set SSP aside and embrace 
that realm which SSP so enthusiastically celebrates:  receiver freedom 
to do what-so-ever receiver freedom might dictate.  There is absolutely 
no problem here.

Arvel

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Dec 2007 19:08:17 -0800

> has been deemed utterly unremarkable?

A lack of working group discussion is evidence of a lack of working group 
awareness and most certainly a lack of explicit working group consensus.

The use of SSP for signed messages creates a series of functional interactions 
that SSP's use on unsigned messages does not.

For a security protocol to skip analysis of interaction effects -- heck, for 
any protocol function to do this -- seems a tad unusual, particularly when it 
seeks to modify an existing critical infrastructure service.

> which I remember reading or implementing.  And it's clearly out of step 

Note that <http://www.imc.org/ietf-mailsig/mail-archive/msg02252.html> refers 
to unsigned messages and not signed messages that do not match the From field.

d/
-- 

   Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 05 Dec 2007 21:06:57 -0600

> the former.  This protocol has NO language with respect to the latter.

Sorry, "MUST be done to a message" in the sense of dictating ultimate 
disposition thereof.

Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 05 Dec 2007 21:14:39 -0600

> Question:  Is DKIM for transit validation or is it for content

DKIM-Base is for transit validation.  DKIM-SSP is for detecting a 
certain type of unauthorized domain use.  Nothing is for content 
authentication.

Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 05 Dec 2007 22:14:45 -0600

Hi all, me again, sorry.  Seems I'm missing all the fun in Vancouver. 
You don't know how much I wish I could be there.

> Internet is going to make the query for this, and hence the mechanism is 

That line of thinking must be rejected because it is historically true 
for all protocols in widespread use today, promotes inertia, and 
celebrates a pessimistic futility.  We must be careful not to think in 
these terms.

> At very best, it will be quite a few years (5-10 years seems typical, 
> for popular enhancements to email) before a large number of receiving 
> servers make the query, and there will remain a substantial percentage 
> of receivers failing to query essentially forever.

Best to get the 5-10 year timer started now then!  This sounds like a 
good argument for getting SSP out yesterday.  Regardless, it may not be 
an accurate assessment of time frames in this case as recent industry 
activity suggests.

> So the strict requirements of the strict mode have to be considered in 
> the face of massive non-adoption, pretty much forever.

Folks, "massive non-adoption, pretty much forever" is one individual's 
assessment.  That does not necessarily mean it is accurate.  But, assume 
for a moment that it is accurate.  Do we deny useful capability to all 
simply because some (or even most) decide they don't need it or want it? 
  No, of course not.  So, no matter how you look at this argument, it is 
easily rejected.

> Contrast this with the view that this feature is quite useful among a 
> small, cooperative collection of services that have agreed to use it.
> 
> massive breadth of use and no prior arrangement among the users -- it is 
> a perfectly credible capability, albeit one that needs to be treated as 
> a specialized facility, rather than a general one.

I hope that I have completely misunderstood.

The notion that we should embrace a plurality of closed, specialized, 
and proprietary approaches to what should be an open industry standard 
freely available to all is antithetical to the IETF purpose (as I 
understand that purpose) and is specifically contrary to what we, as a 
working group, are chartered to achieve.  Therefore, it is out of step 
both with the spirit and the scope of our chartered work and should 
simply be discarded upon that basis.

Also, I can not stress this point enough: "specialized facilities" (as 
opposed to general ones) have a way of becoming entrenched and remaining 
specialized.  This is not healthy for the larger community.

Now, I am ready (and eager) to be corrected.

Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 05 Dec 2007 22:50:33 -0600

> Note that <http://www.imc.org/ietf-mailsig/mail-archive/msg02252.html> 
> refers to unsigned messages and not signed messages that do not match 
> the From field.

Well, I wonder what this might mean: "There is also the issue of (c) the 
use of SSP to determine the types of DKIM identities that are acceptable."

I'm done with this debate now.  What matters is the issue tracker and 
I'm sure the chairs would rather see input there.

Arvel

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Dec 2007 23:09:35 -0800

+1

Me, three.  Alert... everyone else.

d/

-- 

   Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 06 Dec 2007 01:50:07 -0600

> Me, three.  Alert... everyone else.

OMG, +1

I could easily get on-board for this.  What's unacceptable is if the 
existence of any valid signature what-so-ever is sufficient to bypass SSP.

Arvel

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 06 Dec 2007 12:12:46 -0000

>> by senders that publishing SSP will affect what happens to their mail.

Exactly. Verifier implementors who do not read the document carefully  
enough (Shock! Horror! they wouldn't to that would they!) will see all  
those "Verifiers MUST" statements and deduce that they are obliged to  
follow them exactly. Which will discourage them from trying innovative and  
imaginative techniques which might, in the long term, lead to impprved  
filtering of 'suspicious' (or even 'not so suspicious') messages.

And let me remind you that this thread started exactly because Dave  
Crocker (who maybe should know better) misread those "MUST"s in exactly  
that way. If even the people on this list can mis-read the draft, then  
that is a clear indication that its wording needs to be reviewed even  
though it does, when read carefully, say the right thing.
> mandate what receivers will do is a value added use of anyone's time.

Extra work that results in implementors making fewer mistakes is NEVER a  
waste of time.

FYI, here is the wording that I suggested again. It isn't necessarily a  
pure addition, since it might enable some other less obvious statements of

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 6 Dec 2007 09:26:00 -0500

> though it does, when read carefully, say the right thing.

I agree that he chose to read them that way.

> Extra work that results in implementors making fewer mistakes is NEVER a

Agreed, but I don't think that's the case here.

> > adherence to the particular set of processes described here."

I don't think that really changes much.  

-1

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Thu, 06 Dec 2007 08:23:00 -0800

Dave Crocker wrote:
> 
> The use of SSP for signed messages creates a series of functional 
> interactions that SSP's use on unsigned messages does not.

Dave. Did you read rfc5016 before it was issued? It's not like this
was a closed opaque process.

And as far as I can tell, you alone seem to be carrying this torch
here. Changing what we agreed on with rfc5016 should require a very
high barrier. I see little if any support, let alone broad consensus
that we got it wrong.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 06 Dec 2007 08:44:39 -0800

> high barrier. I see little if any support, let alone broad consensus

So, you missed the postings by Levine and Atkins?  (Perhaps some others were 
on "my" side of this topic, but these two were at least quite explicit.)

I guess they don't know much about the topic or anti-abuse recipient 
operations behavior, so it's probably ok to keep this an individual ad hominem 
dismissal.

I've tried to recruit postings by some other anti-abuse folks who have 
expressed strongly negative opinions, but they have declined, indicating that 
they try to avoid being abused, and do not see any indication of interest in 
serious discussion about this in this group.

 From the style of quite a few postings on the list, can you blame them?

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Thu, 06 Dec 2007 08:57:44 -0800

>> high barrier. I see little if any support, let alone broad consensus

   You still didn't respond: did you read 5016 before it was issued?
   In fact I know that you did because you gave a lot of very detailed
   feedback. And this was not one of the thing you commented on at the
   time, so charges of "paradigm change" ring rather hollow.

> So, you missed the postings by Levine and Atkins?  (Perhaps some others 
> were on "my" side of this topic, but these two were at least quite 
> explicit.

   I didn't read them as supporting your reading. Let them speak for
   themselves. There are a lot of things being discussed, after all.

> operations behavior, so it's probably ok to keep this an individual ad 
> hominem dismissal.

   Saying that you need broad consensus to change the documented
   consensus is hardly an ad hominem dismissal.

> expressed strongly negative opinions, but they have declined, indicating 
> that they try to avoid being abused, and do not see any indication of 
> interest in serious discussion about this in this group.
> 

   Ah, the silent majority. Still silent after all these years.

		Mike

---

From: Steve Atkins <[email-masked]>
Date: Thu, 6 Dec 2007 09:17:02 -0800

On Dec 6, 2007, at 8:57 AM, Michael Thomas wrote:

>> So, you missed the postings by Levine and Atkins?  (Perhaps some  
>> others were on "my" side of this topic, but these two were at  
>> least quite explicit.
>

I broadly agree with most of Dave's concerns...

>
>> I guess they don't know much about the topic or anti-abuse  
>> recipient operations behavior, so it's probably ok to keep this an  
>> individual ad hominem dismissal.
>
>> I've tried to recruit postings by some other anti-abuse folks who  
>> have expressed strongly negative opinions, but they have declined,  
>> indicating that they try to avoid being abused, and do not see any  
>> indication of interest in serious discussion about this in this  
>> group.

... but this working group has  people who are prepared to spend
a lot of time to shout down those they disagree with, leading to an
unproductive and unprofessional environment. I find the lack of
courtesy and professionalism here unpleasant enough that I tend
not to get involved much, even though I see very poor design
decisions being made.

It's unavoidable to some degree - any mention of "antispam" tends
to bring the noisy kooks out of the woodwork - but it's not going to
lead to a well-engineered, useful protocol.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Thu, 06 Dec 2007 09:29:10 -0800

Steve Atkins wrote:
>>> others were on "my" side of this topic, but these two were at least 
>>> quite explicit.
>>

Believe it or not, I agree with some of Dave's too. But that isn't
the issue at hand. The specific issue is whether *any* DKIM signature
from *any* domain should be sufficient to qualify for "strict" or "all".
Do you agree with that or not?

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 06 Dec 2007 09:40:04 -0800

Michael Thomas wrote:
> the issue at hand. 

It isn't?  You were asking a more narrow question?

And what if Steve's "broadly" happens to include the particular that you say 
this exchange involves?  Is there some reason you didn't seek to find that out?

d/
-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Thu, 6 Dec 2007 09:49:51 -0800

> Do you agree with that or not?

In a well-designed protocol based on DKIM, yes I'd agree that a
validly DKIM signed message should not provoke an SSP query.

But that's not the protocol we have.

I think RFC 5016 shows a lack of understanding of DKIM (or is choosing
not to consider some important features of DKIM), and is
part of the push to try and build a next generation SPF on
an inappropriate base authentication technology.

Cheers,
   Steve

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 6 Dec 2007 12:51:46 -0500

> not to get involved much, even though I see very poor design

I'm sympathetic to this perspective.  I think we have two broad groups here.  
One believes that SSP has utility and one believes that it doesn't.  Trying 
to produce a design by committee that attempts to split the difference is 
suboptimal.

Personally, I'm getting sick of the attacks on the concept and utility of SSP 
at this point in the game.  I really wish people would focus on making it as 
good as it can be and then we'll see what we end up with.  

I'm having a hard time not believing that some people are intentionally trying 
to undermine SSP development.  

I agree that some poor design decisions are getting made and have less 
interest than I used to in trying to invest my time in fixing it (and no, I'm 
not going to expend the time to go into details).

Scott K

---

From: <[email-masked]>
Date: Thu, 6 Dec 2007 12:56:03 -0500

When it comes to discussing SSP I hear a lot of noise with very little
reason to implement or use except in a few specific cases like highly
phished sites. My 2 cents
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Steve Atkins
Sent: Thursday, December 06, 2007 12:17 PM
To: DKIM WG
Subject: Re: [ietf-dkim] Tracing SSP's paradigm change

Cheers,
   Steve

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 6 Dec 2007 12:58:34 -0500

> an inappropriate base authentication technology.
I think you aren't understanding the purpose of SSP at all.

If any random signature from any domain obviates the SSP, what possible use is 
SSP?

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Thu, 6 Dec 2007 10:11:43 -0800

> If any random signature from any domain obviates the SSP, what  

Bill Oxley observed across threads "When it comes to discussing
SSP I hear a lot of noise with very little reason to implement or use
except in a few specific cases like highly phished sites."

There's a long discussion to be had there, which starts with me
asking "Well, what's your threat model?" and would ideally follow
with "So, given this framework, what is your attack tree, and how
does SSP help thwart it?", but when I've tried to have that discussion
in the past it's not gone anywhere productive

Cheers,
   Steve

---

From: [email-masked] (Wietse Venema)
Date: Thu, 6 Dec 2007 13:13:03 -0500 (EST)

> If any random signature from any domain obviates the SSP, what possible use is

SSP is good for senders to announce what mail they sign. That's
the non-controversial part. 

	Wietse

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 6 Dec 2007 13:21:07 -0500

> in the past it's not gone anywhere productive

Personally, I think that exact question has been asked many times and answered 
with great specificity many times.  I agree that those who disliked SSP at 
the start of the working group still disagree on this.  

Personally, I think only the highly phished sites that really care about 
forgery will publish highly restrictive SSP records and so I think Bill and I 
actually agree.  

The choice in my mind is whether something like SSP is decided in secret among 
large highly phished senders and large receivers or if we are going to have a 
standardized approach that all can use IF they wish.  As has recently been 
said, no one is forcing anyone to use SSP.  Those who don't like it are 
perfectly free to ignore it.

What I see going on is a desire to change SSP into something completely 
useless, and then based on this change, declaring it useless.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 06 Dec 2007 13:30:27 -0500

> in the past it's not gone anywhere productive

Steve, were you not involved in the lengthy threat analysis discussions 
and production of RFC 4686?

There are two sides to the coin here and it really serves no justice at 
to point to rehash it all, who's at fault, who's the bad guy, good guy, 
etc.

For the record, there has been many questionable decisions made and when 
they were highlighted, they were either pushed aside, ignored or 
shunned. So it is really an humorous irony to see whats going on now.

-- 
Sincerely

Hector Santos, CTO

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 06 Dec 2007 12:36:53 -0600

> not to get involved much, even though I see very poor design

I wish to sincerely apologize to everyone in this WG if I have 
contributed to an unprofessional/unproductive environment. Lately, I 
think a good argument could be made that I have.

Arvel

---

From: Steve Atkins <[email-masked]>
Date: Thu, 6 Dec 2007 10:42:02 -0800

On Dec 6, 2007, at 10:30 AM, Hector Santos wrote:

> Steve, were you not involved in the lengthy threat analysis  
> discussions and production of RFC 4686?

The vast majority of that discusses threats against DKIM
in particular, primarily a rehash of the normal attacks
against PKI and DNS.

What I'm talking about is "the general threat that SSP is
intended to counter", which is a completely different,
and mostly unrelated thing (though I suspect that part
of the attack tree would involve the issues discussed
there). I've not seen that discussed in any clear, let
alone formal, manner, I don't think.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Thu, 6 Dec 2007 11:16:50 -0800

On Dec 6, 2007, at 9:29 AM, Michael Thomas wrote:
> The specific issue is whether *any* DKIM signature from *any* domain  
> should be sufficient to qualify for "strict" or "all".
>

This question appears to miss the point.  When examining the domain of  
the From, a valid signature by that domain on behalf of _any_ header  
should be sufficient to comply with a "strict" assertion.  The only  
exception need would be for restricted keys.  As Originating Signature  
is defined, this is not the case.

Dave's comment was about DKIM offering evidence of a domain's  
responsibility.  This concept has been missed by the current  
definition for Originator Signature.  Messages that are not signed or  
signed by different domains would be a separate issue.  The "all"  
assertion requires _at least a valid_ signature acceptable to the  
verifier.  At least the definition for "all" is correctly at the domain.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 06 Dec 2007 11:40:05 -0800

> an inappropriate base authentication technology.

   Gee thanks, I am new on this block I guess.

   In any case, the problem that I'm having with a lot of the nay-sayers
   is that it is purely destructive rather than constructive feedback.
   The feedback is always of the nature of this is wrong, not what will
   correct the problem. When I raise issues, I suggest a change to make
   the spec better. If you don't suggest concrete changes to the draft,
   it's really sort of hard to take you or anybody else seriously.
   Frankly if you think this is just a piece of junk, I really don't
   understand why you or Dave or John waste your time.

		Mike

---

From: Hector Santos <[email-masked]>
Date: Thu, 06 Dec 2007 14:58:54 -0500

> alone formal, manner, I don't think.

Well, I hate to be accuse of being respectful, but I disagree.

There has been at least 2+ years of long discussions on nearly every 
security aspect, every one regarding SSP, including its relationship 
with DKIM.

Every item was discussed, debated and argued. I even wrote a IETF I-D 
called DSAP that addressed nearly everything we are talking about here 
with a primary focus on the security threats. I wrote detailed outlines 
and provided boundary charts that provided the possible scenarios and 
events based on the possible results for DKIM plus SSP. There was an 
appreciation by many people for these analysis charts.

If one chooses to ignore people, deemed it not formal, not worthy or not 
qualified your input, or maybe you just finally recognizing it, fair 
enough. But it is really unfair suggest to everyone it never happen, nor 
the time and energy wasn't put in.

Since the very first SSP draft, the top concerns

    - Redundant SSP lookups
         - including when it is applied.
    - What does "Exclusive" mean?
    - Types of policies
    - 3rd party signatures - how to control it

They were discussed, over and over and over again many times. 
Unfortunately, it appears, although with the compromises made by both 
camps, the finer points still haven't been resolved.

The other significant conflictive problem:

     - Reputation vs SSP

The out of scope concept continues to rears its head.  Some people felt 
there was an undermining going with SSP, that it would never work, but 
lets see where it goes. But it was like reputation was the ultimate way 
to do it, hence no need to use SSP was the basic philosophy you felt in 
the air.

-- 
Sincerely

Hector Santos, CTO

---

From: Steve Atkins <[email-masked]>
Date: Thu, 6 Dec 2007 12:06:47 -0800

On Dec 6, 2007, at 11:40 AM, Michael Thomas wrote:

>>>>>> So, you missed the postings by Levine and Atkins?  (Perhaps  
>>>>>> some others were on "my" side of this topic, but these two  
>>>>>> were at least quite explicit.
>>>>>

(Michael removes the relevant comment here, let me re-add it).

>> But that's not the protocol we have.

I agree, in principle, with Dave's view that a valid DKIM
signature should not provoke additional DNS queries
for self-published policies.

However I do not believe that SSP does not require
that, from my reading of the current drafts.

>   understand why you or Dave or John waste your time.

RFC 5016 isn't based on a clear articulation of what threat
SSP is supposed to defend against. It's also based on the
misconception that if a sender DKIM signs a mail then it
will still be signed on receipt (I understand that you know
that that isn't the case, but a lot of the document appears to
be based on simply ignoring that fact). It's a good solid
description of what a protocol should look like, and many
of the points it does bring up are good ones - but it's
based on false assumptions.

Given that, any suggested changes aren't going to be
wordsmithing, they're going to be wholesale rewrites
which will both be rejected by the document owner and
cause yet more aggravation, noise and personal attacks
here (the level of discourse is so coarse that everyone,
myself included, is letting their frustration leak through
into the discussion). What's the point? My goal is not
to annoy people, it's to improve the quality of the global
email infrastructure.

If you want to work on an analysis of SSP, based on an
honest evaluation of the weaknesses of DKIM on which
it's based, a clear articulation of the threat it intends to
thwart and a real analysis of the actual threat model and
the ways in which SSP can alleviate it, and the harmful
side effects that doing so may have on email in general
then that would be a useful document for the group to
put together and a good use of time.

Minor wordsmithing of an existing document based on
invalid lemmas may improve that documents clarity, but
doesn't seem like the most useful use of time.

Cheers,
   Steve

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 7 Dec 2007 01:08:17 +0100

Steve Atkins wrote:

> part of the push to try and build a next generation SPF

No push in that direction on any SPF or IETF list I know,
in fact discussing 2822 originator header fields on SPF
lists would be on the border to "off topic" (excl. PRA
for various and known reasons).  

A "part of the push" sounds like more than one or two
contributors, are you talking about Doug's TBR draft ?
That's IMO no SPF-TNG, it might be a kind of SMTP-TNG.

 Frank

---

From: Steve Atkins <[email-masked]>
Date: Thu, 6 Dec 2007 16:12:05 -0800

> That's IMO no SPF-TNG, it might be a kind of SMTP-TNG.

I was referring to SSP, which is trying to be the next SPF
(and, in strict mode, is identical in functionality to a subset of
SPF).

Cheers,
   Steve

---

From: Jim Fenton <[email-masked]>
Date: Thu, 06 Dec 2007 16:54:30 -0800

> PS: Mike and I agree on something! Alert the media!

In that case, what is the SSP result when a message does not contain a
valid Originator Signature, and the Originator Domain has a policy of "all"?

The whole business about third-party signatures is a DKIM-based
mechanism to decide what to say in that case.  If the verifier sees
another signature that they "like", the result is "not Suspicious".

-Jim

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 7 Dec 2007 02:13:30 +0100

Steve Atkins wrote:
 
> (and, in strict mode, is identical in functionality to a
>  subset of SPF).

SSP is farer away from SPF than PRA.  SPF is about SMTP, not
not originator header fields, and it's about backscatter,
not phishing, an SPF PASS means something even it's from an
unknown stranger, an SSP PASS from unknown strangers means
nothing.  SSP and SPF are very different.  SSP and PRA might
share some functionality, with different weak spots.  PRA has
of course all weak spots of SPFs adding its own.  

SSP has the "first author" when the terminology is fixed, as
Dave proposed it.  At that point I always stop thinking, the
"first author" is just too odd for my tastes - like the idea
that a mailing list could simply *replace* an existing Sender
header field.  I guess I wrote that more than often enough
here, the WG wants to try it anyway, let's see what happens.

 Frank

---

From: John L <[email-masked]>
Date: Thu, 6 Dec 2007 20:17:09 -0500 (EST)

> valid Originator Signature, and the Originator Domain has a policy of "all"?

"not compliant"

> another signature that they "like", the result is "not Suspicious".

If the recipient sees another signature it likes, it's not going to do
an SSP lookup at all, so I don't see any value in giving recipients 
directions for a situation that won't happen.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 06 Dec 2007 21:21:00 -0500

>(and, in strict mode, is identical in functionality to a subset of
What subset of SPF is that?  I'm intimately familiar with SPF and I'm not 
following you.

Scott K

---

From: John Levine <[email-masked]>
Date: 7 Dec 2007 04:47:14 -0000

>I'm sympathetic to this perspective.  I think we have two broad
>groups here.  One believes that SSP has utility and one believes that
>it doesn't.

I wouldn't object to a version of SSP that stuck to publishing
senders' practices, and I doubt anyone else would either.
Unfortunately, the current draft is about 1/4 sender practices and 3/4
other stuff.  It's the other stuff that's the problem.

---

From: "J D Falk" <[email-masked]>
Date: Fri, 7 Dec 2007 00:31:32 -0500

Steve Atkins wrote:

> There's a long discussion to be had there, which starts with me asking
> "Well, what's your threat model?" and would ideally follow with "So,
> given this framework, what is your attack tree, and how does SSP help
> thwart it?", but when I've tried to have that discussion in the past
> it's not gone anywhere productive

At the meeting on Tuesday, I suggested that one way to settle the d= vs.
i= debate would be to document the many overlapping yet divergent likely
use cases -- and was promptly asked to do so.  Hooray for volunteerism!

I think the threat modeling may be yet another instance where we're all
taking past each other because we have different threats in mind, so
(unless there's stringent objection) I'm going to include
threats/concerns in that document as well.

Right now I'm on a flight back to Colorado, then on vacation for a few
days, so the questions for this project will show up next week.  Feel
free to send me any additional thoughts in the meantime.

Your most humble servant,

--
J.D. Falk
Receiver Products
Return Path

---

From: Steve Atkins <[email-masked]>
Date: Thu, 6 Dec 2007 21:46:48 -0800

On Dec 6, 2007, at 9:31 PM, J D Falk wrote:

>> asking
> taking past each other because we have different threats in mind
> , so (unless there's stringent objection) I'm going to include

The first step would be a group consensus on what the threats
are ("what SSP is supposed to be for"), or at least a superset of
what most people think.

Anyone? Bueller?

Cheers,
   Steve

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 7 Dec 2007 01:36:42 -0500

> are ("what SSP is supposed to be for"), or at least a superset of
I, for one, feel like we did this in great depth during and before the 
requirements development.  My suggestion would be to look to the work we've 
already done and refresh your memory on the established consenses.  I'm 
assuming this isn't the play the game over until you get the result you want 
game.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Thu, 6 Dec 2007 22:51:23 -0800

On Dec 6, 2007, at 10:36 PM, Scott Kitterman wrote:

> already done and refresh your memory on the established consenses.

I recall two suggestions from there. Neither were considered in any
depth.

1. Domain forgery. That's not a "threat". It's an intermediate step,  
at most.

2. Phishing.

So that's.... one.

Got any others?

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Dec 2007 00:22:33 -0800

Steve Atkins wrote:
> 1. Domain forgery. That's not a "threat". It's an intermediate step, at 
> most.
> 
> 2. Phishing.

And phishing has a rather rich terrain.  Consideration of which specific 
subset will be addressed (hmmm... pun?) by particular SSL features has not 
been considered.

Comparing phishing examples of the From mailbox address, versus the remaining 
array From display string, Subject line, body content, or use of cousin 
domains ought to force rather careful statements of expected effect.

Equally, the references to choices made due to common user interface display 
practices has not received analysis, other than the earlier discussions for 
DKIM where we agreed not to factor human factors into the design, opting 
instead for a focus on receive-side filter engine activity.

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Fri, 07 Dec 2007 03:58:50 -0500

> free to send me any additional thoughts in the meantime.

J D,

First I would like to say that I welcome this project of yours. If will 
finally help focus attention to the security issues I and many others 
highlighted, then this is good news.

When I wrote the (now expired I-D) I-D DSAP (DKIM Sender Authorization 
Protocol) draft:

http://www.isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html
http://www.isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.txt

the main reason was to officially highlight the concerns and hopefully 
they would be considered for SSP.  I was not really interested in 
competing or stepping on anyone's toes, but only to highlight the 
concerns. I decided not to follow up on DSAP and support SSP when Jim 
did consider them for the most part, in more complex ways, but it was 
enough to satisfy the key concerns outlined in DSAP.

Before I was encouraged in writing the I-D, I outlined it with a 
PowerPoint presentation, where it was converted to a web presentation:

     http://www.isdg.net/public/sap/dsap.htm

The presentation might help summarizes the issues.

If you do look at these documents, please view it not a proposal for a 
new DSAP protocol, but to extract the general considerations.

The DSAP work was based on working out the boundary conditions for all 
possible DKIM results.  This was done back around the 2005/2006 time 
frame.  It help highlight what can be eliminated, what can be folded and 
also help highlight the complexities as well.  You might want to look at 
this August 2005 message which help frame the discussion on SSP and how 
it relates to DKIM:

     http://www.imc.org/ietf-mailsig/mail-archive/msg02046.html

In fact, on that time frame, there were many really good key security 
discussions regarding SSP:

     http://www.imc.org/ietf-mailsig/mail-archive/theads.html#02046

DSAP considered the entire flow of whats possible, including payload 
considerations to help address optimization. This is one reason I 
personally had a problem with the SSP lookup steps outlined in RFC 5016, 
but it wasn't a big concern related to the overall questions DSAP addressed:

Ultimately, DSAP addresses the following fundamental security questions 
about DKIM:

    * Does the domain ever distribute mail?
    * Do you expect the mail to be unsigned?
    * Do you expect to sign all mail?
    * Is your domain the exclusive signer?
    * Are 3rd party signers or signatures allowed?
    * Are 3rd party signers allowed to strip your original signatures?

Each of security concern is based on whats realistically possible in 
deployed pure DKIM signer and DKIM receiver only world.  Nothing was 
left out, I refrained from subjective thinking, non-heuristic, purely 
technical considerations on the automatic state machine possible 
conditions for DKIM.

Another relative viewpoint of the above is to relate them to current 
conditions in the today's world and this might help to determine the 
relative effectiveness of a SSP or DSAP or any other Originating 
domain-based policy protocol.  In principle, a receiver will see the 
following boundary conditions:

    (1) Mail arrives with no signature
    (2) Mail arrives with valid 1st signature (1PS)
    (3) Mail arrives with invalid 1PS
    (4) Mail arrives with valid 3rd signature (3PS
    (5) Mail arrives with invalid 3PS

One example:

A domain exclusive "Only I always sign" 1st party signing policy.

Using a simple FUZZY LOGIC classification model:

    +1.0 -> 100% good, no false positives
    +0.5 -> 50% not sure, everything look good, hash failure
     0.0 -> indeterminate
    +0.5 -> 50% not sure, something is wrong
    -1.0 -> 100% bad, no false positives

Based on this stated policy, you can rate the results:

   -1.0  (1) Mail arrives with no signature
   +1.0  (2) Mail arrives with valid 1st signature (1PS)
  -/+0.5 (3) Mail arrives with invalid 1PS
   -1.0  (4) Mail arrives with valid 3rd signature (3PS
   -1.0  (5) Mail arrives with invalid 3PS

Analysis:

First with the 100% reliable zero false positive failures:

   -1.0 (1) Mail arrives with no signature
   -1.0 (4) Mail arrives with valid 3rd signature (3PS
   -1.0 (5) Mail arrives with invalid 3PS

There should be no question that these are 100% violations of the 
domain's stated exclusive "Only I always sing" policy. Signatures are 
required and no 3rd party signing is expected. Therefore there should no 
ambiguity from an programmatic automated thinking process on what 
classification these results belong in - these are candidates for 
immediate rejection.

Second, the 100% reliable zero false positive success:

   +1.0 (2) Mail arrives with valid 1st signature (1PS)

Again, there should no question that this is a "DKIM Complete" and "SSP 
complete" message.  It should be be classified as a candidate for 
acceptance.

     Note: In the Threat Analysis discussions leading up to
     RFC 4886, I believe it was a consensus that the only
     reasonable possible threat for a 1st party valid signature
     is internal theft or compromise of the owner's DKIM hashing key.

and third, that leave us with the indeterminate result:

  -/+0.5 (3) Mail arrives with invalid 1PS

It is indeterminate because there has been no confidence in what to deal 
with failure.

It could be a +0.05 in the sense that the DNS records all look ok, but 
there was hashing failure.  One of the reason we have a bh= body hash 
was to help address this scenario where there might be a simply message 
body integrity issue.

It could be a -0.05 in the sense that something else went wrong, 
NXDOMAIN, missing headers, something else probably shouldn't happen like 
the more understandable body alteration issue.

In either case it is a indeterminate condition in the same, it is not a 
100% zero false positive condition.

The security threat here is that unless there is guidance for 
indeterminate conditions, bad guys can exploit DKIM by intentionally 
creating DKIM signature that will fail.  In other words, just throw in a 
junk hash.

and finally, for this fuzzy condition, this leads up as do why I always 
thought the DKIM "ignore if failure, view as unsigned" can both be 
useful but also problematic.

If we follow RFC 4871 DKIM recommendations in classify failed DKIM 
signatures as unsigned then the above analysis changes:

   -1.0  (3) Mail arrives with invalid 1PS -> Promoted to no signature

Because it is was promoted to no signature, the exclusive policy will 
promote a rejection classification.

This can be viewed as both good and bad:

   - good: a decision has been made.
   - bad: This increases the potential for false positives.

In summary, we just analyzed the really strong exclusive "I always sign" 
policy.  The same can be done with the others to create a decision tree 
with +/- 1.0 zero false positive conditions and also fuzzy +/- 0.5 
indeterminate unknown false positive conditions.

-- 
Sincerely

Hector Santos, CTO

---

From: "Patrick Peterson" <[email-masked]>
Date: Fri, 7 Dec 2007 02:26:53 -0800

In the thread below the common issue is "what will happen in the
future?" Dave thinks things will happen in 5-10 years or "pretty much
forever" while Arvel disagrees. While my opinion matches Arvel's more
than Dave's it is certainly true that no one knows for certain. And we
can all agree that it is unlikely I have a new silver bullet argument or
body of evidence that will convince Dave that his timeframes are off by
an order of magnitude.

As Yogi Berra said, "Prediction is very hard, especially about the
future"

I recommend we all agree that we don't know when these things will
happen. It certainly won't be in less than 12 months and it had better
be before "pretty much forever". I think we can still agree on the best
design even if it takes somewhere in this range to realize. We can
certainly agree that the clock won't start ticking until we have a spec.

pat

---

From: "Patrick Peterson" <[email-masked]>
Date: Fri, 7 Dec 2007 02:31:28 -0800

Similar to my recommendations on avoiding crystal ball arguments in
designing SSP, I would like to encourage us to avoid arguing about SSP
market demand. Again this thread from Dave and Arvel is a great
illustration.

I think lots and lots of folks want strict/deny. (Of course I count
myself among them so how's that for bias!)

Dave and others think there is a small, non-Internet scale bunch that
want it.

There is no proof that Arvel and I am right. But I do think there are
enough people making this argument that there is a credible, if
unproven, need. I think we should err on meeting this possible need
rather than disregarding this possible need.

pat

---

From: "Patrick Peterson" <[email-masked]>
Date: Fri, 7 Dec 2007 02:35:02 -0800

>  From the style of quite a few postings on the list, can you 
I hope that myself and a few others have avoided the ad hominem attacks
and attempted to engage in serious discussion. If I have attacked or
offended anyone I apologize.

Intelligent people of good will often disagree on technical matters but
that should not impact our mutual respect for one another.

pat

---

From: "Patrick Peterson" <[email-masked]>
Date: Fri, 7 Dec 2007 02:42:31 -0800

> not to get involved much, even though I see very poor design
ironically enough while i disagree with steve on most aspects of SSP, i
feel the exact same way regarding his comments above.

(of particular frustration to me has been a large number of posts
stating "SSP dictates receiver actions", etc.)

it is quite clear the unmovable object and irresistable force have met
in the form of diametrically opposed opinions on SSP that will not be
changing. and this has led to unproductive and unprofessional
discussions.

> lead to a well-engineered, useful protocol.
again i agree but i think one man's antispam kook is another man's
rational thinker. the same goes for useful protocols.

pat

---

From: "Patrick Peterson" <[email-masked]>
Date: Fri, 7 Dec 2007 02:42:34 -0800

+1

---

From: "Patrick Peterson" <[email-masked]>
Date: Fri, 7 Dec 2007 03:09:04 -0800

> the start of the working group still disagree on this.  
+1: neither the irresistible force nor the immovable object are budging
:)
 
> forgery will publish highly restrictive SSP records and so I 
Steve thinks a threat model and attack tree are necessary. I don't know
if they are necessary or if this work has been completed. My
justification for SSP is the same one that has been brought up for
almost two years now: after certain domain-owners go to great lengths to
deploy DKIM reliably across their entire extended set of legitimate
MTAs, they will want to tell the world their non-binding preference is
to have receivers not deliver unsigned messages using their domain.

I know of significant market demand for this capability and I certainly
have every plan to use it if/when available across a very large number
of mailboxes worldwide.

Note that this capability doesn't mean that the current SSP draft is
"right" let alone "perfect". But whatever wordsmithing and improvements
are made to SSP it is important that the core of the strict/deny
capabilities remain. I'm very much in favor of polishing SSP and very
much opposed to removing core strict/deny features.

> perfectly free to ignore it.
Yahoo and Paypal have already publicly stated that they have developed
their own back-channel method for a strict/deny-like SSP capability for
DK. Other large senders have also said they will obtain this
functionality through back-channel arrangements if needed.

Here is the quote Bank of America provided for use at IETF:
"DKIM has allowed the largest targets of online fraud and phishing, the
financial services industry, to begin positively asserting e-mail that
is legitimately from them. Conversely, we are looking toward SSP as a
way to apply strong policy regarding e-mail that falsely purports to be
from one of our domains. In other words, this policy framework needs to
provide a clear intent related to the assertion of the sending
institution, including a strong capacity for dealing with unsigned mail
or malformed signatures, including the intent for this type of message
to not be delivered to the customer mailbox.
If this capability is not available in SSP, then the capability will be
provided by other means and SSP will lose much of its usability."
Erik M. Johnson, SVP, E-mail Infrastructure & Secure Messaging, Bank of
America

Here is the quote from US Bank:
"Delivering an email that has failed a DKIM check as "Suspicious" may
fit most use cases but not all.  Domains that are targeted for Phishing
need a mechanism of informing recipient domains that they have "no
confidence" in unsigned or improperly signed email.  These emails should
be treated as potential threats and NOT delivered to the Intended
recipients.   A SSP "Deny" option would provide the ability for domains
that fit this use case to recommend rejecting or quarantining email that
has failed DKIM verification."
Jeff Carnahan, Messaging Solutions Architect, US Bank

Note 1: Please don't misinterpret these statements as requesting the
ability for senders to *dictate* receiver behavior.
Note 2: Please don't misinterpret these statements which use the term
"phishing" as statements that DKIM and/or SSP will solve "phishing". The
use of the term "phishing" is clearly intended to help describe the
types of institutions that are more interested in this type of
capability, not to describe the problem we are solving.
Note 3: I believe Bank of America and PayPal have two of the largest,
most sophisticated enterprise deployments of DK/DKIM in the world. These
two organizations requests for this capability should not be taken
lightly. Even if one disagrees with their request it is dangerous for
the IETF to deny a requested capability the Internet community.

cheers,

pat

---

From: "Patrick Peterson" <[email-masked]>
Date: Fri, 7 Dec 2007 03:19:18 -0800

> an inappropriate base authentication technology.

I really struggle with comments like these. I don't believe RFC 5016 is
a push to build a "next generation SPF" but there's no response I can
think of to this accusation. (Although "Yes, I have stopped beating my
wife." comes to mind. :) ) This statement is subjective and attributes a
specific motive to SSP/5016 supporters that can't be be rebutted without
going down the ad hominem, unconstructive route.

(And please don't take this as an argumentum ad hominem but rather as an
argumentum ad nuncium. It is certainly not meant as an ad hominem and
hopefully not taken as one.)

pat

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Dec 2007 06:32:14 -0800

> certainly agree that the clock won't start ticking until we have a spec.

and

 > market demand. Again this thread from Dave and Arvel is a great

Patrick,

Your suggestions would be fine if the standards effort were free, rather than 
representing massive direct and opportunity costs, as well as affecting the 
complexity -- ie, the basic viability -- of the specification.

A sense of the market need/demand for a protocol is fundamental to the 
decision to pursue developing it.  A sense of the plausible adoption rate has 
a massive effect on the types of engineering decisions that are made about it.

(By the way, the issue of market demand is formally written into IETF 
documents about chartering an effort. The comment about adoption is simple 
experience: SSP seeks to change existing email handling.  Changes to existing 
service take a very long time.  We have lots and lots of experience to back 
this statement up.)

The difference between narrow, immediate need versus broader, long-term need 
(as wells as between combinatorials of these) will typically have a very large 
impact on the specific engineering choices that are made and the way they are 
pursued, such as shoving something out the door without testing it, versus 
taking a more gradual approach that permits learning from taking smaller steps.

For myself, I am clear there is an immediate need among a small set of very 
important service operators.  Given that we all know of at least one 
real-world example of a private agreement for an equivalent service -- as well 
as statements from some others that they want the same service -- I think we 
have a solid basis for believing that there will be uptake among this market 
niche.

What we also have is, at best, conflicting data about the broader market.  It 
makes no sense for us to decide to ignore this fact.

d/
-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 7 Dec 2007 09:59:48 -0500

On Friday 07 December 2007 09:32, Dave Crocker wrote:
> Your suggestions would be fine if the standards effort were free, rather
> than representing massive direct and opportunity costs, as well as
> affecting the complexity -- ie, the basic viability -- of the
> specification.
>
> decision to pursue developing it.  A sense of the plausible adoption rate
> has a massive effect on the types of engineering decisions that are made
> about it.
>
> experience: SSP seeks to change existing email handling.  Changes to
> existing service take a very long time.  We have lots and lots of
> experience to back this statement up.)
>
> The difference between narrow, immediate need versus broader, long-term
> need (as wells as between combinatorials of these) will typically have a
> very large impact on the specific engineering choices that are made and the
> way they are pursued, such as shoving something out the door without
> testing it, versus taking a more gradual approach that permits learning
> from taking smaller steps.
>
> real-world example of a private agreement for an equivalent service -- as
> well as statements from some others that they want the same service -- I
> think we have a solid basis for believing that there will be uptake among
> this market niche.
>
> What we also have is, at best, conflicting data about the broader market. 
> It makes no sense for us to decide to ignore this fact.
>
> d/

We had this discussion when the working group was chartered.  The decision to 
include SSP in the charter is a reflection of the consensus.  Given that, is 
there clear and convincing evidence that would merit overturning the 
established consensus?

Scott K

P.S.  Please could we do something new and stop redoing the last two years of 
discussion on this topic.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: <[email-masked]>
Date: Fri, 7 Dec 2007 10:09:06 -0500

Please note that when I suggested an SSP record that would indicate that
"We send no mail" it was pointed out forcefully that SPF could do that
for me. So the effect on some was to think that SSP must be supportive
of SPF/Sender ID, that is where that impression has been coming from.
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Patrick Peterson
Sent: Friday, December 07, 2007 6:19 AM
To: Steve Atkins; DKIM WG
Subject: [ietf-dkim] Next-generation SPF cabal

pat

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 7 Dec 2007 10:34:25 -0500

> of SPF/Sender ID, that is where that impression has been coming from.
I think that was me.  I think it was also suggested (and the reason the WG 
chose not to pursue it) that it was outside the scope of the WG charter.

I understand the SPF has a downside that some people find seriously 
objectionable.  None of those problems apply to a 'sends no mail' SPF record.  
Personally, I think it's silly to standardize additional ways to say the same 
thing.  Others may view it differently.

If it was me that seemed forceful to you, sorry.  SPF does give a domain owner 
a way to say that domain sends no mail.  I'm not sure how many ways we need 
to say that.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 07 Dec 2007 11:21:44 -0500

Hi Bill,

You do remember the original SSP specs had a clear "NO MAIL" policy 
option?  And its still possible now with the current SSP draft - declare 
a strict policy with no key, its a trigger a negative classification of 
the transaction A.K.A - rejection.

--
HLS

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 7 Dec 2007 17:21:56 +0100

Scott Kitterman wrote:

> I think it was also suggested (and the reason the WG chose not 
> to pursue it) that it was outside the scope of the WG charter.

It's hard to define what "sends no mail" actually means.  With
SPF you can cover "neither as HELO nor in MAIL FROM".  With PRA
you can say "not as PRA".  A draft trying something better could
still miss say Reply-To (no originator header field at all).

At the end we might arrive at "has no MX and either no SMTP at
its address, or no address at all" as definition.  And if folks
really want this they didn't show up on the SMTP list to fight
for a "mandatory MX at least for IPv6" in 2821bis to support
Doug's proposal in this direction here.  So far 2821bis didn't
adopt it, and we're in Last Call.

> None of those problems apply to a 'sends no mail' SPF record.

+1, a "v=spf1 -all" is simple.  However it doesn't cover a PRA
in my 4408 universe, no matter what 4406 said, or what the IESG
said about 4406.  Adding another SPF record "spf2.0/pra -all"
is no rocket science, but maybe Bill wants "really nowhere, even
in non-PRA header fields", and then he IMO needs "neither MX nor
IP" to determine it, not SSP or DKIM. 

> I'm not sure how many ways we need to say that.

Receivers not otherwise directly interested in SPF or PRA would
miss it, but they could use a service aggregating this source
(among others), e.g. in the form of a "no mail" black list.  

In other words I also don't see how adding SSP as another source
could help Bill, unless he intends to work on SIQ as aggregator.

 Frank

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 08:51:03 -0800

>   it's really sort of hard to take you or anybody else seriously.

Michael, you must be reading different postings than I am.

First, you seem to forget that an observation that something is broken is 
valid on its own.  It does not require that the speaker also propose a 
solution, merely that they make a sufficient case of brokenness.  Getting a 
proposed solution is always encouraged, but dismissing concerns that come 
independent of solutions is a good way to dismiss real issues.

Second, many postings have had concrete suggestions.  So, your saying "always" 
suggests that you are missing either entire messages or significant portions 
of their content.

d/
-- 

   Dave Crocker

---

From: Jon Callas <[email-masked]>
Date: Sun, 9 Dec 2007 12:33:31 -0800

It's been hard over the last few days to keep pace with all of the  
messages here, so my comments are on the basic notion that Dave had  
brought up.

I agree wholeheartedly with his basic premise, that SSP started off  
being modest, and has grown into the experimental and encompassing. I  
also agree that this isn't good.

So I'm going to pull back and describe how I think we got here.

Back in the days of DKIM-base, we started with considering what  
happens with broken signatures. We also believed that it would be not  
uncommon for a legitimate message to get its signature broken in flight.

When you consider what the receiver is supposed to do with a broken  
signature, the first suggestion is, "Well, do what you did before  
DKIM." This is legitimate, if unsatisfying. It is more unsatisfying  
the more that signatures can be expected to land unmolested.

Secondly, if you consider the senders for whom DKIM is most valuable  
- -- big phishing targets -- they want the illegitimate message thrown  
away.

This leads us to a nice confluence of events. The receiver has a  
message it isn't sure what to do with, and the sender can offer  
helpful advice. If the sender says, "I'd rather you threw away a good  
message than accept a bad one," then the receiver has a hint as to  
what to do with it. Don't bother trying to process it, just junk it.

Thus is born SSP, and thus is born the "I sign everything" policy.  
This is non-controversial, we all think it's great. As a receiver, if  
I see a broken signature, do an SSP check and if it says "sign all" I  
can now just throw the message with the broken signature away.

However, next comes an addition to that. If we assume there are  
active bad guys, they'll just send their bad messages with no  
signature. Consequently, we can solve this by redefining a broken  
signature to include messages with no signature. It doesn't take much  
of a stretch to consider no signature to be merely the most extreme  
form a broken signature. This way, we end up will all forged messages  
pretending to be from a signing domain to be dropped at the receiver.

This is undeniably a Good Thing. I support it, myself. However, it is  
also precisely the place where SSP jumped the shark. All the further  
mission-creep of SSP comes from this one seemingly-innocuous, well- 
meaning change.

This *radically* changes SSP in two fundamental ways:

(1) It changes SSP from being a protocol that governs the error  
condition of an optional protocol to being a protocol that governs  
*every* email received by *every* MTA.

(2) It changes SSP from being *guidance* that a sender gives to a  
receiver to a *mandate* that the sender gives to the receiver.

The first one is troubling for a number of reasons. When we started  
DKIM, we told the rest of the IETF that this was an optional  
protocol, you didn't have to use it, and so on. We also cooed softly  
at the people who worried about the increased DNS use, arguing many  
ways that this wouldn't dramatically increase the global load on DNS  
all that much.

While this addition (SSP check on every message) is certainly a Good  
Thing, it means that we've gone back on our word to the rest of the  
IETF. I think it could be argued that that this violates the DKIM  
charter, in spirit, if not in the letter.

The second one is much subtler. It's a principle of email sending  
that the receiver can do whatever they want, no matter how stupid.  
While it may be useful for the sender to offer hints and guidance to  
the receiver, the sender cannot mandate. While I don't know how, I  
see here the makings of an exploitable architectural flaw.

I think we need to take a big step back from SSP. We need to  
seriously look at all policies other than the original "sign  
everything" policy and discuss them thoroughly. We need to seriously  
look at that one little change and discuss how it changed, as Dave  
said, the very *paradigm* of SSP.

I offer as a suggestion that we issue an SSP document that describes  
only the basic broken-signature-only model of SSP with only the one  
policy (sign-all). After that, we look at enhancements to the model  
carefully. We seriously discuss whether they are outside the charter  
because of the effect it has on the global email infrastructure to  
turn DKIM from an opt-in protocol to a you-must protocol. We also  
seriously have to look at other policies to discuss their  
effectiveness along with their environmental effects.

	Jon

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 10 Dec 2007 17:51:07 +0100

Jon Callas wrote:
  
> If the sender says, "I'd rather you threw away a good message than
> accept a bad one," then the receiver has a hint as to what to do
> with it. Don't bother trying to process it, just junk it.

Unfortunately "first author" and "sender" are unrelated concepts.
DKIM can't pick the envelope sender because it's SMTP-agnostic.

After that decision PRA is the only existing algorithm to figure
out an entity that's likely the "sender", and PRA only picks the
2822-From address if there is no Resent-Sender, Resent-From, or
Sender.  It's also the only logical interpretation of (2)822(upd)
after ignoring the envelope sender address for whatever reasons.

> As a receiver, if I see a broken signature, do an SSP check
> and if it says "sign all" I can now just throw the message
> with the broken signature away.

Better don't, if the "first author" isn't the "sender".  That's
a design flaw in SSP, let's give the Sender ID folks the credit
that they got *this* right.
  
> While this addition (SSP check on every message) is certainly
> a Good Thing, it means that we've gone back on our word to the
> rest of the IETF.

The WG charter lists an early SSP draft as input, and that I-D
mentions a check of messages without valid originator signature.

> I think it could be argued that that this violates the DKIM  

I'd reject the appeal:  It's kind of obvious that checking SSP
in the presence of a valid originator signature is a waste of
bandwidth.  Of course receivers are free to check SSP *always*
if they want it as input for their decision to check DKIM.

> the sender cannot mandate

Especially some "first author" can't pretend to be the "sender"
if he's not.  But actually the I-D doesn't "mandate", it only
needs to trimmed.  E.g. no "bounce suspicious mails" recipe :-(

> I see here the makings of an exploitable architectural flaw.

Any redefinition of "originator" bypassing 2822upd cannot work,
it breaks the email architecture.  A mail Resent-From: me is a
mail from me, I'm the sender, and if I find a MUA supporting
this Resent-feature that breaks a DKIM signature of the "first
author" in this mail then I'm still the sender, and the "first
author" got no SSP-veto right over my broken MUA.  (That was a
theoretical example, actually I don't like the Resent-* feaure)

> We need to seriously look at all policies other than the
> original "sign everything" policy and discuss them thoroughly.

If SSP gets its definition of "originator" right, using the PRA
because nothing else will do (for DKIM).  Admittedly I'm lost
what "all deny" could be, the three other cases "all process",
"strict process", and "strict deny" could make sense.  

I'm not sure about "all process", is that like NEUTRAL, a kind
of "thank you" from the sender to the receiver for trying DKIM
and SSP, unfortunately in vain ?

> I offer as a suggestion that we issue an SSP document that 
> describes only the basic broken-signature-only model of SSP
> with only the one policy (sign-all).

IMO the basic model was and is "no valid originator signature".

If, as JohnL said, receivers decide to accept a mail based on
other indicators (trustwothy valid third party signature or 
whatever they like) they'd have no reason to check SSP at all,
in other words SSP doesn't need to talk about these scenarios:

SSP is for those who wish to check it, after they found no
valid originator signature.  Or before, if they wish to check
it always, or if they think "before" is faster because they
won't waste their time with DKIM if there's no "strict deny".

 Frank

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 11 Dec 2007 14:06:53 -0500

> directions for a situation that won't happen.

Sorry to chime into this so late, but I want to make sure I understand.
Given this:

SPP bankofamerica.com p=strict

From: [email-masked]
DKIM-Signature: i=@dkim.mit.edu
DKIM-Signature: i=@dkim.bankofamerica.com
Subject: Get a great rate today!

<body munged by mit that would cause bankofamerica signature to fail>

You'd accept the message?

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com

---

From: John L <[email-masked]>
Date: Tue, 11 Dec 2007 14:52:20 -0500 (EST)

> You'd accept the message?

That depends on what I think of dkim.mit.edu.  If they had a history of 
sending good mail, sure.  If not, probably not.

It's probably worth reminding people yet again that the point of DKIM is 
to reliably tie a message to a domain, so you can use that domain's 
reputation to evaluate the mail.  SSP doesn't change that.

This example also reminds us that unrelated to SSP, real world filtering 
can make good use of other sorts of info like realistic (i.e., not 
self-published) estimates of how likely various domains are to be phish 
targets.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 11 Dec 2007 15:25:27 -0500

> sending good mail, sure.  If not, probably not.

I don't know about others, but you can't base a world wide open standard 
protocol based on these extremely subjective isolated decisions, and 
thats even if YOU have a clue as well of who they are, which most of the 
time, you won't.

> reputation to evaluate the mail. 

So without Reputation, is DKIM useless?  Is this part of the DKIM-BASE 
specification?  Hmmmmmm, I think I did see a reference to that assertion 
some where... oh yeah, the off-list engineered Deployment draft 
entrenched with reputation considerations and hardly none for SSP:

    2.5. Filtering Software

    ...
    Unless a scheme can correlate the DKIM signature with accreditation
    or reputation data, the presence of a DKIM signature SHOULD be
    ignored.

Mind boggling!  It only makes you wonder why we have such a conflict here.

 > SSP doesn't change that.

SSP != REPUTATION

-- 
Sincerely

Hector Santos, CTO

---

From: Jon Callas <[email-masked]>
Date: Tue, 11 Dec 2007 14:41:35 -0800

On Dec 11, 2007, at 11:52 AM, John L wrote:

> That depends on what I think of dkim.mit.edu.  If they had a  
> history of sending good mail, sure.  If not, probably not.
>
> It's probably worth reminding people yet again that the point of  
> DKIM is to reliably tie a message to a domain, so you can use that  
> domain's reputation to evaluate the mail.  SSP doesn't change that.
>
> This example also reminds us that unrelated to SSP, real world  
> filtering can make good use of other sorts of info like realistic  
> (i.e., not self-published) estimates of how likely various domains  
> are to be phish targets.
>

I agree completely with John.

The original use case that Miles gave ages back was a message  
bouncing off of someone's alumni association.

It is not at all unreasonable to think that such a message could get  
mangled, and therefore re-signed. If an MIT alum gets their mail  
redirected, it would be normal, accepted operation that you'd accept  
the message.

	Jon

---

From: "J D Falk" <[email-masked]>
Date: Wed, 12 Dec 2007 20:31:15 -0500

Steve Atkins wrote:

> The first step would be a group consensus on what the threats are
> ("what SSP is supposed to be for"), or at least a superset of what
> most people think.

Actually, I think that's the LAST step.  My hypothesis is that different
types of signers and/or verifiers (different use cases) perceive
different threats.

Hector Santos wrote:

> they would be considered for SSP.

Thanks, this'll be a great starting point.  Now I just hope I can find
the time....

---

From: Steve Atkins <[email-masked]>
Date: Wed, 12 Dec 2007 17:42:49 -0800

> types of signers and/or verifiers (different use cases) perceive

Well, without knowing what threats SSP is supposed to mitigate, it's
impossible to start analyzing how well it does so. So identifying the  
threats
certainly can't be the last step, and I can't actually think of anything
that comes before that.

Where would you start?

Cheers,
   Steve

---

From: "J D Falk" <[email-masked]>
Date: Wed, 12 Dec 2007 21:01:25 -0500

+1

This will let us experiment and learn through real-world operational
experience, rather than continually rehashing the same arguments.

---

From: "J D Falk" <[email-masked]>
Date: Wed, 12 Dec 2007 21:01:14 -0500

Steve Atkins wrote:

>> Actually, I think that's the LAST step.  My hypothesis is that
>> different types of signers and/or verifiers (different use cases)
>> perceive different threats.
> 
> threats certainly can't be the last step, and I can't actually think
> of anything that comes before that.
> 
> Where would you start?

Dangit, Steve, we're agreeing again.  I'm going to start by documenting
the many different-yet-overlapping use cases & related threats.  The
only difference from your earlier statement is that I don't think we'll
ever have conesensus on The One True Threat Model; instead each
different-yet-overlapping user of DKIM & SSP will have
different-yet-overlapping concerns about each.

---

From: Mark Delany <[email-masked]>
Date: Wed, 12 Dec 2007 18:43:56 -0800

> experience, rather than continually rehashing the same arguments.

Plus One. I'm inclined to this approach if we can't reconcile the  
differences that appear to have stalled SSP progress.

Is there a common subset of SSP that most everyone agrees on?

Mark.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 12 Dec 2007 23:27:17 -0800

I have been avoiding this thread, because it does not apply to a
particular issue, but it seems to go on and on...

Jon Callas wrote:
>  messages here, so my comments are on the basic notion that Dave
> had brought up.
>
>  being modest, and has grown into the experimental and
> encompassing. I also agree that this isn't good.

What is the modest SSP that everyone speaks of?  The first SSP draft
that I know of is draft-allman-dkim-ssp-00, dated July 9, 2005, prior
to the chartering of the DKIM Working Group. It contains the
"unknown", "all", and "strict" policies (although they were known as
~, -, and ! respectively), as well as a "no mail" policy.  It not only
checks the local-part of the email address, it has a provision that
allows sender signing policy (as it was known then) to be expressed at
the user level.  It searches up 5 levels of hierarchy to protect
against sub-sub-sub-domain attacks.  It includes a reporting address
and a testing flag.

The only substantial thing that has been added is the handling tag.

In so many ways, SSP is much more modest now than before.

> happens with broken signatures. We also believed that it would be
> not uncommon for a legitimate message to get its signature broken
> in flight.
>
>  DKIM." This is legitimate, if unsatisfying. It is more
> unsatisfying the more that signatures can be expected to land
> unmolested.

By "do what you did before DKIM", I gather you mean that you consider
the signature not to exist.  If broken signatures are treated any
better than non-existing signatures, this invites attackers to attach
invalid signatures to messages.
>
> Secondly, if you consider the senders for whom DKIM is most
> valuable -- big phishing targets -- they want the illegitimate
> message thrown away.
>
> helpful advice. If the sender says, "I'd rather you threw away a
> good message than accept a bad one," then the receiver has a hint
> as to what to do with it. Don't bother trying to process it, just
> junk it.

This is the "handling" flag, which was just introduced in the latest
draft.

>  This is non-controversial, we all think it's great. As a receiver,
> if I see a broken signature, do an SSP check and if it says "sign
> all" I can now just throw the message with the broken signature
> away.

No, that's not what the "I sign everything" policy says at all.  Since
the message doesn't have a valid signature, SSP says the message is
Suspicious.  The verifier can use that information however it pleases.
>  signature to include messages with no signature. It doesn't take
> much of a stretch to consider no signature to be merely the most
> extreme form a broken signature. This way, we end up will all
> forged messages pretending to be from a signing domain to be
> dropped at the receiver.

Again, not dropped, unless you're talking about the handling tag.
>
> This is undeniably a Good Thing. I support it, myself. However, it
> is also precisely the place where SSP jumped the shark. All the
> further mission-creep of SSP comes from this one
> seemingly-innocuous, well- meaning change.
>

Application of SSP to only messages containing broken signatures has
*never* been proposed in any SSP draft.  To do so would create an
incentive not to deploy DKIM:  there would be the fear that
application of a DKIM signature might hinder delivery of messages,
because of the potential for breakage that would not exist for
unsigned messages.
>  receiver to a *mandate* that the sender gives to the receiver.

Again, you are confusing the practices with the handling tag, and even
the handling tag isn't a mandate.
> protocol, you didn't have to use it, and so on. We also cooed
> softly at the people who worried about the increased DNS use,
> arguing many ways that this wouldn't dramatically increase the
> global load on DNS all that much.
>
> While this addition (SSP check on every message) is certainly a
> Good Thing, it means that we've gone back on our word to the rest
> of the IETF. I think it could be argued that that this violates the
> DKIM charter, in spirit, if not in the letter.

I'd like to know what part of the charter you think this violates.

So, let me get this right:  We allow domains to optionally publish a
policy (practice) that says "I sign everything" but we don't even
check that when we get something that isn't signed.  How can that
possibly be useful?

>  While it may be useful for the sender to offer hints and guidance
> to the receiver, the sender cannot mandate. While I don't know how,

It's about as non-mandatory as I can think of making, other than
making it a non-normative implementation note (which of course I'll do
if the WG consensus says so).  Beyond that, we're in the "treat the
message (hint-hint, nudge-nudge) with prejudice" realm, which is more
dangerous than being more specific, as Scott Kitterman has noted about
SPF.

> everything" policy and discuss them thoroughly. We need to
> seriously look at that one little change and discuss how it
> changed, as Dave said, the very *paradigm* of SSP.

I would like to know *when* it changed, and then I would have context
for *how* it changed.
> describes only the basic broken-signature-only model of SSP with
> only the one policy (sign-all). After that, we look at enhancements
> to the model carefully. We seriously discuss whether they are
> outside the charter because of the effect it has on the global
> email infrastructure to turn DKIM from an opt-in protocol to a
> you-must protocol. We also seriously have to look at other policies
> to discuss their effectiveness along with their environmental
> effects.

SSP in no way turns DKIM from opt-in to you-must.   Domains that don't
publish SSP have their mail treated as non-Suspicious, regardless of
the presence or absence of signatures, which is the most favorable
category.

- -Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 12 Dec 2007 23:29:50 -0800

> certainly can't be the last step, and I can't actually think of anything

RFC 5016.

-Jim

---

From: Mark Delany <[email-masked]>
Date: Thu, 13 Dec 2007 00:02:07 -0800

On Dec 12, 2007, at 10:36 PM, Jim Fenton wrote:

> Mark Delany wrote:
>>>> describes
> I thought we had documented it in RFC 5016.

 From an IETF procedural perspective that may well be so - my  
question is more about whether the sentiment of the WG matches 5016?

It's purely a strawman, but I sense that sub-setting a core might  
help us move forward. I am likely wrong, but it's a question I'd like  
to ask.

Mark.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 13 Dec 2007 00:37:14 -0800

Mark Delany wrote:
> From an IETF procedural perspective that may well be so - my question
> is more about whether the sentiment of the WG matches 5016?

That's a good question.  5016 went to Working Group Last Call in March;
the only substantive issue is whether it should include information on
application of multiple signatures by a domain.  But I suppose that
since the draft was Informational everyone was excused from commenting
at that time.
>
> It's purely a strawman, but I sense that sub-setting a core might help
> us move forward. I am likely wrong, but it's a question I'd like to ask.

My sense from reading the list traffic is that there are a lot of
differing opinions on what the subset might contain, with results
ranging from making SSP vaguely useful to actively hostile to DKIM
deployment.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 12 Dec 2007 22:36:37 -0800

(in other words:  -1 to above approach)

-Jim

---

From: Mark Delany <[email-masked]>
Date: Thu, 13 Dec 2007 01:06:03 -0800

>> help

So does that mean you are skeptical about the existence of a broadly  
acceptable subset of SSP or merely that there might be contention  
over what that subset is?

Given your participation level, I readily bow to your greater  
knowledge of WG sentiment, but it seems to me that if there is no  
acceptable subset, then you are in effect saying that the current SSP  
is the minimalist possible functional spec. Is that what you are  
saying? That the current SSP is indivisible?

In any event, I see Jon's suggestion as a divide-and-conquer  
approach. If it moves us forward, I'm for it because at this stage I  
suspect that progress is as important as substance.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2007 05:43:39 -0800

...
> ranging from making SSP vaguely useful to actively hostile to DKIM

Jim,

I think you did not try to answer Mark's question.  He didn't ask about the 
range of individual opinions, which is the answer you gave.  He asked about a 
common subset that "most everyone agrees on".  That permits leaving out stray, 
outlier views.   (And by the way, I don't recall seeing a recent posting 
hostile to DKIM deployment.)

In other words, Jim, he asked a classic rough consensus question.

In fact my own reading of postings does show a rather solid common subset, 
quite strongly.  Just look for references to phrases like "not controversial".

d/
-- 

   Dave Crocker

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 13 Dec 2007 14:55:54 +0100

Jim Fenton wrote:

> we're in the "treat the message (hint-hint, nudge-nudge) with
> prejudice" realm, which is more dangerous than being more
> specific, as Scott Kitterman has noted about SPF.

Some folks including me disagree very strongly with this opinion:

* SPF is very strict about not dictating any "receiver policy",
  and in one case (PermError) this strict approach even caused
  a now confirmed erratum re-inserting the lost extended error
  code for receivers wishing to reject PermError.

* For obvious reasons checking SPF works best at the border MTA
  in an SMTP session before DATA.  Getting a FAIL at this point
  receivers obviously better reject the mail, otherwise they'd
  later be forced to drop it (bouncing FAIL is no sound option).

* Some folks discussed here under the tag "high value phishing
  targets" proposed a "DWIM FAIL" introducing "receiver policy"
  REJECT for this "harderfail" or whatever it is.  The proposal
  wasn't accepted, as it would water down millions of policies
  with an ordinary FAIL, also of course hoping for a REJECT in
  (rare) cases of "clueless receiver checked behind his border".

* This reasoning is simple, obvious, and valid for SPF, it's not
  necessarily also good for PRA or SSP.  If you want "DWIM FAIL"
  in SSP go for it, but don't say that it's lacking in SPF.

 Frank

---

From: Jim Fenton <[email-masked]>
Date: Thu, 13 Dec 2007 06:18:29 -0800

Dave Crocker wrote:
> I think you did not try to answer Mark's question.  He didn't ask
> about the range of individual opinions, which is the answer you gave. 
> He asked about a common subset that "most everyone agrees on".  That
> permits leaving out stray, outlier views.   (And by the way, I don't
> recall seeing a recent posting hostile to DKIM deployment.)
>
> In fact my own reading of postings does show a rather solid common
> subset, quite strongly.  Just look for references to phrases like "not
> controversial".

It is not my place to make a call on the consensus of the WG, but my
read on recent discussion is that the sentiment is diverging rather
severely from 5016.

As I said in http://mipassoc.org/pipermail/ietf-dkim/2007q4/008646.html,
application of SSP to only messages containing broken signatures brings
with it the fear that application of a DKIM signature might hinder
delivery of messages, because of the potential for breakage that would
not exist for unsigned messages.  This is the proposal that I see as
being actively hostile to DKIM deployment.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2007 07:12:17 -0800

Jim,

Mark asked a question and you posted a response that was not a response, but 
instead referred to diversity of views.  If you had something in mind other 
than attempting to claim that Mark's query was not going to get a successful 
resolution, what was it?

Given your followup response, it seems odd for a document author to post such 
a note, since it isn't clear how it aids working group discussion seeking 
resolution of an open question.

As for 5016, you are highlighting one of the problems with calling such 
documents "requirements" since slavish adherence to its desires eliminates any 
benefits from later insight.

d/
-- 

   Dave Crocker

---

From: [email-masked] (Wietse Venema)
Date: Thu, 13 Dec 2007 10:24:59 -0500 (EST)

> because of the potential for breakage that would not exist for

An excellent reason to treat "no signature" as "bad signature"
and vice versa.

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Dec 2007 09:21:36 -0800

Dave Crocker wrote:
> documents "requirements" since slavish adherence to its desires 
> eliminates any benefits from later insight.

What you call "slavish", I'd characterize as water under the bridge.
What you seem to be saying is that any single person should be able
to reopen with no barrier every bit of consensus that was achieved
in rfc5016. I'd like to hear what the actual barrier ought to be
from the chairs.

		Mike

---

From: Hector Santos <[email-masked]>
Date: Thu, 13 Dec 2007 12:56:11 -0500

Michael Thomas wrote:
> Dave Crocker wrote:
>> As for 5016, you are highlighting one of the problems with calling 
>> such documents "requirements" since slavish adherence to its desires 

+1.

-- 
Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Thu, 13 Dec 2007 13:12:44 -0500

> An excellent reason to treat "no signature" as "bad signature"

And in theory, this is acceptable.

But there is still a sub-set of hard cold facts that still allow for 
detection of 0% false positive fraud of unauthorized usage.

The irony in all this is that those who don't want SSP to a play role 
because it promotes policy driven controls, are intentionally blind to 
the idea that DKIM-BASE is inherently based on subjective policy driven 
controls. From my standpoint, I view some of these unverified DKIM-BASE 
inherent policies as security threats.  There is no dispute that this 
DKIM-BASE inherent policies exist and presents an security concern.  To 
ignore it will be irresponsible.

I don't think SSP is hostile to the DKIM deployment, but helps its 
deployment because it will at least provide some avenue of protection 
for domains and receivers who don't wish to get into 3rd Party Trust 
Service dependencies where there is no standard definition and 
absolutely no guarantee of consistent results.

So no, SSP is not hostile to DKIM deployment. However, I will note that 
is hostile toward those who are betting their hopes on 3rd party trust 
concepts.

-- 
Sincerely

Hector Santos, CTO

---

From: [email-masked] (Wietse Venema)
Date: Thu, 13 Dec 2007 13:48:09 -0500 (EST)

> absolutely no guarantee of consistent results.

By the way, speaking of trust and reputation services:

SSP does not say that my bank's domain belongs to a real bank.

SSP does not say that a criminal's domain belongs to a fake bank.

SSP does not help me decide which bank is real.

If anything requires a reputation service, then it is SSP not DKIM.
DKIM can manage just fine with a local whitelist.

I am aware that credibility on this list is inversely proportional
to the number of messages posted, and I will post corrections like
this infrequently.

	Wietse

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2007 11:58:42 -0800

> What you call "slavish", I'd characterize as water under the bridge.

Were mine the only voice raising concerns, that might be appropriate.

> in rfc5016. I'd like to hear what the actual barrier ought to be

Since I didn't say or mean anything close to your interpretation, I can't 
guess what prompted you to invent it.

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Dec 2007 13:27:53 -0800

Eric Allman wrote:
> Actually, we (or at least, I) started thinking about unsigned messages 
> first, since it seemed pretty obvious that senders that wanted to sign 
> everything would want recipients to be able to make use of that 
> information.  I didn't originate this concept: it came from DK (RFC 4870).

   It was also part of the original IIM as well. The original IIM
   considered both lack of valid first party signature and no
   signatures at all as identical. 4870 is seemingly a little vague
   on this point. In any case, this is hardly some new thing snuck
   in while nobody was looking. The concepts have been out there
   for 4 years now.

		Mike

---

From: Hector Santos <[email-masked]>
Date: Thu, 13 Dec 2007 16:57:36 -0500

Eric Allman wrote:
> 
> --On December 9, 2007 12:33:31 PM -0800 Jon Callas <[email-masked]> wrote:
> 
>>                                    After that, we look at
>> enhancements to the model   carefully. We seriously discuss whether
>> they are outside the charter   because of the effect it has on the
>> global email infrastructure to   turn DKIM from an opt-in protocol
>> to a you-must protocol. We also   seriously have to look at other
>> policies to discuss their   effectiveness along with their
>> environmental effects.
> 
> I'm not sure if you intentionally changed the topic from SSP to DKIM 
> here.  Regardless of the details of SSP, DKIM remains optional.  For 
> that matter, receivers don't need to do any scanning of their mail at 
> all today, and that isn't going to change.  I certainly hope that DKIM 
> information will become valuable enough that most receivers will /want/ 
> to consult it, and I hope that they will care enough about the 
> information that senders care to provide in SSP to use that as well.

+1.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Thu, 13 Dec 2007 17:12:05 -0500

+1

> DKIM can manage just fine with a local whitelist.

I think SSP is part of the non-repudiation process for the DKIM domain 
in how it expected his mail was to be analyzed by the receiver.

I also think the assessment is a different layer that can apply with or 
without DKIM or DKIM/SSP and before or after.

The efforts to "tie" the valid signature with a reputation service is a 
worthy endeavor, however, are implementation and security concerns 
around this model mostly associated with anonymous transactions where is 
no "rap sheet" yet established.

So in view, DKIM + SSP + REPUTATION all compliment each other.

-- 
Sincerely

Hector Santos, CTO

---

From: John Levine <[email-masked]>
Date: 13 Dec 2007 23:01:33 -0000

>What is the modest SSP that everyone speaks of?

Based on what I've seen, it's a cut down version of section 2 that
says how a sender can sign to match the Author domain, and a cut down
version of section 4 that says how you publish and fetch records
that contain "unknown" and "all" policies.

Those parts seem to be generally unobjectionable.  Beyond that, it's
off into the swamp.

This probably doesn't match all the stuff in 5016.  Sorry.

---

From: Damon <[email-masked]>
Date: Thu, 13 Dec 2007 18:10:13 -0500

> SSP does not say that my bank's domain belongs to a real bank.

If I am the bank, then I can ensure that messages purporting to be
from me are from me and nobody else.

> SSP does not say that a criminal's domain belongs to a fake bank.

I know what banks I bank with. Someone at a fake bank with a valid ssp
and dkim will still likely be ignored. I know that at least MY bank
uses SSP and DKIM and I can trust that it is from them.
> SSP does not help me decide which bank is real.

Again, I know who my bank is. If I get a message from BoA or a message
from the First Mountain Trust of Namibia, I believe I would not have
any trouble distinguishing between the two.
> to the number of messages posted, and I will post corrections like

I am not oblivious to what you are trying to say, but I believe that
this will at least keep us going in the right direction and give us
operational folks some tools with teeth. I am sure that when we build
it, they will come and reputation services will eventually part of the
tools. I just don't think it belongs in the draft.

Regards,
Damon Sauer

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2007 19:31:43 -0800

Jim,

Normally, a requirements doc like 5016 comes after a problem description, not 
before.  A threats analysis is a problem description.

I read Steve's query as being about threats, not requirements.

As for RFC 4686, it says very little about the threats that SSP is expected to 
mitigate.

d/

-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Dec 2007 13:53:52 +0000

> in rfc5016. I'd like to hear what the actual barrier ought to be

I've not talked to Barry about each specific issue in the tracker,
but our general approach is that the WG arrived at rough consensus
on 5016 and so anything else needs additional justification.

That includes additions (e.g. handling tag) as well as other
changes.

I don't have a precise definition of additional justification, but
I will talk to Barry to try work something out.

Meanwhile, as soon as I get some time to correlate the issues in
the tracker with our high-volume mail traffic (next week earliest),
I'll try to start us out on declaring as closed issues where we do
appear to have sufficient consensus.

Stephen.

---

From: [email-masked] (Wietse Venema)
Date: Fri, 14 Dec 2007 09:37:07 -0500 (EST)

> any trouble distinguishing between the two.

I don't expect burglars to put "WARNING: BURGLARY IN PROGRESS"
signs on side walks.

Likewise, I don't expect that criminal banks will announce their
intentions in such an obvious manner as you are suggesting.

As for your assertion that you know who your bank is, can you pick
out the real bank from the list posted here:

http://mipassoc.org/pipermail/ietf-dkim/2006q3/005884.html

What is the relevance of this for the current effort? I have nothing
against an SSP that says what mail if any a domain signs or sends.
Like many, I would use that to throw away some mail. But it would be
a mistake to position SSP as the solution for email phishing.

	Wietse

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Dec 2007 07:59:19 -0800

Wietse Venema wrote:
>> Again, I know who my bank is. 
...
> out the real bank from the list posted here:

Just so no one misses this fundamental point:

    Most people do *not* know the domain names of the companies with send them 
legitimate mail.  Added to this is that most people do not inspect the domain 
name and they can be swayed by the contents of the From display string, the 
Subject line, or the body, independent of what is in the From field domain name.

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Fri, 14 Dec 2007 08:29:21 -0800

> a mistake to position SSP as the solution for email phishing.

I agree with the above statement.  At the same time, I think it's
appropriate to consider the potential for technologies like SSP to
reduce losses due to phishing.  It isn't necessary to "solve" the
problem to produce a tangible benefit.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Dec 2007 08:40:48 -0800

> problem to produce a tangible benefit.

Right.  So let's explore what current problems specific functions in SSP will 
mitigate.

Folks who are proponents of particular SSP features should document specific 
threats and specific SSP feature(s) that will mitigate them.

An essential part of such exercise is to explain why the mitigation is 
strategic.  That is, why will it not be easy for attackers to work around the 
SSP mechanism and achieve equivalent attack success.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Fri, 14 Dec 2007 12:03:14 -0500

Dave Crocker wrote:

> Right.  So let's explore what current problems specific functions in SSP 
> will mitigate.
> 
> Folks who are proponents of particular SSP features should document 
> specific threats and specific SSP feature(s) that will mitigate them.
> 
> strategic.  That is, why will it not be easy for attackers to work 
> around the SSP mechanism and achieve equivalent attack success.

I believe the analysis and chart just posted and provided in:

   http://mipassoc.org/pipermail/ietf-dkim/2007q4/008702.html

Serves as basis in analyzing the DKIM-BASE Protocol Model and how SSP 
plays a major role in the non-repudiation process.  In additional, it 
shows where failures are still a fundamental problem in DKIM-BASE.

-- 
Sincerely

Hector Santos, CTO

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Dec 2007 17:32:47 +0000

> specific threats and specific SSP feature(s) that will mitigate them.

I think that'd be useful.

Of course, people who aren't proponents can also document specific
threats, and I'd be interested in a few examples that aren't included
in 4868 or the security considerations of the ssp-01 I-D (if I missed
something in a recent posting a reference would be fine). I don't
doubt that some such threats exist, but I don't recall seeing anything
specific on this so far.

> around the SSP mechanism and achieve equivalent attack success.

Modulo look-alike domains I guess? (There's text in 4868, 4.2.1 about
that btw.) I don't think anything in SSP can mitigate that threat.

S.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Dec 2007 09:46:53 -0800

> that btw.) I don't think anything in SSP can mitigate that threat.

What do you mean "modulo"?

Note that "explaining why the mitigation is strategic" requires more than 
citing a threat.

In any event...

While you have just expressed your own opinion about SSP's ability to mitigate 
this attack - and fwiw I agree - I am not sure that there is a clear consensus 
about this among working group participants.

In the context of ensuring a broad base of shared understanding and agreement, 
neither your view nor mine about the particulars matters very much.  Getting 
group consensus on the details is what matters and that begins by stating the 
details.

Hence the desire to document threats and mitigations for particular SSP 
functions explicitly.

d/
-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Fri, 14 Dec 2007 09:52:56 -0800

> that btw.) I don't think anything in SSP can mitigate that threat.

In that instance the threat might be "A well informed malicious sender
misleads recipients about who the author of the mail is".

SSPs answer to that would be an ability for some receivers to
identify that an unsigned email with the byte-for-byte identical
email address in the From field should have been signed, so
is a forgery.

The analysis would touch on false positives due to signature
breakage, that byte-for-byte comparison is not adequate to
protect a visible brand, that the email address isn't even displayed
in many MUAs and so on.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Fri, 14 Dec 2007 10:10:14 -0800

> protect a visible brand, that the email address isn't even displayed

   Any sort of analysis needs to keep in mind that although SSP thwarts
   a relatively narrow set of attacks in and of itself, it could well
   be useful in conjunction with various phishing filtering heuristics,
   reputation, and the like which are all outside of the scope of SSP.
   Not taking that into account -- or ruling any such possibilities out
   of scope -- is an unfair and impossible barrier for *any* protocol the
   IETF might produce.

		Mike

---

From: Steve Atkins <[email-masked]>
Date: Fri, 14 Dec 2007 10:19:57 -0800

>  of scope -- is an unfair and impossible barrier for *any* protocol  

Absolutely.

If the value of an SSP feature is only shown when it is combined
with something else, then that something else needs to be considered
when evaluating the efficacy of mitigation provided by the combination.

But in those cases an SSP feature needs to add some value to
the approach to justify it's existence. For example, phishing can
be mitigated using a list of domains that are valid sources of, for
example, financial services data and combining that with SSP
derived data.

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Dec 2007 10:21:42 -0800

>   of scope -- is an unfair and impossible barrier for *any* protocol the

Yup. An analysis which makes these details concrete would permit consideration 
of the actual long-term benefit of the mechanism.

It would be nice to have concrete details.

d/

-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 14 Dec 2007 21:18:20 -0000

>Modulo look-alike domains I guess?

Depending on the threat, there's all sorts of likely workarounds.  For
example, as I noted a few days ago, many MUAs show the From: line
comment rather than the address.

I also look forward to learning what problem it is that we're trying
to solve here.

R's,
John