[anti-spam-wg] Survey on potential use of IETF's Sender Signing Practices (SSP) specification.

[Dave Crocker dhc@localhost]

Hello.

I am sending this to a number of anti-abuse mailing lists, in order to solicit
comments on the likely use of a new technical specification.  Its development
has been underway for sometime and is believed to be close to completion,
which is expected to result in IETF standardization.

The survey is based on the latest draft of SSP:

   <http://dkim.org/specs/draft-ietf-dkim-ssp-01.html>

however the Summary, below, is provided so that you do not have to read the
technical specification, in order to answer the questionnaire.

In particular, comments are sought from those running anti-abuse filtering
engines -- as an independent service or as part of a larger service such as a
general purpose ISP.  Imagine that the capabilities you read about, below,
have been standardized by the IETF and are available today.  Then consider the
questions that follow the summary.

Please note that this survey is not asking about use of DKIM message signing.

The survey pertains *only* to SSP.

Please send your responses to me privately. The survey results will not show
the identity of any respondent.  However I need to know who send responses in,
for my own, informal validation...

Thanks!

/d

ps. I am posting this individually, so as to avoid the problem of replies to
cross-posting.  Apologies if you receive it more than once.



SSP Summary Description
=======================


The IETF's DKIM working group has followed its specification of a base method
for associating a responsible identity to an email, via cryptographic signing,
with a draft, titled 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 permits a potential signer -- that is, the owner of a domain
name -- to publish an SSP-specific DNS record -- a 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 author's mailbox
address -- the rfc2822.From <addr-spec> portion of an address -- in a received
message.

The draft cites the rfc2822.Sender field as a preferable choice, over From,
but notes "the large number of deployed Mail User Agents that do not display
the Sender header field value argues against that."

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 problematic uses of a domain name,
specifically related to use of the email address in a message's RFC2822.From
field <addr-spec>, where the use cannot be validated as acceptable.

SSP does not seek to deal with other identity fraud, such as in the
human-readable RFC2822.From <display-name>, the Subject field, or in the
message body, or any use of "cousin" domains that can be confused with a
target domain. Unauthorized or intentionally confusing domain names and
addresses -- or other deceptive text -- can appear in any of these places and
will not be prevented or detected by use of SSP.

SSP is motivated by a desire on the part of message senders, to inform message
recipients about constraints on the senders' practices.  The premise is that
receivers with this additional information will be able to detect, and
possibly reject, a class of mail that cannot be verifies as legitimate. At
best, the mechanism is approximate, in that a legitimate message might begin
with a legitimate signature, but then have the signature get broken during
transit. When SSP is used, such messages will be treated by the recipient as
exceptions.

The current SSP draft provides for two basic conditions which will trigger a
query:

   1. Unsigned message.  When a receiver gets a message that has no DKIM
signature, they can query the DNS for an SSP record that is associated with
the domain name in the (first) rfc2822.From field header mailbox address.

   2. Signed message.  When a receiver gets a message that is signed, but
which with the identity on behalf of which this message is signed -- the
signature's i= parameter -- as different from the (first) address in the From
field, then perform the SSP query, described in step 1.

The publisher of an SSP record can say that:

   1. All mail that they send is signed by them

   2. All mail that they send is signed by them and they do not send mail via
intermediaries -- called "third parties" -- such as mailing lists that might
modify and re-sign the message.

Messages that fail an SSP analysis are treated as exceptions. The publisher of
an SSP record may request that exceptional mail be treated to:

   1. Further consideration, where the exception status is only one factor in
determining handling.

   2. Rejected.

SSP also permits the publisher to declare that the record applies to all of
its sub-domains, although there is a DNS limitation on reconciling deeply
nested sub-domains with this record.

The SSP specification defines a 10-step "check procedure" that is a decision
tree for performing SSP analysis.

As an example of implications, the SSP rejection semantics would mean that a
confirming site would reject a message that has a broken author signature,
even if it still had a valid signature by an operator with a good reputation.

Given that adoption of a new mechanism, like DKIM's base signing, takes many
years, adoption by any random sender/receiver pair is unlikely for many years,
absent prior arrangement.  So most publishers of SSP records will be sending
to sites that are not checking them.  Equally it should be assumed that
receivers will almost always obtain a failed SSP DNS query, for every message
with a new (un-cached) domain name in the From field.




SSP SURVEY QUESTIONNAIRE
========================


1. What type of organization are you responding for?

   (Please describe whatever is appropriate.  Examples include: ISP,
    anti-abuse filtering service, anti-abuse consulting service...)



2. Your influence on the organization's decision-making for this capability

   [ ] a. I will make the decision

   [ ] b. I expect to influence the decision

   [ ] c. I must implement the decision (I have to live with the
          decision made by others...)

   [ ] d. Other (please describe)



3. Understanding of the above Summary Description

   [ ] a. I believe I fully understand the Summary and the capabilities
          it describes

   [ ] b. I believe I fully understand, but want to make sure

          (Please state your assumptions, questions or the like,
          in Comments.)

   [ ] b. I do not fully understand the summary

          (Please explain what is confusing, in Comments)

   Comments:



4. Relevance and Value

       a.  Please describe what abuse problems you expect SSP to
           eliminate, reduce, or assist in dealing with.



       b.  Please explain how you expect SSP to have these desired
           effects. That is, what specific changes do you expect it
           to cause or permit?



4. Expectations for using the described capabilities described in the Summary

   [ ] a. I expect to use all of the capabilities

   [ ] b. I expect to use some of the capabilities

          (Please state which ones and why, in Comments. Please explain
           which ones you expect not to use, and why.)

   [ ] c. I expect to use none of the capabilities.

          (Please explain why, in Comments.)

   Comments:



5. Please add any other comments you wish to

   Comments:



Many thanks for you time and diligence.


--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net