[ietf-dkim] A perspective on what SSP is attempting

[Hector Santos]

Dave Crocker wrote:
 > Among the various discussions I've had today, one
 > comment about SSP struck me as worth wider consideration:
 >
 >      SSP is one organization's attempt to tell another
 >      what it should do with mail that is from a third
 >      organization.

We can always get in trouble with the semantics David.

I would rather view it as an organization's exposure using an world wide 
database (DNS) of its DIM policy on how its domain is being used with DKIM.

Please try to consider this, not saying you have to agree, just please 
do take some of your time to consider these points. I apologize for the 
length, but I hope I can summarize many of the key issues, discussions 
and consensus which included specifically addressing your statement 
above.  Of course, this is all my opinion, but I hope I am on par with 
the major issues and consensus reached.

Consider the following:

   - Organization ABC may desire that its email domain property is
     exclusively used only by the organization. There is no
     outsourcing,  no clearing house, and it has a company policy
     with provisions that mandates domain brand protections
     by restricting employee external usage of its domain for
     non-company related  communications.

     All mail is DKIM signed by the domain. No exception.

   - Organization XYZ may desire that its email domain property is
     exclusively used only by the organization and exclusively
     with a 3rd party service (3PS) vendor for distributing special
     mail as well.  The company policy mandates its domain
     brand be protected by restricting employee external usage
     of its domain for non-company related communications, and that
     all mail with the company domain must be signed by its internal
     mail operations or by the exclusive 3PS service vendor.

     All mail is DKIM signed by the domain or by the 3PS vendor.
     No exception.

   - Such organizations, with the available technology, have a
     expectation that implementing this technology would help in
     reduction the today's obvious problematic fraudulent usage.
     They would prefer that any compliant receiver able to detect
     fraudulent usage with 0% false positives, and *classified" it
     for rejection.

Now, please consider these two very important points. They are vital 
considerations:

   - Consider that RFC 4871 places a new "responsibility" on the
     domain owner for signing mail with DKIM. As such, there is
     also inherent and expected equal responsibility on the DKIM
     receiver to assist in the disseminating process.

   - The key general industry problem is the handling unauthenticated
     x821 anonymous, unsolicited message transactions. If there is no
     information about the sender, it is currently difficult, with no
     standard protocol, to make any assessment, good or  bad, about
     the sender and/or domain.

So what does that mean?

It means, at least for a system like us, and I believe many work in the 
similar manner, if the 2821 session is authenticated, there we skip most 
or all filtering concepts.  DKIM is very likely to fall in this category 
as well.  I believe the main reason is because we have more faith in the 
legitimacy of an x821 authentication based transaction.  That faith is 
increased with local white listing.  There is still methods to detect 
abuse by compromised authenticated users, but for the most part, these 
additional filters are generally skipped or reduced to possibly only AVS 
scanning with authenticated sessions.

So this is mostly about dealing with the anonymous sender.

How do we change the anonymity of the sender?

Well, first we need to decide "who is the sender?"  This seems to be a 
source of contention in this group.

Regardless of who or what is the sender, the commonality is the 
fundamental concept of finding the "anchor" for the discovery process.

We, as a group, decided the established universal entity for the 
authorship of the message is the x822.From address domain and that would 
be the "anchor.".  I believe a main reason is that required by x822 to 
be present, especially when there no other markers, such as a DKIM 
signature, in the message.

We can not guarantee the Sender: address will be there and if we wanted 
to use this, then I believe we are forced back to a x821 design because 
if missing, the only reasonable substitute is the Return-Path:.

       Note: In past SPF/Sender-ID analysis input for the FCC, I
       found for ~80-84% of the time, the following domain
       association holds true in non-list server environments:

         x821.MailFrom == x822.From [== x822.Sender if present]

       With such a result, it reflected the potentially higher
       payload overhead with Sender-ID vs SPF operations with
       no payload overhead.

So the From: address is the most reasonable and most practical anchor 
available to today for  an unsolicited, anonymous, including unsigned 
transaction to perform a SSP lookup.

If a domain has a SSP policy that says "No 3rd party" i.e., no tampering 
is expected, then IMO, that should be view as a 0% false positive 
indicator for the receiver to use to help protect the domain while also 
helping itself in eliminating the flow of fraudulent mail.

Overall, SSP should answer these basic questions:

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

[BONUS READING MATERIAL: Reputation Considerations]

If the receiver had "reputation" information about the domain, then most 
of this, SSP and DKIM itself becomes a mute point.

Fundamentally, Reputation comes in two forms:

    - Some local policy white or black list.
    - 3rd party service bureaus such as DNSRBL or some TRUST SERVICE.

So there are two issues here for DKIM signers and receivers:

1) In lieu of DKIM TRUST SERVICE (DTS) (100% linked with DKIM
    with no exception), both the DKIM domain and DKIM receiver
    are at risk for potential fraud. The most information that
    can be gathered is:

       - No signature present
       - Valid Signature present
       - Invalid Signature present

    and with no augmenting assessment technology, both the
    DKIM signer and receiver are left in limbo.  The only
    benefit gain here is valid signatures, but there is
    protocol for protecting against fraud.

2) Even with a DTS in place, there is still risk with those DKIM
    receiver systems who are a) not participating in DTS, or b) is
    participating in another DTS where the DKIM domain is not a
    member of. The most information that can be gathered is:

       - No signature present
       - Valid Signature present
       - Invalid Signature present

       - Domain has no TRUST relationship
       - Domain has a TRUST relationship
       - Domain has a TRUST relationship, but no discovery process.

    For the receiver, the only reliable result for factors in a
    decision making process in increasing confidence order:

       - valid signature, no trust established
       - Trust Established for invalid signature
       - Trust Established for no signature
       - Trust Established for valid signature

So even with a reputation system we are still vulnerable for abuse, and 
please note I decided to leave out vendor/user service agreement issues, 
the commercialization aspect of all this that has a risk as well.

Nonetheless, I believe many, here and outside, have genuine concerns 
with any centralized TRUST services requirements in order to make DKIM 
work for a score of many reasons, including the basic idea that DKIM 
should remain to be a separate open technology with protocol flexibility 
to augment new reputation concepts.

In the short term, is history has any meaning here, you end up with the 
"batteries not included" dilemma many, including my company, had 
experienced with non-standard technical operations, customer support 
issues and public relations problems (The DTS may be very customer 
friendly and begins to pick and choose who can be members by using a 
multi-tier pricing model), when new technology (such as eCommerce 
automated credit card processing) in its early stages of development 
provide little options to consumers.  I think it would extremely 
unfortunate if DKIM becomes a "batteries not included" commodity.

Therefore, with all that said, I believe SSP provides that first level 
protection for domains who prefer to operate in whole or in part with an 
exclusive or strict signing practice. The design dilemma  has always 
been on why should an open ended 3PS signer be restricted or controlled 
by providing (by some means) to authorize 3PS to sign on behalf of the 
original domain.

--
Sincerely

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