Subject: [ietf-dkim] New issue: What is the purpose of SSP?

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Sep 2006 10:34:51 -0700

Folks,

I think that Michael has done quite a good job of capturing much of the
detail that has been discussed.

However on reviewing the current draft, I am struck by the absence of
any text that describes the actual purpose of SSP, other than in terms 
of essentially reflexive detail.

   "The most pressing case seems to be the
    bid down attack inherent with almost all systems that allow optional
    authentication: how does a receiver know whether or not it should
    expect a message to contain authentication information?"

That is, we do not have a general, motivational statement for SSP.

I believe that, in fact, the working group has not settled on clear,
precise benefits goal(s) and that, therefore, it makes it difficult for
the working group to develop consistent technical requirements.

By way of priming the pump here is my own attempt to remedy this:

      Potential DKIM signers wish to assist receive-side message
      evaluation systems by publishing information about the messages
      that they originate and possibly sign. The primary basis for
      determining what practices to specify is a strong indication that
      receive-side processors have an interest in using the information.
      As always, other major factors include potential performance and
      reliability impact upon message handlers, and other system
      operators.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Sep 2006 11:57:23 -0700

>   reliability impact upon message handlers, and other system

Performance concerns are less significant when DKIM validation is  
performed by a recipient's email client for messages recognized on  
the a basis of originating and listed within a trusted-domain list or  
address-book.  Unlike IP address schemes where a time-stamp-line may  
not offer IP address information, the DKIM message itself offers  
requisite validation information.  DKIM information is independent of  
any receiving MTA added headers.  Any single email client may need to  
handle messages from several sources, including those that are web- 
based.

With respect to policy, there should also be a general understanding  
reached that acceptance of a message can not be solely based upon a  
DKIM signature domain.  The IP address remains a significant  
identifier that is still needed for general acceptance.  This  
situation might change when call-back or revocation schemes have been  
added to DKIM, or when there is a way to associate a signing domain  
with that of the transmitter.  Until then, policy should remain  
focused upon ensuring the DKIM signing-domain offers protection for  
the transmitter, rather than directly for the message originator when  
they differ.

When deciding upon a basis for DKIM policy, redirections that  
encompass desired email-address field or parameter domains must be  
considered a requisite component.  One possible area where DKIM could  
prove highly valuable would be means to validate a bounce address  
when a DSN is about to be sent.  This can be accomplished within a  
single lookup as only the domain of the bounce address needs to have  
a policy published (assuming the bounce address does not use a  
wildcard MX record).

  i.e.
  <hash1+hash2>.dkim-mf.<mail-from domain>. RR "always" + "strict"

These considerations will change this statement as follows:

   Potential DKIM signers wish to assist receive-side message
   evaluation systems by publishing information about the messages
   that they originate and possibly sign [or have signed]. The
   primary basis for determining what practices to specify is a
   strong indication that receive-side processors have an interest
   in using the information.  As always, other major factors
   include potential performance and reliability impact upon
   message handlers, and other system operators.  [Principal
   email-addresses where policy references of signing-domains and
   their related assurances may impact message handling are
   the 2822.From and the 2821.Mail_From.]

-Doug

---

From: <[email-masked]>
Date: Wed, 20 Sep 2006 15:19:20 -0400

Potential DKIM signers wish to assist receive-side message evaluation
systems by publishing information about the messages that they originate
and possibly sign. As always, other major factors include potential
performance and reliability impact upon message handlers, and other
system operators will determine what use, if any that receive-side
evaluators will make of this information.

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Wednesday, September 20, 2006 1:35 PM
To: DKIM IETF WG
Subject: [ietf-dkim] New issue: What is the purpose of SSP?

Folks,

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Sep 2006 14:16:52 -0700

>  systems by publishing information about the messages that they 
> originate and possibly sign. The primary basis for determining what 
> practices to specify is a strong indication that receive-side 
> processors have an interest in using the information. As always, 
> other major factors include potential performance and reliability 
> impact upon message handlers, and other system operators.
> 

Bill Oxley:
>  systems by publishing information about the messages that they
> originate and possibly sign. As always, other major factors include
> potential performance and reliability impact upon message handlers,
> and other system operators will determine what use, if any that
> receive-side evaluators will make of this information.

My intent was to define criteria for selecting practises that we specify
and assert constraints based on potential impact.  In other words, we
should specify features that are likely to get used and that are not
likely to hurt individual sites or overall Internet performance.

(These sound like obvious criteria, but my own view is that they have
not been considered much during the discussions so far.)

So:

      Potential DKIM signers wish to assist receive-side message 
evaluation systems by publishing information about the messages that 
they originate and possibly sign. Criteria for working group selection 
of practices to specify MUST include a strong indication that 
receive-side processors have an interest in using the information and a 
technical assessment that the publication and query activities will not 
impose excessive burdens on clients, servers, or network nodes.

d/
-- 

   Dave Crocker

---

From: Tim Draegen <[email-masked]>
Date: Wed, 20 Sep 2006 16:23:20 -0700

> of essentially reflexive detail.

I'm not sure if my feedback warrants a "new issue", as Dave Crocker
brings up my main concerns.  Maybe my comments can be added to Dave's
existing issue.  Feedback is below -- but first I need to clarify where
I'm coming from.

My understanding of how SSP is to be used is rooted in two distinct
areas - 1. building high-volume email servers, and 2. building a
reputation service.  Some factoids:

   - My largest customers will not deploy DKIM verification if it
     requires making a DNS query (or two) for every single non-signed
     email that they receive.  Even if it makes no real-world difference,
     some people just won't do it.

   - DKIM only makes a difference to me if a successful verification
     occurs.  Everything else is essentially noise.  Even with a good
     verification in place, I need other information to determine whether
     or not the verified identity is a friend or foe.  That other info
     is appropriately out of scope for DKIM & SSP.

   - I do not need SSP to arrive at a 'good verification' conclusion.
     Since all I care about it a 'good' result, SSP doesn't add enough
     value to warrant the MUST language that currently exists wrt
     verifiers querying for policy.

Where I *do* see a use for SSP.. two places:

   A. People want to use SSP for local filters policies, regardless of
      whether or not DKIM is in the picture (eg, checking for SSP on
      every received email).

   B. A reputation service wants to keep track of an identity/domain's
      SSP for whatever reason (scoring, anti-phishing schemes, blah).

Since "A" is conceivably a sub-set of "B", I'd like to see SSP become
nothing more than a way for domains to publish how they're signing.

=- Tim

----------------------------------------------------------------------
1.  Intro

   - "In the absence of a valid DKIM signature on behalf of the "From"
     address [RFC2822] (Resnick, P., “Internet Message Format,” April
     2001.), the verifier of a message MUST determine whether messages
     from that sender are expected to be signed, and what signatures are
     acceptable."

     MUST -->  MAY.  In reality, my customers won't do this for every
     email they receive.  They'll want to control this behavior, for
     whatever reason.

   - "In particular, whether a domain signs all outbound email must be
     communicated to the verifier."

     This information should be made available to the verifier.  Whether
     or not the verifier retrieves the info will be optional.

   - "Without such a mechanism ... unsigned messages will always need to
     be considered to be potentially legitimate."

     I believe there is quite a bit of existing technology in place to
     determine what is legitimate, regardless of signed status.  :->
     SSP as-a-way-to determine the validity of unsigned email seems a
     bit misguided.

   - "Expressions of signing practice which require outside auditing are
     out of scope for this specification because they fall under the
     purview of reputation and accreditation."

     SSP makes no sense to me unless I view it through a 'reputation'
     lense.  Without going out of scope, I'm hoping SSP describes how
     either a DKIM-verifier or a reputation-agent can determine a
     domain's signing policy.
-----------------------------------------------------------
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Sep 2006 16:44:47 -0700

>     some people just won't do it.

You might add non-cached DNS queries.

>     address [RFC2822], the verifier of a message MUST determine  
> whether
>     messages from that sender are expected to be signed, and what
>     signatures are acceptable."
>

Agreed.

>     SSP as-a-way-to determine the validity of unsigned email seems a

Agreed.

This effort is also possibly pointless when look-alike attacks are  
considered.

>     either a DKIM-verifier or a reputation-agent can determine a

Agreed.

Here reputation must be viewed as something not defined in a classic  
sense of avoiding spam, but rather what might be considered  
"trustworthy" from the basis of transactional messages.  The  
important aspect needed for discerning what is "trustworthy" might be  
partially covered by section 4.5.  In other words, one MUST NOT  
assume an entire domain is "trustworthy" and this is where policy can  
help.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 20 Sep 2006 22:46:28 -0700

Dave Crocker wrote:
> receive-side processors have an interest in using the information and
> a technical assessment that the publication and query activities will
> not impose excessive burdens on clients, servers, or network nodes.
The capitalized MUST (apparently being used in the RFC 2119 sense) seems
a little strong here.  This isn't a specification for a protocol, this
is an informational document which we are using to design a protocol.

I agree these are good goals, but trying to make the design criteria
that rigid risks making our design process inflexible.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 20 Sep 2006 23:04:03 -0700

Interesting thoughts...comments inline.

Tim Draegen wrote:
>> any text that describes the actual purpose of SSP, other than in
>> terms of essentially reflexive detail.
>
I don't understand this.  Many people routinely do reverse DNS lookups
on the IP address from which messages are received, SPF checks (which
can be several lookups), and so forth.  Why the sensitivity to
additional, potentially well-cached lookups?
>     verifiers querying for policy.
There's a lot of question how much "teeth" these requirements on the
verifier have.  We used the stronger wording to encourage "compliant"
implementations to do SSP, because a lot of the reason for publishing
SSP goes away if it is going to be ignored.  But I expect that it will
be up to the individual customer's choice, just as it's possible to turn
certain classes of checks on and off in SpamAssassin.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Thu, 21 Sep 2006 00:42:13 -0700

> is an informational document which we are using to design a protocol.

Requirements documents are used to dictate choices by a specification 
effort.  That's rather more force than just being informational.

> that rigid risks making our design process inflexible.

Requiring that we have a basis for believing a feature will get used and 
won't break anything in the process?  That's rigid?

We have no track record for this mechanism and I believe that there is 
no precedent for one like it on the scale of the Internet.

It might be nice for us to start off a tad conservative.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Thu, 21 Sep 2006 07:11:14 -0700

> additional, potentially well-cached lookups?

That's the difference between trying to tell people what is best for 
them, versus listening to what they are comfortable with.

A MUST should be used when the thing being referred to is required for 
the functionality to be meaningful.  If it remain meaningful in spite of 
exceptions, then a MAY is probably acceptable.

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Sep 2006 09:47:30 -0700

>additional, potentially well-cached lookups?
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.

>certain classes of checks on and off in SpamAssassin.
Again, we need to separate out the two protocols. We have to have MUST
requirements for the SSP protocol, but there isn't a MUST USE SSP 
requirement
for any given DKIM verifier.

       Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 21 Sep 2006 10:07:28 -0700

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.

d/

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Sep 2006 10:21:34 -0700

On Sep 21, 2006, at 9:47 AM, Michael Thomas wrote:

> Jim Fenton wrote:
>>
>> I don't understand this.  Many people routinely do reverse DNS  
>> lookups on the IP address from which messages are received, SPF  
>> checks (which can be several lookups), and so forth.  Why the  
>> sensitivity to additional, potentially well-cached lookups?

There is a far greater likelihood the transactions in question are  
_not_ cacheable.

When there is a high level of UDP traffic, especially when highly  
distributed transactions load a common server, high packet loss rates  
may result.  The average domain offers two DNS.  When each message is  
expected to generate a load on servers that have never indicated an  
expectation of even seeing this traffic, it should also not be  
surprising that this load may not be well handled.  The retry period  
for a lost packet is 5 seconds, followed by 10 and then 20 etc.  The  
number of resulting simultaneous connections may subsequently limit  
the MTA's ability to accept additional connections, for a type of DoS.

  Keep in mind SPF remains experimental, where even that status needs  
to be questioned, as it also represents a serious security concern as  
well.

> there isn't confusion about that because the two really are severable.

When an email-address's domains policy is checked only in response to  
a retained email-address then there is never a need to hunt for a  
policy.  This assumption of any required search is premised upon a  
mode of protection that is highly flawed when look-alike attacks are  
considered.  Address-books and trusted-lists can leverage the  
information made available with DKIM.  For this mode of operation,  
policy may simply provide a means to associate different domains.

>> There's a lot of question how much "teeth" these requirements on  
>> the verifier have.  We used the stronger wording to encourage  
>> "compliant" implementations to do SSP, because a lot of the reason  
>> for publishing SSP goes away if it is going to be ignored.  But I  
>> expect that it will be up to the individual customer's choice,  
>> just as it's possible to turn certain classes of checks on and off  
>> in SpamAssassin.
>
> Again, we need to separate out the two protocols. We have to have  
> MUST requirements for the SSP protocol, but there isn't a MUST USE  
> SSP requirement for any given DKIM verifier.

As indicated with the use of the address-book or trusted domain list,  
there is NO NEED for any SSP must.  Do you want this to become a  
legal requirement?  No protection scheme should mandate highly  
questionable and potentially dangerous network activity.

-Doug

---

From: Tim Draegen <[email-masked]>
Date: Thu, 21 Sep 2006 12:26:47 -0700

> 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

---

From: <[email-masked]>
Date: Thu, 21 Sep 2006 15:49:44 -0400

> 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 
[email-masked] 

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

FWIW,
=- Tim

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 21 Sep 2006 16:30:02 -0400

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>

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

That movement is already at a crawl.

Nonetheless, a DKIM-BASE only system is inherently, by default, a SSP
"Neutral Policy" system and this relaxed default protocol provision is what
this new protocol inherently "dangerous" to pursue en masse.

I don't know about others, but it is what has my hairs standing on my back.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Steve Atkins <[email-masked]>
Date: Thu, 21 Sep 2006 13:46:04 -0700

> that just adds confusion, and would be mostly wrong anyway.

If I understand you correctly you're suggesting that publishing
SSP records be mandated by dkim-base?

If so, -1.

Cheers,
   Steve

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 21 Sep 2006 13:47:20 -0700

> same time will slow adoption.

+1

Saying essentially that "confused people will be confused" isn't enough 
of a reason to mandate something.  They'll be confused anyway.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tim Draegen <[email-masked]>
Date: Thu, 21 Sep 2006 15:03:14 -0700

> same time will slow adoption.

I'm not sure this is accurate.  I'm sitting on top of a large
list of customers who want DKIM, and they want it yesterday.
In other words, concern around slow-adoption rates seems a bit
alien to me.

My understanding (trying to stay on topic with SSP-req); again,
I'm just trying to share my perspective for the rest of the WG:

- SSP can be completely dropped, and DKIM will still be worth
   something to me.  I'm OK with this outcome (if it means no
   more time will be spent on SSP).

- If SSP is going to be something other than an ignored add-on,
   then SSP-req/DKIM-base needs to have language describing
   that, if a signer does not publish an SSP record, the assumed
   default will be <whatever>.  I did a bad job articulating this
   by writing "SSP must be published by DKIM signers".

   EG, with a default of "i sign some", the majority of adopters
   won't need to do anything (they SHOULD, to make SSP queries
   resolve).  This also means that a signer understands that one
   day they can publish "i sign everything" when/if they ever do.

- From my POV, SSP records can be as simple as
   "No-sign/sign-some/sign-all".  At this point in time, I see
   little if any interest in per-user SSP granularity.

- All the language in SSP-req around how a verifier should
   handle mail can be axed.  Specifically, the information
   advertised by SSP should stop at "I (do/do not/partially)
   sign".  Adding ".. and therefore you should treat unsigned
   email from me as suspicious" might seem useful, but the
   unenforcible nature of this only adds confusion.

Hmmm.  I suppose the above points describe my SSP requirements.
If the WG deviates from this list, I cannot guarantee overnight
adoption rates.  :-P

=- Tim

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 21 Sep 2006 18:43:42 -0400

----- Original Message -----
From: "Tim Draegen" <[email-masked]>
To: <[email-masked]>

>   unenforcible nature of this only adds confusion.

And removing it further adds confusion to an already ambiguous "What is the
Payoff?" DKIM-BASE protocol that has a very high potential for invalidation.

Signing mail is the easy part.  What you need to do is explain to me (and
the rest of the receiver world) why they should a) look for, and b) add
overhead in processing DKIM signatured on the receiver end.  For what
purpose?  For the signer's benefit?  The receiver's benefit? The User's
benefit?  And how do you measure that benefit?

We keep trying to hide the fact, the reality, that in the end, every one of
us is going to market and use DKIM as a New Security, "Anti-Bad Mail", "Good
Guy Reinforcement" feature, which inherently implies a filtering or Tagging
concept that is independent of how one actually does rejects, holds, tags or
ignores mail.

My suggestion is to remove all these subjective ideas and concentrate on the
mechanics on how SSP can improve the security (authorization) of using
DKIM-BASE in the first place. I believe that was the original proof of
concept when DKIM and SSP was just one!  It was a mistake to separate it in
my view.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Sep 2006 15:58:24 -0700

Dave Crocker wrote:

> For example, are there reasonable SSP features that do not involve 
> DKIM at all.  (Answer, "I send no mail" is a prime example.)
>

Right, but by the same token I don't think we want to be in ocean boiling
mode either. But let's talk about the concrete: is there something other 
than
"I don't send mail" in the non-dkim category that should be on our agenda?

       Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 21 Sep 2006 16:11:08 -0700

> Right, but by the same token I don't think we want to be in ocean
> boiling mode either. But let's talk about the concrete: is there
> something other than "I don't send mail" in the non-dkim category
> that should be on our agenda?

Agreed, but I think there might be a difference between the underlying 
publishing framework, versus the particular practices we define records 
for initially.

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 22 Sep 2006 04:34:55 -0000

>   then SSP-req/DKIM-base needs to have language ...

No way.  

There is enough operational experience with DK that we can be
confident that DKIM will do what we expect it to.  SSP, on the other
hand, is purely a paper design with no operational history at all.
SSP's intentions to stop phishing are noble, but a lot of us have
grave doubts that SSP will be useful, and suspect that its goals will
be met in other ways.  It's probably worth standardizing SSP as an
experiment to find out what works and what doesn't, but not if that
puts DKIM at risk.

A lot of people who plan to use DKIM are not going to use SSP, no
matter what the spec says.  A spec that mandates SSP is a spec that's
not going to be implemented.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Sep 2006 11:00:43 +0100

>>   then SSP-req/DKIM-base needs to have language ...

I'd be with John there for purely process reasons - I'd like to
see base as an RFC and adding any normative SSP reference would
set that back by months at least.

S.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 22 Sep 2006 07:48:27 -0400

----- Original Message -----
From: "John Levine" <[email-masked]>

>>- If SSP is going to be something other than an ignored
>>  add-on, then SSP-req/DKIM-base needs to have language
>>   ...
>
> No way.
>
> There is enough operational experience with DK that we can
> be confident that DKIM will do what we expect it to.  SSP,
> on the other hand, is purely a paper design with no
> operational history at all.

The SendMail DKIM-SMILTER public API has SSP support built-in. Therefore any
implementations out there using this API, it would  have direct field
testing and operational history.

What you are wishing to say that you haven't seen (or wouldn't know) anyone
published SSP policies other than the default o=~ (Optional Signature)
Policy.   The fact is, every DKIM domain I have tested up to this point has
a SSP policy published.  So you are obviously wrong in this respect.

Hnmmmmmmmm, isn't this the same problem with SPF?  Everyone (the majority)
publishing a NEUTRAL policy that it made SPF practically useless?

I would rather use direct correlations and real operationl history based on
similar concepts such as SPF, to have enough insight to see history will
repeat itself here with DKIM using neutral policies or NO SSP (therefore
NEUTRAL by default).

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 22 Sep 2006 08:03:56 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>

> John Levine wrote:
>
>>> - If SSP is going to be something other than an
>>>   ignored add-on, then SSP-req/DKIM-base needs
>>>   to have language ...
> >
> > No way.
>

If there is a long run benefit to "doing it right" (not saying it is), "by
months" would be inconsequential to the majority of "mankind" (Internet
Email Industry - across the board).

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 22 Sep 2006 15:39:47 +0200

Michael Thomas wrote:

> We have to have MUST requirements for the SSP protocol, but
> there isn't a MUST USE SSP requirement for any given DKIM
> verifier.

+1

In other words SSP-MUST means "if you do SSP you MUST get it
right".  An example from the also voluntary SPF:  If the
receiver aborts SPF-evaluation for his own private reasons
(no TempError, let alone PermError) it's fine, but then this
receiver shouldn't add a dubious Received-SPF: NONE (or even
NEUTRAL) trace header field, because that would be a lie.

Frank

---

From: Douglas Otis <[email-masked]>
Date: Fri, 22 Sep 2006 07:43:49 -0700

On Fri, 2006-09-22 at 07:48 -0400, Hector Santos wrote:
>
> I would rather use direct correlations and real operational history
> based on similar concepts such as SPF, to have enough insight to see
> history will repeat itself here with DKIM using neutral policies or NO
> SSP (therefore NEUTRAL by default).

Most major ISPs request neutral handling when their SPF records do not
match the client.  For some this was not good enough, and they even
requested positive handling.

While reasons for a DKIM signature failure will be different, they will
persist just as they have with SPF.  If history offers guidance, it
would be to NOT request handling except in exigent situations.

When approaching such policy, offer a 100 foot pole. Allow exigent
situations to be clearly asserted such as "I sign all messages and avoid
services that might break signatures," and the 100 foot pole that
asserts "I sign all my messages, but my users take advantage of services
that are likely to break these signatures."

Even when the 100 foot pole often induces neutral handling, some may
attempt to condition handling based lists of unfriendly  services.  If
history is to offer any guidance, expect most to avoid delivery issues
that require continuous support to resolve.

One area that seems missed is that the 2821.MAIL_FROM would be benefited
by being able to assert a policy separately from that of the 2822.From
or perhaps even a 2822.Originator.  This is where policy can play two
roles.  One that offers associations, and the other that might illicit
negative handling.

To associate with any number of domains: 

query-label = base32(sha(signing domain) + crc(signing domain));

The reason for two hashes may be overkill.  This is to ensure an
extremely low possibility of a collision.  The query domain will be
asserted within the resource record, so even an unexpected collision
will be properly resolved unless there is a desire to publish a policy
for both. : ( 

The query would be:
query-label._dkim-xx-policy.<domain of email-address in question>

The synthesis of the response could be:

          *._dkim-xx-policy.<adr dom> RR "a:adr dom; f:A:O"
   _default._dkim-xx-policy.<adr domain> RR "a:adr dom; f:A:O"
query-label._dkim-xx-policy.<adr domain> RR "a:adr dom: sig dom; f:A:O"

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 22 Sep 2006 15:06:12 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>

>> I would rather use direct correlations and real operational
>> history based on similar concepts such as SPF, to have enough
>> insight to see history will repeat itself here with DKIM
>> using neutral policies or NO SSP (therefore NEUTRAL by default).

> Most major ISPs request neutral handling when their SPF records
> do not match the client.  For some this was not good enough, and
> they even requested positive handling.
>
> While reasons for a DKIM signature failure will be different, they
> will persist just as they have with SPF.  If history offers
> guidance, it would be to NOT request handling except in
> exigent situations.

And what are those "Exigent Situations?"

In principle, I disagree with the assertion that we are not offering new
ways to filter mail.  I'm a realist. That is exactly how it is going to be
used.  Whether it is standard SSP, non-standard proprietary REPUTATION
schemes, Heuristics, Classification, Neural Nets methods, etc, its all about
the same thing - Query Dissemination. Its a long establish science.

While it is true the industry has evolved with legacy operations for which
there is little to do about the exploitations, and for the most part
receivers followed a fail-safe philosophy,  with DKIM-SSP, we would be
evolving beyond legacy operations and therefore a new level of expectations
with new protocol attributes that allows signers and receivers to leverage.
Hopefully, towards their benefit and not the benefit of the exploiters.

In short, if you do something that will move you into a new category, then
we are no longer talking about the inadequacies of 20+ years old legacy
operation.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 22 Sep 2006 16:25:43 -0700

On Sep 22, 2006, at 12:06 PM, Hector Santos wrote:

>> guidance, it would be to NOT request handling except in exigent  
>> situations.
>

Many consider phishing an exigent situation.  Corporations may  
restrict their inputs to authenticated web-forms and abandon email  
for commerce.  Alerts become an automated phone call.  There are some  
commerce activities where this method is fairly burdensome.  One  
response is to individualize each message in a recognizable fashion.   
When an existing or trusted email-address can be used in conjunction  
with a valid DKIM signature, standardized annotations replace what  
might become a confusing array of recognition techniques.

> In principle, I disagree with the assertion that we are not  
> offering new ways to filter mail. I'm a realist. That is exactly  
> how it is going to be used.

DKIM should improve upon performance and accuracy of message  
filtering without reliance upon policy assertions.  This filtering,  
as always, would be based upon a type of non-standard share reputation.

> Whether it is standard SSP, non-standard proprietary REPUTATION  
> schemes, Heuristics, Classification, Neural Nets methods, etc, its  
> all about the same thing - Query Dissemination. Its a long  
> establish science.

Only when policy information is trustworthy would there be any  
protection.  Many of the bad actors have already adopted various look- 
alike attacks to avoid message filtering techniques, where blocking  
policy becomes worthless.  Standardized trusted-lists and address- 
books allow DKIM to establish trust.

> While it is true the industry has evolved with legacy operations  
> for which there is little to do about the exploitations, and for  
> the most part receivers followed a fail-safe philosophy, with DKIM- 
> SSP, we would be evolving beyond legacy operations and therefore a  
> new level of expectations with new protocol attributes that allows  
> signers and receivers to leverage.

I agree with the sentiment, but we both see different uses for  
policy, association versus blocking.

Publishing reputation by name rather address is more comprehensive,  
but...  Histories supporting reputation must be verifiable.  Most  
abuse today looks spammy, but so do valid messages.  When spammy  
messages are sent in bulk to non-receptive recipients, the IP address  
is block-listed.  With DKIM, there may not be evidence the signing  
domain was responsible for the Rcpt To parameter.  This weakens a  
concept of bulk being applied to DKIM in the same manner as with an  
IP addresses.

> Hopefully, towards their benefit and not the benefit of the  

Of greater importance is to ensure that DKIM is not a detriment to  
the implementer.

> In short, if you do something that will move you into a new  
> category, then we are no longer talking about the inadequacies of 20 
> + years old legacy operation.

It takes years for infrastructure to change, where legacy equipment  
will be in play.  A retained email-address annotation approach offers  
significantly improved protection compatible with existing systems.   
It would be my hope that DKIM abuse reporting and perhaps the  
adoption of opaque identifiers make a dent in identifying and  
eliminating millions of compromised systems that are responsible for  
sending much of the spam.

-Doug