[ietf-dkim] New issue: What is the purpose of SSP? {3.5} {3.5}

[Bill.Oxley at cox.com]

>In sum, I think the SSP-req doc should say "SSP must be published
> by DKIM signers, and the format is <this>".  

Disagree, dkim base works now. There will be people that will move very
slowly into implementation and requiring SSP to be implemented at the
same time will slow adoption.

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
bill.oxley at cox.com 


-----Original Message-----
From: ietf-dkim-bounces at mipassoc.org
[mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Tim Draegen
Sent: Thursday, September 21, 2006 3:27 PM
To: dcrocker at bbiw.net
Cc: DKIM IETF WG
Subject: Re: [ietf-dkim] New issue: What is the purpose of SSP? {3.5}
{3.5}

Dave Crocker wrote:
> Michael Thomas wrote:
>> I think that the interesting meta issue here is that DKIM
>> verification does not require this; SSP requires this. I hope that
>> there isn't confusion about that because the two really are
>> severable.
> 
> I am glad you raised this.  It encourages the basic question about the

> relationship between SSP and DKIM?
> 
> For example, are there reasonable SSP features that do not involve
DKIM 
> at all.  (Answer, "I send no mail" is a prime example.)
> 
> Note that "I send no mail" has nothing to do with signing, in which 
> case, the middle S of SSP is overly constraining.

I would like to elaborate on this point.  I'm more comfortable with
working with use-cases, so I'll present my ideas in such a format:

  - Mega-ISP wants to deploy DKIM.  Someone told them it stops spam,
    dries up phishing spots, and somehow prevents spy-ware.  Whatever,
    sales guys at work.

  - Mega-ISP uses my appliance to sign.  The on-box helper walks
    the admin through the necessary steps:

     1. Create config tying together selector, domain, streams of
        email to sign..  admin clicks "done".

     2. Sample DNS records (in a number of popular formats) are sent
        to admin's email account.

        XXX do we include SSP record for this domain?

     3. Admin adds records to DNS.

     4. Back on the appliance, admin clicks on "Click to test".
        Everything checks out, and the admin knowns that stuff is
        basically up and running (no typos in records, etc).

        XXX do we test for SSP record?

     5. Admin then spends the rest of the afternoon using scripting
        language of choice to automate the process.  Next day,
        Mega-ISP offers "Premium Email ID Protection" add-on to
        customers.

  - Mega-ISP wants my appliance to verify DKIM signatures.

     1. Admin clicks on checkbox "I want to verify DKIM signatures".

     2. A new filtering bit becomes available, "verified good".

     3. Admin delights in the power of writing filters like:

        A. "if email-is-DKIM-good and sender is PayPal,
            skip phish-philter"

        B. "if email-is-DKIM-bad/absent and sender signs
            all/most email, do the phish-philter"

     4. Admin calls me and complains to me that filter 3-B just
        adds overhead.

     5. I convince the admin that my reputation service is doing
        something useful with DKIM results.  Instead of filtering
        on DKIM-good and whitelisting, perhaps customer wants to
        participate in reputation sharing.

     6. Admin deletes filters and checks "Share DKIM results",
        These results become a small piece of a much larger picture.
        No white/black-list is maintained ever again by admin.

Although my appliance makes things EZ-mode, I think this use-
case scales to the DIYers, too.

My main points wrt this effort:

a. Signers MUST publish a SSP record.  Its easier for me to say
"you must publish this record, please do it" if the stone-tablet
in IETF-land says so.

b. Verifiers should be allowed to function without any need to
query an SSP record.  In my case, my 3rd-party reputation agents
will be doing the tracking of SSP records.  For whatever reason,
I'll have customers that want to do it themselves, and I'll expose
that functionality.

In sum, I think the SSP-req doc should say "SSP must be published
by DKIM signers, and the format is <this>".  I guess some sample
scenarios on the verification half can be described, but I think
that just adds confusion, and would be mostly wrong anyway.


FWIW,
=- Tim

PS. The "I send no email" thing could be useful.  I'd use it
to inform network owners that despite the fact that they
"send no email", some IP addresses assigned to them are in fact
sending mail.  Just make "SSP" generic enough to be "SP", and
I think we're good to go for at least a few years.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html