[ietf-dkim] Collection of use cases for SSP requirements

["Patrick Peterson" <[e-mail]>]

3 months and 1300 mailing list posts ago, I wrote that I was going to
survey some senders on SSP use cases and report results back to the
list. At long last, here are the results.

We reached out to a large set of senders who are either heavily phished
or have very valuable online brands they want to protect. Our results
are therefore highly biased toward these organizations. They send high
volumes of legitimate email using heavily phished domains. They will be
among the earliest enterprises to deploy with aggressive SSP policies.
All of these senders understand the inherent limitations in
authenticating a domain used in email (cousin domains, friendly names,
lack of client support, etc). They understand DKIM is not a 'silver
bullet' solution but still believe DKIM offers a technology that over
time will help reduce their current problems of domain spoofing.

Developing SSP is very different from developing DKIM. DKIM is a
technical challenge while the challenge of SSP is primarily to determine
what senders want to communicate to receivers and what receivers want to
know about senders policies/practices. SSP should provide a vocabulary
to senders that meets their needs and is useful to receivers -- this is
the most important requirement imho. Separation of SSP Requirements from
SSP is very helpful.

Here is their feedback. I have also requested that they join the list
and provide direct input. This is *requirements* input, not proposing a
solution. And if anyone attended the recent MAAWG conference in Toronto,
this is the same information I presented to ISPs.

Requirement #1. More aggressive practice options
Senders are concerned the current options aren't aggressive enough to
cause change in how spoofed email is handled. Without such a change
implementing DKIM is of little value to them.

The senders want to stop domain spoofing from impacting their brand and
customers. They want more aggressive policy statements that will more
aggressively encourage the receiver to drop spoofed email. It may be
some time before they are 100% signing and common errors that cause
signature failure for their mail are eliminated but they are focused on
realizing this as soon as possible. When this happens, they want to be
able to request that receivers drop signature failures or unsigned
email. For some, the cost of phishing is so high and some day the risk
of dropping messages will be so low that their inability to state a
stronger policy will impact their ability to reduce the impact of domain
spoofing.

Another way to state this requirement is that there is a difference
between, 
- I sign all email, and
- I sign all email, treat unsigned or invalid signature with suspicion,
and,
- I sign all email AND have enough confidence in the reliability of
signatures AND the risk of allowing spoofed email is high enough that I
choose to accept the risk and therefore state that receivers should drop
unsigned/invalid signature email.

Requirement #2. I send no email.
Many senders have a large number of domains that are never used in
email. They want to be able to state this unambiguously. To the senders
I surveyed, the 'I send no email' policy is a unique case from the other
cases. I asked if they wanted this in addition to the SPF/SIDF '-all'
policy and they universally said yes. 

Requirement #3. Feedback of invalid signature/unsigned mail
Senders are concerned that the #1 item that will prevent them from
moving to aggressive practices is the inability to identify errors.
Errors on their part (failure to implement signing, improper signing),
receiver errors (noncompliant implementations of DKIM validation) or
anything else that Murphy's Law says will happen. They would like a
feedback mechanism to be defined that provides this feedback. Defining
this mechanism does not require it to be implemented by any receiver;
failing to define this mechanism makes it impossible to implement easily
for anyone. (Without going too far down the solution avenue, senders
felt one possible solution to receiving an excessive number of
invalid/unsigned feedback emails during a large-scale spoofing attack
was to state that they only wanted feedback for emails which originated
from their IP space as defined by their SPF record. Not a complete
solution as envelope sender not equal From: and mailing list traffic
doesn't originate from their IP space, but many felt this might be a
good compromise solution.)

Please consider these inputs and (hopefully) look for more direct input
shortly. I hope these SSP requirements are useful for the SSP
Requirements doc. I am unable to attend the IETF session today but I'm
sure it will be a lively discussion.

I've excerpted the most relevant sections from SSP Requirements and SSP
below with some edits to be more specific about possible changes.
Changes prepended with >>>>

http://www.dkim.org/specs/draft-ietf-dkim-ssp-requirements-02.html

4.1.  Problem Scenario 1: All Mail Signed with DKIM
<snip>
   3. A provides information that it signs all outgoing mail, but places
no expectation on whether it will arrive with an intact signature.
   4. B could use this information to bias its filters such that it
looks somewhat more suspicious.
>>> This is great for senders that sign their email but don't have
confidence of high rate of receiver validation or that aren't too
concerned with domain spoofing.

4.2.  Problem Scenario 2: Illegitimate Domain Name Use
<snip>
   3. A provides information that it signs all outgoing mail, but places
an expectation that it should arrive with an intact signature, and that
the receiver should be suspicious if it does not.
   4. B could use this information to bias its filters such that it
looks much more suspicious.
>>>> A set of senders really want B to drop this email. Giving them to
vocabulary to state this is their desire. ISPs are of course free to do
as they see fit, but providing them with more granular information is
useful.

4.3.  Problem Scenario 3: Domain Sends No Mail
A domain may not intend to send mail at all. In such a case, it could be
advantageous for a receiver to know the domain's intent and would be
likely to treat such mail very suspiciously.
>>>> Option to state "drop" vs "very suspiciously" desired.

6.3.  Practice and Expectation Requirements
<snip>
9. Practices and Expectations MUST be presented as an information
service from the signing domain to be consumed as an added factor to the
receiver's local policy. In particular, a Practice or Expectation MUST
NOT mandate any disposition stance on the receiver.
>>>> It's possible to state a desired disposition (drop) without
mandating a disposition stance. An ambiguous expectation and a binary
expectation is different from an expectation and a mandate.

http://www.dkim.org/specs/draft-allman-dkim-ssp-02.txt

4.2.  Record Syntax
<snip>
   p= Outbound signing practices for the entity (plain-text; OPTIONAL,
      default is "unknown").  Possible values are as follows:

      unknown  The entity may sign some or all email.

      all  All mail from the entity is signed; unsigned email MUST be
         considered Suspicious.  The entity may send messages through
         agents that may modify and re-sign messages, so email signed
         with a Verifier Acceptable Third-Party Signature SHOULD be
         considered non-Suspicious.

      strict  All mail from the entity is signed; messages lacking a
         valid Originator Signature MUST be considered Suspicious.  The
         entity does not expect to send messages through agents that may
         modify and re-sign messages.
>>>> Notch above 'Suspicious' desired

            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.
>>>> Strict signing not equal to 'does not sign' use case to many
senders.

pat

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html