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

From: Dave Crocker <[email-masked]>
Date: Thu, 06 Dec 2007 18:22:00 -0800

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.

c/
-- 

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

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 06 Dec 2007 21:29:16 -0500

>      what it should do with mail that is from a third

If you mean from as in 2822.From, then no.  If you mean from as in 
delivered by MTA operated by an entity not controlled the 2822.From domain 
owner, then sure.

I'd say suggest rather than tell, since we all know senders can't tell 
receivers what to do, but generally, that's exactly the point.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 07 Dec 2007 01:30:25 -0500

Dave Crocker wrote:
 > Among the various discussions I've had today, one
 > comment about SSP struck me as worth wider consideration:
 >

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

---

From: "Patrick Peterson" <[email-masked]>
Date: Fri, 7 Dec 2007 03:19:15 -0800

>       what it should do with mail that is from a third

I really struggle with comments like these, too. I don't believe this is
true but even more fundamentally I don't believe that discussing
"comments about SSP" is productive. We should be discussing how to build
the best SSP and these random comments engender long threads that leave
everyone frustrated and angry.

I think we all hear various comments about SSP but having the list
consider them without an acutal discussion of SSP issues is just not
productive.

(Again I'm attacking the message not the man. Please don't take this as
an ad hominem attack. It is certainly not meant as one and hopefully not
taken as one.)

pat

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Dec 2007 06:15:14 -0800

Patrick Peterson wrote:
> "comments about SSP" is productive. 

Patrick, my saying "one comment about" was merely meant to give credit for 
someone else noting a fact, not to cast it as an opinion.

It isn't an opinion. It is a factual statement that serves to raise a 
perspective about SSP that has missing from balanced discussion about SSP.

A more complete version would be something like:  If a DKIM signature from an 
organization is not broken, then SSP is a mechanism by which that organization 
can make statements to another about mail from a third.

We are so focused on the concerns of that first organization that we are 
forgetting to worry about the fact that their statements are intended to 
affect the handling of mail that they did not originate -- but someone else did.

If there is an error in this factual statement, I don't see it and certainly 
would wish for someone to explain it to me.

The point of the perspective is not to disenfranchise the first organization, 
but to make sure we are not blindly disenfranchising the third.

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Fri, 07 Dec 2007 06:52:42 -0800

Dave Crocker wrote:
> We are so focused on the concerns of that first organization that we 
> are forgetting to worry about the fact that their statements are 
> intended to affect the handling of mail that they did not originate -- 
> but someone else did.
>
> If there is an error in this factual statement, I don't see it and 
> certainly would wish for someone to explain it to me.
>
> The point of the perspective is not to disenfranchise the first 
> organization, but to make sure we are not blindly disenfranchising the 
> third.

I'm sorry, but are you suggesting that romania.mafia.com has a legitimate
voting right for their use of my domain name that SSP would take away
from them illegally?

       Mike

---

From: <[email-masked]>
Date: Fri, 7 Dec 2007 10:05:58 -0500

Unfortunately this message is one that is useful to my organization.
With thousands of small businesses that don't have the capability to
manage their own DNS, mail, DKIM signing they will have to rely on the
ISP to provide that for them. An ISP may find it easier to publish a
single sign.isp.com public key and put an ssp record in the business
domain that indicates 3rd party signing.

Now on the receiver side, it will depend on the implementation whether
SSP is checked at all. There is room for a threat model there.
Thanks

Bill Oxley
Messaging Engineer
Cox Communications

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Patrick Peterson
Sent: Friday, December 07, 2007 6:19 AM
To: [email-masked]; [email-masked]
Subject: [ietf-dkim] Discussing what someone said about SSP -
productive?

pat

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Dec 2007 07:16:27 -0800

> voting right for their use of my domain name that SSP would take away

Are you saying that, at the time of SSP processing, you can know for certain 
that that is the name and nature of the third party?  If you are, please 
explain the basis, because I do not see it.

My point, in highlighting the third party, is exactly to note that SSP is 
based on some assumptions that attend only to the owner of the SSP record and 
not to the third party whose mail is affected by that record.

As has been noted, ad nauseum, SSP will, at best, be an imperfect mechanism, 
at least due to taking years to adopt broadly and, probably more importantly, 
to broken signatures.

Giving one party a source of leverage on mail from a another is the very 
nature of what SSP is seeking to do.  Certainly it is mail not signed by the 
first party. This perspective should raise warning flags.

That mail abuse is such an extreme problem is probably the only reason we 
would consider such a mechanism, but we need to be careful that we do not use 
it to entirely disenfranchise possibly legitimate mail senders.

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Fri, 07 Dec 2007 07:41:55 -0800

Dave Crocker wrote:
> Giving one party a source of leverage on mail from a another is the 
> very nature of what SSP is seeking to do.  Certainly it is mail not 
> signed by the first party. This perspective should raise warning flags.
>
> That mail abuse is such an extreme problem is probably the only reason 
> we would consider such a mechanism, but we need to be careful that we 
> do not use it to entirely disenfranchise possibly legitimate mail 
> senders.
I assume you know what the meaning of "disenfranchise" is as you've
chosen to use it twice now. A legitimate user of my domain name is exactly
who I say is legitimate. There is no vote to be had on that issue, and 
as such
no vote to be taken away. Do you seriously dispute that?

       Mike

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 7 Dec 2007 16:44:14 +0100

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

"Author" and "sender" are intentionally different concepts
in e-mail, and the "we" in TINW didn't manage to reconcile
them where it matters, in 2822upd.

JFTR, Dave and others proposed to deprecate Resent-* header
fields in 2822upd (on the 822 list), a significant part of
the problems with SSP.  RFC 5016 4.3 even hints broadly at
the problem, "Bob" (a mailing list or resender) has to be
free to resend Alice's SSP mail, because 2822upd says that
he's free to do this.

A receiver rejecting Bob's resent mail because Alice wants
this in her SSP might be at odds with (2)822(upd).  If you
want to get rid of Resent-* update or obsolete RFC (2)822,
"on the DKIM list" won't fly.  At the moment you can only
hope that Bob doesn't invalidate Alice's DKIM signature.

With mailing lists violating 2821(bis) 3.10(9) as they see
fit - up to "replace existing Sender" - SSP is in trouble,
and "don't use it on mailing lists" is shaky without a way
to identify a mailing list address.  We're not sure what
Bob is up to, and worse, Alice can't be sure.  

SPF at least went to the trouble of justifying its mode of
operation as "allowing to emulate 821 as good as possible
after 1123", for SSP it's apparently "even 822 was already
wrong".  PRA at least tried to (ab)use (2)822 header fields
in a plausible way, SSP does not even pretend to understand
what they mean and how they are used.

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

Well, a solution compatible with what most mail standards say 
certainly exists already, modulo Doug not liking certain uses
of MX, because it could be an attack vector.

*All attempts to outsmart PRA are doomed*.  I think that's
a kind of "IETF law" in the style of "Usenet laws".  Adding
a lemma based on "PRA isn't good enough" should be simple.

> I found for ~80-84% of the time, the following domain
 
> x821.MailFrom == x822.From [== x822.Sender if present]

Great, with 16-20% false positives and 90% spam it should be
clear that rejecting all mails from odd IPs on Fridays is a
"better" mechanism (it's certainly cheaper than PRA or SSP).

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

I give up again, this is hopeless.  Get an experimental RFC
for SSP and check out what it does for the desperate folks
wishing to participate.  Beware of volunteers too timid to
publish a clean SPF PASS / FAIL policy like Ebay / Paypal,
they might be in for a surprise (from their POV).

 Frank

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Dec 2007 07:55:11 -0800

Michael Thomas wrote:
>>  would consider such a mechanism, but we need to be careful that we do
>> not use it to entirely disenfranchise possibly legitimate mail senders.
> I assume you know what the meaning of "disenfranchise" is as you've chosen 
> to use it twice now. A legitimate user of my domain name is exactly who I 
> say is legitimate. There is no vote to be had on that issue, and as such no
>  vote to be taken away. Do you seriously dispute that?

Your perspective asserts certainties that we already know do not apply.

My point is exactly that SSP will be operating in a context of significant
uncertainty, yet it's design model really assumes differently.

d/
-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 7 Dec 2007 11:16:53 -0500

On Friday 07 December 2007 10:55, Dave Crocker wrote:
> >> we would consider such a mechanism, but we need to be careful that we do
> > chosen to use it twice now. A legitimate user of my domain name is
> > exactly who I say is legitimate. There is no vote to be had on that
> > issue, and as such no vote to be taken away. Do you seriously dispute
> > that?
>

I guess that's a yes.

If you believe that any random MTA has an equal right to emit mail claiming to 
be from my domain, then I think there's little left to discuss.  I totally 
and completely understand why you think SSP is a bad idea.

Mike's point is the key one.  His point is right one.  From your perspective 
then, I guess there's no phishing problem because anyone is equally 
legitimate for sending from any domain.  

Scott K

---

From: John Levine <[email-masked]>
Date: 7 Dec 2007 17:00:19 -0000

> If you believe that any random MTA has an equal right to emit mail
> claiming to be from my domain, then I think there's little left to
> discuss.

Twisting other people's arguments to make them sound absurd is not helpful.

For example, since you want to forbid all third parties from sending
mail, please explain why you want to forbid newspaper mail-to-a-friend
services.  Why are you opposed to press freedom?

R's,
John

PS: The non-absurd version of this is, where did we conclude that the
DNS operator's rights to a domain name always trump every other
possible use?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 7 Dec 2007 12:20:58 -0500

> services.  Why are you opposed to press freedom?

Nothing says they have to use my domain name to do it.  It's completely 
orthogonal to the point.

> DNS operator's rights to a domain name always trump every other

I disagree.  What I stated is the logical conclusion from the statement.  
Either domain owners have the right to control the use of their domain names 
in email or they don't.

If they do, then Mike's point stands.

If they don't, then phishing is inherently OK.  There really is no middle 
ground.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Fri, 7 Dec 2007 09:27:35 -0800

On Dec 7, 2007, at 8:16 AM, Scott Kitterman wrote:

> claiming to
> be from my domain, then I think there's little left to discuss.

If you don't want people to forward your mail, then you're not obliged
to send mail to them.

If, on the other hand, you want to participate in a store-and-forward
protocol then you don't get to say that other hosts are not allowed to
emit mail claiming to be from your domain.

Cheers,
   Steve

---

From: Steve Atkins <[email-masked]>
Date: Fri, 7 Dec 2007 09:38:46 -0800

> If they don't, then phishing is inherently OK.  There really is no  

Fallacy of the excluded middle.

Just because it's OK for people to use some variant on a webmail
interface to send mail "from" their email address does not make it
OK to criminally steal passwords or credit card details.

We're getting a reasonable survey of logical fallacies
today. Entertaining, but not terribly useful, and there's at least a
couple of dozen more to collect to get the full set.

Could we move on to some more reasonable lines of argument?

Cheers,
   Steve

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 7 Dec 2007 12:43:13 -0500

> emit mail claiming to be from your domain.
And that's also orthogonal to my point.  That would be an argument against 
SPF, but not SSP.  If my mail is transparently forwarded (without 
modification) then SSP presents no obstacle to store and forward.  If someone 
changes my message, then it's no longer my message.  The fact that DKIM 
signature break when messages are modified is a feature.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 7 Dec 2007 12:47:19 -0500

> OK to criminally steal passwords or credit card details.

Phishing is about misrepresenting identity.  Either you believe domain owners 
should be allow to control the use of identity or you don't.  There is no 
middle ground.  This has nothing to do with content of the message.  
Your 'middle ground' doesn't exist.

Your can't prevent random people from using domain names in email without 
preventing random people from using domain names in email.  It's really that 
simple.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Fri, 7 Dec 2007 09:53:08 -0800

> signature break when messages are modified is a feature.

You acknowledge and expect that mail claiming to be "from"
your domain may be legitimately received and re-emitted by an MTA
without your explicit permission or knowledge  (by the
simple fact that both you and they participate in the global email
infrastructure).. Perfectly reasonable, that's just how email works.

But that also means that "any random MTA has
an equal right to emit mail claiming to be from your domain".

So you're contradicting your previous statement. You probably want
to start over and talk about your real concern, rather than "use of  
your domain
in mail emitted by other MTAs".

Cheers,
   Steve

---

From: Jim Fenton <[email-masked]>
Date: Fri, 07 Dec 2007 09:58:50 -0800

> OK to criminally steal passwords or credit card details.

Some domains don't sanction the use of outside services to send mail
"from" their domain, and have terms of use requiring the use of their
domain's own mail servers to send mail. This is becoming increasingly
commonplace in the corporate world.  If you want to forward a news
article, you're welcome to do so using your personal email address.

Domains lacking "terms of use" requiring the use of their own mail
servers (which presumably would sign outgoing mail), should not publish
SSP other than "unknown", because it is perfectly within a user's rights
to send mail using means that wouldn't get it signed.  It would be
helpful to have this expressed in the Development/Deployment/Operations
document.

-Jim

---

From: Steve Atkins <[email-masked]>
Date: Fri, 7 Dec 2007 10:06:30 -0800

On Dec 7, 2007, at 9:47 AM, Scott Kitterman wrote:

> Phishing is about misrepresenting identity.

No, it's not. Phishing is "the activity of defrauding an online account
holder of financial information by posing as a legitimate company",
according to my dictionary.

Wikipedia also has a decent definition:
"In computing, phishing is an attempt to criminally and fraudulently
acquire sensitive information, such as usernames, passwords and
credit card details, by masquerading as a trustworthy entity in an
electronic communication."

What you're doing is taking perfectly reasonable, normal behaviour
(the owner of an email address using a smarthost not controlled by the
domain owner to send email) and entirely different, criminal, behaviour
(pretending to be the domain owner for the intent of defrauding others,
stealing financial information and passwords and so on). You're  
combining
those into a single group of behaviour and calling it "phishing" - a  
word
that everyone here knows is a description of very, very bad behavior.

You're taking the concept of "the domain owner should control all use of
that domain" - which is a reasonable position to start with, even if  
it's
wrong - and taken the argument to an extreme of categorizing behavior
that contradicts your argument as criminal.

It's not a compelling way to state your case.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Fri, 07 Dec 2007 10:17:00 -0800

> emit mail claiming to be from your domain.

Why are you seizing on the narrow word emit, when it was pretty
clear that by emit he meant "invented out of whole cloth"? For
somebody who copping to being above the fray, that's a rather
uncharitable reading. Or perhaps even a reducto ad hominem!

 >>>> issue, and as such no vote to be taken away. Do you seriously dispute

Unlike Dave's response, you have a chance to answer yes or no.
If there's some "excluded middle", please name it.

		Mike

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 7 Dec 2007 13:17:35 -0500

> It's not a compelling way to state your case.

Sure, but we've been through all this before, so there's really no point.  

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Fri, 7 Dec 2007 10:17:49 -0800

> article, you're welcome to do so using your personal email address.

That's quite true, though not relevant to the comment you're replying  
to.

> helpful to have this expressed in the Development/Deployment/ 

Yes. That sounds like a good thing to have recorded somewhere.

It wouldn't be just "their own mail servers", it would also be those
they'd authorized to send dkim-signed mail on their behalf by one
or other of the usual methods.

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Dec 2007 10:20:29 -0800

> article, you're welcome to do so using your personal email address.

Hence my asking during the meeting whether we weren't seeking to have random 
receiving services enforce contractual issues that are internal to the owner 
of the domain.

It makes enormously good sense for us to seek to rein in rogue independent 
third parties that have no relationship to the domain owner.

However to ask random recipients to enforce internal policies of the domain 
owner seems considerably beyond what is reasonable for an Internet scale 
protocol service.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Fri, 07 Dec 2007 13:25:52 -0500

> signature break when messages are modified is a feature.

+1.

-- 
Sincerely

Hector Santos, CTO

---

From: Steve Atkins <[email-masked]>
Date: Fri, 7 Dec 2007 10:23:07 -0800

On Dec 7, 2007, at 10:17 AM, Michael Thomas wrote:

> Why are you seizing on the narrow word emit,

"Emit" is a pretty well defined word.

> when it was pretty
> clear that by emit he meant "invented out of whole cloth"?

No, it wasn't. It did appear that he hadn't considered the implications
of his statement, but that's why we share our thoughts with our peers,
so that they can consider them from a different perspective and share
with us their interpretations and concerns about our writing, the  
meaning
behind it and the implications on the rest of the universe. Right?

> For

You'd need to be more specific. As you state it, my answer is that  
you're
clearly and obviously wrong.

If you were to be more specific in your wording (and the specificity  
went
in the direction I'd expect) there's a chance I'd agree with you, but  
at the
moment what you're saying is so broad and vague that it's clearly wrong.

Cheers,
   Steve

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 7 Dec 2007 13:41:39 -0500

On Friday 07 December 2007 13:23, Steve Atkins wrote:

> you're clearly and obviously wrong.
>
Personally, I'd invest more time and effort in careful wording if I weren't 
convinced this is all just playing gotcha and were in fact a serious 
discussion.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Fri, 07 Dec 2007 10:52:23 -0800

Steve Atkins wrote:
> with us their interpretations and concerns about our writing, the meaning
> You'd need to be more specific. As you state it, my answer is that you're
> If you were to be more specific in your wording (and the specificity went
> in the direction I'd expect) there's a chance I'd agree with you, but at 
> the

   It sure isn't obvious to me, and I'm afraid that I'm at the end
   of the road here as I can't figure out what set of axioms that either
   you or Dave are operating from for that not be true. From the looks
   of it, that set of axioms leads to "SSP == bad", so I again wonder
   why you're wasting your time, unless it is to prevent SSP from being
   published.

		Mike

---

From: Eric Allman <[email-masked]>
Date: Fri, 07 Dec 2007 10:58:20 -0800

>       what it should do with mail that is from a third

You left out an important part of what SSP should (in my opinion, 
completely legitimately) try to do:

        SSP is one organization's attempt to tell another what it
        should do with mail that is from a third organization that
        claims to be from the first organization.

Of course, SSP also includes guidance on unsigned messages.

eric

---

From: Steve Atkins <[email-masked]>
Date: Fri, 7 Dec 2007 11:06:37 -0800

>   why you're wasting your time, unless it is to prevent SSP from being

I like DKIM.

Publishing a bad (harmful or overly complex or with no actual benefit
or...) protocol tied closely to DKIM would be bad for DKIM
deployment.

So... I either want SSP to not be bad, or for it to not be published,
or (worst case) for it not to be widely deployed.

I'd prefer the former. If things continue as they are I'm likely to
get the latter, so if I wanted that, I could just step away from the
abuse now[1] and let y'all get on with it.

I'd rather take yet another attempt at getting people to look at the
fundamental flaws in it, and see if they can be reduced. Previous
attempts to do that haven't worked, leading to the bad protocol we
have now, but I remain optimistic that at least some of the less verbose
folks in the WG are open to such concerns.

Cheers,
   Steve

[1] If you think the on-list stuff is bad, you should see the off-list
screaming and shouting and ranting and threats. One of my
favorites reminded me of early 90s era usenet kooks:

"I have all the moral mission and incentive to publish articles
and testimonies on blogs, the news rags, technical journals, EFF
and especially the FCC regarding my security concerns with DKIM
and FCC, on how BIG COMPANIES and DMA members are going
to damage the network for the rest of the world."
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 7 Dec 2007 19:10:52 -0000

>   why you're wasting your time, unless it is to prevent SSP from being

An SSP that publishes actual things that a sender actually does, is
non-controversial. For example: this domain signs all the mail it
emits that has its domain on the From: line, or that domain emits no
mail at all with its domain on the From: line.

It's the mountain of add-on semantic baggage that's a problem.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Fri, 07 Dec 2007 14:45:51 -0500

> or...) protocol tied closely to DKIM would be bad for DKIM

Steve,

Are you comfortable with a DKIM only world, if not, what should be 
augmented with it to secure some basic exploitations?

Or

Are you comfortable with a DKIM only world with verifiers only treating 
valid signatures "more special" than the rest, including a verifier 
seeing a domain with all three types of messages coming in, treating 
these less special?

     NO signature
     Valid Signature
     Invalid Signature

Which ones are more important?

What I am pointing out is that, forget SSP, forget everything else but 
consider only DKIM, why should a verifier go to the trouble and cost of 
development to process DKIM messages when its only interested in the 
valid ones and ignoring the rest?

How is the domain protected with is new DKIM signer responsibility?

He is only responsible for the mail he does signs and not responsible 
for his domain mail he intentionally decides not to sign?

My point in all these question is that there has to be some technical 
protocol consistency in all this.  Forget SSP, use something else, who 
cares!   I have a hard time believing Verifiers are just going to look 
for the valid needle in the haystack while ignore all the other 
potential thorns.

Of course, we have a problem with mail integrity mishaps.

But it doesn't really make sense for verifiers to just accept or treat 
more special the valid signature and leave them in limbo with the same 
domains being exploited with fake signatures or just DKIM ignorant 
legacy bad guys spoofing with non-signed messages.

So in one respect, I really don't care what technology XYZ is, we need 
something to help protect against DKIM fallacies.

In the other respect, SSP is as good as it gets, in my opinion, as a 
open public protocol which interfaces quite well with the possible DKIM 
signer results.

DKIM risk falling into a "batteries not included" dilemma that many 
other early rudimentary technologies have suffered.

--
HLS

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Dec 2007 11:49:26 -0800

Sorry it was not clear that the issue has been that working group discussion 
has only been from the perspective you describe and rather steadfastly 'left 
out' the one I described.

Of course, any reasonable discussion would include both. But that first 
requires acknowledging the relevance of both.

d/

-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 7 Dec 2007 14:57:39 -0500

> or...) protocol tied closely to DKIM would be bad for DKIM

DKIM has one property that I believe is very useful for some (not saying you, 
I don't know): 

It has no value without some type of add-on.  It needs either something like 
SSP or a reputation service.  SSP we could standardize (I think we know 
enough technically if we decide to do it), but standarizing anything about 
reputation is something we are a long way from.  So it appears to me that 
some people want DKIM + proprietary add-on = profit.

> or (worst case) for it not to be widely deployed.

If it's bad, I think the not widely deployed will take care of itself.

> folks in the WG are open to such concerns.

Well we've been through this all at least twice.  Once when we did the charter 
and once when we did the requirements documents.  I don't see anything here 
other than reopening issues around which there was already WG consensus 
without any new information beyond I didn't like the result the first two 
times we did it.

If some of my responses are terse or not perfectly formed semantically, I ask 
for your indulgence and please write it off to WG fatigue.

Scott K

---

From: Eric Allman <[email-masked]>
Date: Fri, 07 Dec 2007 12:07:30 -0800

I do not agree with your position, which, as I understand it, seems 
to be that SSP is attempting to impose its will upon verifiers.  It's 
not, and it never was.  You've been choosing to ignore the parts of 
the spec that make that clear, and focus on the words that we have 
chosen and explicitly defined, interpreting them out of context and 
in your own way.

I've got no problem with adjusting language to clarify things, but I 
feel that your input has been unhelpful, and the fact that you've 
read over earlier versions of relevant documents without apparent 
concern until now is troublesome.

Senders have every right to tell the world how they would prefer that 
their mail be treated by recipients.  Of course they can't be sure 
their preferences will be honored, but they have every right to make 
the request.

eric

--On December 7, 2007 11:49:26 AM -0800 Dave Crocker 
<[email-masked]> wrote:

> Sorry it was not clear that the issue has been that working group
> discussion has only been from the perspective you describe and
> rather steadfastly 'left out' the one I described.
>
> Of course, any reasonable discussion would include both. But that
> first requires acknowledging the relevance of both.
>
> d/
>
> Eric Allman wrote:

---

From: [email-masked] (Wietse Venema)
Date: Fri, 7 Dec 2007 15:15:05 -0500 (EST)

> It's the mountain of add-on semantic baggage that's a problem.

I agree. SSP is good for senders to announce what mail they send
and/or sign. That's the non-controversial part.

The rest I see as false expectations based on false assumptions.

	Wietse

---

From: Jim Fenton <[email-masked]>
Date: Fri, 07 Dec 2007 13:48:23 -0800

Dave Crocker wrote:
> Hence my asking during the meeting whether we weren't seeking to have
> random receiving services enforce contractual issues that are internal
> to the owner of the domain.
>
> It makes enormously good sense for us to seek to rein in rogue
> independent third parties that have no relationship to the domain owner.
>
> However to ask random recipients to enforce internal policies of the
> domain owner seems considerably beyond what is reasonable for an
> Internet scale protocol service.

It isn't the internal policy that we're seeking to enforce.  It's that,
as a result of the fact that the internal policies are set up a
particular way, that makes it possible to detect other unauthorized uses
of the domain more directly.  We may end up "enforcing" (your term, not
mine) internal policies in the process, but that's a side effect.

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Fri, 07 Dec 2007 14:24:18 -0800

> Of course, SSP also includes guidance on unsigned messages.
That and "organization" gives a lot more legitimacy to the kind of
third parties that SSP is trying stop. But this whole formulation is
problematic though. Better is:

     SSP is an organization's attempt to *inform* receivers what its
     practices are so that receivers can make better disposition decisions
     about mail purporting, but without DKIM substantiation, to have
     originated from that organization.

       Mike

---

From: Steve Atkins <[email-masked]>
Date: Fri, 7 Dec 2007 14:26:23 -0800

>> or...) protocol tied closely to DKIM would be bad for DKIM

(There's not much SSP content here. Skip to the final section, or the  
next message, if you like.)

> augmented with it to secure some basic exploitations?

A DKIM-only world would be pretty useless. DKIM is mostly a base on  
which to build other things.

>
> Or
>
> Are you comfortable with a DKIM only world with verifiers only  
> treating valid signatures "more special" than the rest, including a  
> verifier seeing a domain with all three types of messages coming  
> in, treating these less special?
>
>     NO signature
>     Valid Signature
>     Invalid Signature
>

Well, as an aside, two of those categories aren't valid. There's only  
"Valid DKIM signature" and "No valid DKIM signature".

Neither is "more important", they're two types of email that will  
probably be processed differently by the receiver.

DKIM-signed mail will likely be cross-referenced with third-party  
data sources, and moved to the red carpet if it's found to be on  
them. If not, the longevity and history of it's DKIM identity will be  
queried, and if it's from an author with a history of sending wanted  
email, it'll be moved to the red carpet. If neither of those, it'll  
likely be treated the same as unsigned mail.

Unsigned mail will be treated as it is now - based on the content,  
and the reputation of other identifiers in the email (e.g. source IP  
address).

Some of this is driven by the receivers needs, though things like  
registration with third-party data providers will likely be driven by  
a mixture of sender and receiver needs. (And, don't forget, receivers  
and legitimate senders have pretty much the same goals - keeping the  
end recipients happy).

>
> What I am pointing out is that, forget SSP, forget everything else  
> but consider only DKIM, why should a verifier go to the trouble and  
> cost of development to process DKIM messages when its only  
> interested in the valid ones and ignoring the rest?

Because a valid DKIM signature identifies the author 100% reliably.  
That allows the receiver to do a number of things.

It lets them track the reputation of the author, both via internal  
reputation tracking and external reputation and certification  
services - meaning that they can reduce the false positives of their  
spam filters.

It allows them to cross reference that author identity with external  
third party sources of data (which will allow many of the advantages  
that goodmail has been hawking, including, for instance, a unique,  
unfakeable badge in the MUA that the mail came from, for example, a  
financial institution that is accredited by the US FDIC).

It allows them to run feedback loops, unsubscription methods and  
suchlike much more reliably and with lower maintenance overhead, both  
for the sender and the receiver.

There's a strong incentive for good actors to maintain a consistent  
DKIM identity, and that allows all of the above, and a bunch of other  
things. All good, solid operational benefits.

> He is only responsible for the mail he does signs and not  
> responsible for his domain mail he intentionally decides not to sign?

Of course not. He is responsible for all mail he emits.

But he is choosing to tie the signed mail to a persistent identity,  
which will (if he has a history of good behavior, or is accredited by  
a third-party) affect positively the way that mail will be handled by  
the receiver.

I suspect that only signing a fraction of mail sent will be not  
unusual for some types of sender, as will signing with different  
identities for different sorts of mail.

>
> My point in all these question is that there has to be some  
> technical protocol consistency in all this.  Forget SSP, use  
> something else, who cares!   I have a hard time believing Verifiers  
> are just going to look for the valid needle in the haystack while  
> ignore all the other potential thorns.

I think it'll mostly be driven by two things. Reputation tied to  
persistent identity and third-party accreditation. They're easy to  
implement (based on current technology, just taking advantage of a  
much better persistent identity from DKIM), and very effective.

> But it doesn't really make sense for verifiers to just accept or  
> treat more special the valid signature and leave them in limbo with  
> the same domains being exploited with fake signatures or just DKIM  
> ignorant legacy bad guys spoofing with non-signed messages.
>
> So in one respect, I really don't care what technology XYZ is, we  
> need something to help protect against DKIM fallacies.

That technology is probably a mixture of reputation and third-party  
accreditation.

>
> In the other respect, SSP is as good as it gets, in my opinion, as  
> a open public protocol which interfaces quite well with the  
> possible DKIM signer results.

I'd disagree on the "as good as it gets" in implementation terms, but  
that's a minor issue that can be ignored. Other than that, yes, it's  
pretty similar to any conceivable protocol based on self-accreditation.

Lets consider "phishing", which is about the only threat there's much  
agreement that SSP may be used for.

If you exclude reputation and accreditation from the setup, and rely  
*solely* on DKIM and SSP then there is absolutely no difference  
between mail from [email-masked] and sales@ bq--aq276yx7mh7xs.com[1]

They're both DKIM signed. They both have valid SSP records - in fact  
the bq--aq276yx7mh7xs.com SSP records may be stricter than the  
ebay.com ones, as they don't care if some fraction of their mail is  
discarded.

So, what do you do now? SSP can only protect an exact sequence of  
bytes in one header, the associated domain. It cannot protect a  
brand. It cannot protect the sender as rendered to the recipient in  
an MUA. It doesn't even try to protect any use of the brand in the  
body of a message.

There's a longer discussion as to why "stopping some phishes is not  
only pointless, but may be actively harmful", but the bottom line is  
that the only thing SSP can protect is a particular byte sequence.

Protecting against use of a particular byte sequence is unlikely to  
provide any real benefit to the sender or recipient unless it is  
cross-referenced with a list of "legitimate senders" of some sort.  
And that has been rejected by those considering SSP as useful in it's  
current form (partly because once you actually have a third-party  
list of that sort you don't need the self-accreditation of SSP, just  
the authentication of dkim).

Hence, again, my question as to what threat SSP is intended to  
protect against?

(That's actually a different question to "what can SSP be used for"  
and, when it comes to making SSP useful, a more useful question to  
answer.)

Cheers,
   Steve

[1] For bq--aq276yx7mh7xs.com read "any domain name that'll be  
rendered similarly to ebay.com in the recipients MUA". or "something  
semantically similar to ebay.com" or "anything that a recipient  
might, with no additional data, believe to be a legitimate eBay domain".
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Fri, 07 Dec 2007 14:35:21 -0800

> folks in the WG are open to such concerns.
You know Steve, this is a very long thread and you've contributed quite
a bit to it. I'll say that I have absolutely no clue what in particular 
(s) you
think is screwed up. All I know is that you don't like it, and that we need
to start from first principles again.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 07 Dec 2007 14:40:16 -0800

Dave Crocker wrote:
> discussion has only been from the perspective you describe and rather 
> steadfastly 'left out' the one I described.
>

We have acknowledged the relevance of both. This was discussed
ad nauseum in the thousands of messages about third party vouching,
added as provisional requirements, ID's written, and ultimately rejected.
I'm not sure how you could have missed that, but I know that my mind
was numb for the experience.

       Mike

---

From: Hector Santos <[email-masked]>
Date: Sat, 08 Dec 2007 13:41:26 -0500

> The rest I see as false expectations based on false assumptions.

Hi Wietse,

Since there is a cited interest to "start from principles" with the 
"less verbose people" to finally solve the problem with "flawed 
attempts" before, may I ask what conclusions or benefits can be made 
with what you agree with are non-controversial?

In other words, if SSP is good for senders to  announce (exposing to the 
everyone, including DKIM verifiers):

      a) what mail they are sending, and/or
      b) what mail they are signing?

then for what purpose is that announcement is required?  What usefulness 
does it offer to anyone?  Why will the verifier need it? Can it be used 
for mail dissemination? for confirmation of valid usage? For detection 
of fraudulent usage?  If so, what level of accuracy is there?  If there 
are no benefits, then what purpose is the announcement for?

-- 
Sincerely

Hector Santos, CTO

---

From: Dave Crocker <[email-masked]>
Date: Sat, 08 Dec 2007 15:00:22 -0800

Mike,

Given the existence of thousands of messages in the archive, it won't be much 
effort for you to point me to a thread of them.  The one thing I will ask, 
however, is that it not merely be a reference to the issue, but rather a 
thread in which the perspective is in fact, considered and incorporated into 
the design process.

I ask for the pointer because I'm not aware of such consideration taking place.

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Sat, 08 Dec 2007 18:44:49 -0500

Hi Steve,

Version 1.0 of my response to you here was rather terse. Version 1.1 
cleaned it up. Version 2.0 reduced it down to just answering your last 
question, and this version 3.0 is what ended up with which I hope can 
serve as mush shorter outline. I just hope that the reduction and 
removal of more complete insights and reasoning doesn't water down the 
key points:

   o A/R Out of Scope.
   o SSP is not about A/R.
   o SSP addresses DKIM protocol consistency.
   o SSP does not address Phishing.
   o Concern: Discovery Process.
   o Concern: # of lookups required.
   o Concern: 3rd party usage
   o Concern: Mailing list usage

o A/R Out of Scope.

A/R (Accreditation/Reputation) concepts is out of scope. I will just 
like to note that this on-going A/R injection only served to be a source 
of contention and continues to defuse the SSP working group efforts.

There are endless reasons why it is out of scope, both technically and 
very much political.  Even then, A/R does not solve the problem SSP 
attempts to address.

Since A/R concepts is out of scope, I will only say that it is already 
viewed that it may be an additional layer in a total solution framework, 
but it is not a requirement for DKIM.

o SSP is not about A/R.
o SSP addresses DKIM protocol consistency.

SSP is not a reputation concept. It does not apply to who is GOOD or 
BAD. It applies to all.  SSP address the protocol consistency of the 
DKIM usage.  It looks at all the possible outcomes and which one can be 
protected from exploitation.  It applies to all - good and bad. The bad 
can be DKIM/SSP compliant as well.   This is where A/R layer may apply 
but it is not a part of the protocol consistency requirement SSP addresses.

o SSP was never designed to address Phishing.

SSP only address DKIM protocol consistency. It is not an ANTI-SPAM 
concept in the sense it is making the 'subjective decision' of whats 
good or bad or what "appears" to be bad with phished domains.  Phished 
domains are not addressable with SSP and for the record, A/R concepts 
can not adequately address it as well.

o Concern: 3rd party usage.
o Concern: Mailing list usage.
o Concern: Discovery Process.
o Concern: # of lookups required.

Since 2005, from the old MAILSIG list to this DKIM list, the numerous 
SSP discussions, threads, debates and thorough analysis by many people, 
  the  major areas of disagreement or contention can best be summarized 
or to included the above items.

I believe that the mailing list usage is still up in the air, but it 
also falls as a sub-set of 3rd party issues.  The key issue with the 
mailing list question is by far the mail integrity issues is no doubt 
introduces.

But overall, since SSP-01, there has always been a source of contention 
on the 3rd party usage.  I believe I called this "Managed vs Unmanaged 
3rd party usage:

      Managed basically restricts or controls who is allowed
      to sign on behalf of the originating domain holder.

      Unmanaged allowed for open ended 3rd party signing.
      I believe John Levine was an advocate of this by elegantly
      pointing out asking what is the difference as long as
      the 3rd party signature is valid.

DKIM allows for a valid DKIM message if at least one signature is valid.

If there was one vital agreement with all parties is this:

      The valid 1st party signature provides a message transaction
      with a high degree of confidence for its validity.

That doesn't not say it is good or bad guy. But it is protocol 
consistent with little need to do anything else in addressing its 
authenticity.  The A/R to determine the GOOD/BAD question is a different 
layer and out of scope consideration.

So the 3rd party usage issue was one of the complex areas that in theory 
came down to offering some form of "list" concept where a verifier can 
use to get domain authorization for the 3rd party usage.

The question was then how would that be done.

There were many discovery process and hotly contested ideas proposed 
form simple list ideas in the SSP records to DNS recursive sub-domain 
lookup ideas.

And finally, in all cases, the overhead concern with # of DNS lookup 
required was also part of the issue in addressing the discovery process. 
  In addition, there was the debate of when it should be done.

All these were address and my review, I personally think SSP allows for 
DKIM protocol consistency checking.

It still fits total picture with any additional A/R implementation layer 
because SSP doesn't address that part of the mail dissemination process.

In the model I see, it can be illustrated as so:

    +-----------+
    |  PAYLOAD  |
    +-----------+
         |
         v
  +----------------+
  |                |                            +------------+
  | DKIM           |--------------------------->| CONTINUE   |
  | Signature      | UNSIGNED: OPTIONAL         +------------+
  | Authorization  |
  | Protocol       |
  |                |                            +------------+
  |                |--------------------------->|            |
  |                | SIGNED: EXPIRED            |            |
  |                |--------------------------->|            |
  |                | NO MAIL EXPECTED           | FAILURE/   |
  |                |--------------------------->| CLASSIFY   |
  |                | UNSIGNED: REQUIRED         |            |
  |                |--------------------------->|            |
  |                | SIGNED: NOT EXPECTED       |            |
  |                |--------------------------->|            |
  |                | 3P SIGNED: NOT ALLOWED     |            |
  +----------------+                            +------------+
         |
         |
      SIGNED
      MESSAGE
         |
         v                                      +------------+
    +--------------+                            | CONTINUE/  |
    |              |--------------------------->| CLASSIFY   |
    |              |    INVALID SIGNATURE       +------------+
    | DKIM         |
    | SIGNATURE    |
    | VERIFICATION |                            +------------+
    |              |--------------------------->| PASS       |
    |              |    VALID SIGNATURE         +------------+
    +--------------+

    Figure 2: DKIM Signature Authorization Protocol Outline

NOTE: THE DIAGRAM IS NOT IMPLYING HOW SSP-01 IS OUTLINED.  It simply 
illustrates to show the DKIM protocol consistency checking is related to 
a SSP idea.

So SSP is just a mechanism to make sure the DKIM protocol is used 
properly and also not abused with the most obvious exploitations.

As was mentioned, the SSP model is for compliant systems - both good or 
bad people. So none of this doesn't eliminate any additional layers for 
actually determining if the message should be accepted or rejected.

-- 
Sincerely

Hector Santos, CTO

Steve Atkins wrote:
>> verifier seeing a domain with all three types of messages coming in, 
>> treating these less special?
>>
>>     NO signature
>>     Valid Signature
>>     Invalid Signature
>>
> DKIM-signed mail will likely be cross-referenced with third-party data 
> sources, and moved to the red carpet if it's found to be on them. If 
> not, the longevity and history of it's DKIM identity will be queried, 
> and if it's from an author with a history of sending wanted email, it'll 
> be moved to the red carpet. If neither of those, it'll likely be treated 
> the same as unsigned mail.
> 
> Unsigned mail will be treated as it is now - based on the content, and 
> the reputation of other identifiers in the email (e.g. source IP address).
> 
> registration with third-party data providers will likely be driven by a 
> mixture of sender and receiver needs. (And, don't forget, receivers and 
> legitimate senders have pretty much the same goals - keeping the end 
> recipients happy).
> 
>>
>> consider only DKIM, why should a verifier go to the trouble and cost 
>> of development to process DKIM messages when its only interested in 
>> the valid ones and ignoring the rest?
> 
> Because a valid DKIM signature identifies the author 100% reliably. That 
> allows the receiver to do a number of things.
> 
> reputation tracking and external reputation and certification services - 
> meaning that they can reduce the false positives of their spam filters.
> 
> There's a strong incentive for good actors to maintain a consistent DKIM 
> identity, and that allows all of the above, and a bunch of other things. 
> All good, solid operational benefits.
> 
>>
> which will (if he has a history of good behavior, or is accredited by a 
> third-party) affect positively the way that mail will be handled by the 
> receiver.
> 
> I suspect that only signing a fraction of mail sent will be not unusual 
> for some types of sender, as will signing with different identities for 
> different sorts of mail.
> 
>>
> implement (based on current technology, just taking advantage of a much 
> better persistent identity from DKIM), and very effective.
> 
>>
>> open public protocol which interfaces quite well with the possible 
>> DKIM signer results.
> 
> *solely* on DKIM and SSP then there is absolutely no difference between 
> mail from [email-masked] and sales@ bq--aq276yx7mh7xs.com[1]
> 
> They're both DKIM signed. They both have valid SSP records - in fact the 
> bq--aq276yx7mh7xs.com SSP records may be stricter than the ebay.com 
> ones, as they don't care if some fraction of their mail is discarded.
> 
> So, what do you do now? SSP can only protect an exact sequence of bytes 
> in one header, the associated domain. It cannot protect a brand. It 
> cannot protect the sender as rendered to the recipient in an MUA. It 
> doesn't even try to protect any use of the brand in the body of a message.
> 
> There's a longer discussion as to why "stopping some phishes is not only 
> pointless, but may be actively harmful", but the bottom line is that the 
> only thing SSP can protect is a particular byte sequence.
> 
> cross-referenced with a list of "legitimate senders" of some sort. And 
> that has been rejected by those considering SSP as useful in it's 
> current form (partly because once you actually have a third-party list 
> of that sort you don't need the self-accreditation of SSP, just the 
> authentication of dkim).
> 
> Hence, again, my question as to what threat SSP is intended to protect 
> against?
> 
> (That's actually a different question to "what can SSP be used for" and, 
> when it comes to making SSP useful, a more useful question to answer.)
> 
> Cheers,
>   Steve
> 
> 
> [1] For bq--aq276yx7mh7xs.com read "any domain name that'll be rendered 
> similarly to ebay.com in the recipients MUA". or "something semantically 
> similar to ebay.com" or "anything that a recipient might, with no 
> additional data, believe to be a legitimate eBay domain".
> NOTE WELL: This list operates according 
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
> 
>

---

From: [email-masked] (Wietse Venema)
Date: Sat, 8 Dec 2007 18:46:59 -0500 (EST)

With DKIM, The Signer Domain says "I signed this mail".  It does
not approve content, or state that content is benign.  The receiver
decides whether to give this signature preferred treatment.  There
is little or no controversy about this aspect of DKIM.

With SSP, The Sender Domain says "I send such and such mail":  if
any is signed, or not signed.  This is primarily relevant for mail
without valid signature by The Sender Domain.  There is little or
no controversy about this aspect of SSP.

There is controversy about attempts by The Sender Domain to make
statements about mail handling practice by other parties such as
forwarders or receivers.

I see these as well-meaning attempts to provide a magic wand against
email forgery, just like the one that SPF attempted to provide;
attempts that are rooted in the assumption that The Sender Domain
can somehow constrain forwarder or receiver behavior.

In my opinion, credibility is determined by the combination of
Sender Domain and Signer Domain; different combinations having
different credibility, many combinations having none at all. If
SSP attempts to infringe on or otherwise constrain forwarder or
receiver practice, then it may very well become as relevant as SPF.

	Wietse

---

From: Hector Santos <[email-masked]>
Date: Sat, 08 Dec 2007 19:30:55 -0500

> is little or no controversy about this aspect of DKIM.

Agree, as in my message to Steve shows and was written in the draft I-D 
DSAP and as it was stated at least numerous times in the last two years, 
by myself and others.

> no controversy about this aspect of SSP.

If I understand you, sure.  But I think you have a decoupling mentality 
about SSP mentality where I don't and I only say that because I am very 
interested in eliminate abusive and exploited DKIM usage.

> statements about mail handling practice by other parties such as

Well understood.

> can somehow constrain forwarder or receiver behavior.

Ok, I am not particularly interested in name calling or anything like 
that, but sure there was a TECHNICAL DESIGN issue with SPF when it came 
to indirect mail transactions where there is more than on hop.

DKIM attempts to address the practical issue and it is marketed as so in 
its technology comparisons.

DKIM-BASE does solve this problem, however, its premise is based:

    - no middle ware mail integrity issues,

    - No regard as too is the signer, which includes that if the
      original integrity is broken, the middle ware will correct
      it.

So yes, DKIM-BASE does solve the forwarding problem but it that not to 
say it addresses the fraudulent usage problem or mail integrity issues 
that are possible when more than one hop or there is some mail 
resubmission concept (Mailing List) used.

> receiver practice, then it may very well become as relevant as SPF.

Again, I agree over all, but I really don't care and I don't think it 
will be productive to compare it to SPF or question its relevance.

If there is one legitimate comparison, then we should look at the 
relevance of DomainKeys (DKEYS).

DKEYS is a prime example of where we have problems which DKIM attempts 
to address.

For the most part, DKEYS == DKIM when there is no SSP, and my opinion, 
DKIM risk falling into the same waste land if we don't resolve the SSP 
issue.

SSP is not about reputation or accreditation.

And no one has ever said that a A/R system should not be part of some 
total picture or solution for a product offering.  Thats a given, but I 
  am not looking to lock in DKIM implementation with some very limited 
"batteries required" Trust Service concept.

-- 
Sincerely

Hector Santos, CTO

---

From: Michael Thomas <[email-masked]>
Date: Sat, 08 Dec 2007 18:18:16 -0800

Dave Crocker wrote:
> Mike,
>
> Given the existence of thousands of messages in the archive, it won't 
> be much effort for you to point me to a thread of them.  The one thing 
> I will ask, however, is that it not merely be a reference to the 
> issue, but rather a thread in which the perspective is in fact, 
> considered and incorporated into the design process.
>
Where you're Goldilocks and I get to find the porridge. Check.
> I ask for the pointer because I'm not aware of such consideration 
Since the modus operandi here seems to be a whack-a-mole of ancient issues,
I'd just assume find my amusement elsewhere.

       Mike

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 9 Dec 2007 04:14:07 +0100

Hector Santos wrote:

> there was a TECHNICAL DESIGN issue with SPF when it came to 
> indirect mail transactions where there is more than one hop.

The decision that RFC 1123 5.3.6(a) and anything built on it
is "broken by design" was intentional, obvious, and covered
by RFC 821.  If folks seriously try to compare an enumeration
of "permitted" sender IPs while talking with one of their own
MTAs on the side of the receiver it unsurprisingly won't work.

The number of hops has nothing to do with it, there can be as
many hops as you like before the border or behind it, check
SPF at the border and you're fine.  As long as you reject FAIL
at the border you are also fine in scenarios where unmodified
MAIL FROMs are forwarded by a third party to you.  

Pretty basic, no "Bob can't resend mail from Alice" involved.
As soon as Bob got Alice's mail it is his mail, no amount of
weasel words could change this.

> DKIM-BASE does solve the forwarding problem

DKIM doesn't "solve" a "forwarding problem", for starters it
doesn't have any "forwarding problem", no need to "solve" it.

>> If SSP attempts to infringe on or otherwise constrain forwarder
>> or receiver practice, then it may very well become as relevant
>> as SPF.

> Again, I agree over all, but I really don't care and I don't
> think it will be productive to compare it to SPF or question
> its relevance.

Comparing http://www.openspf.org/Statistics with a not yet ready
draft would be pointless, and SSP is targeted for a far narrower
audience, victims of phishing.  Comparing it with PRA could make
sense at some point in time, the SSP folks will say when, they
start later, earlier comparisons would be unfair.

> If there is one legitimate comparison, then we should look at
> the relevance of DomainKeys (DKEYS).

Comparing the deployment a not yet ready draft with a historic
RFC, what's that good for ?  Sounds like comparing SPF with
the true RFC 821 believers still trying to use reverse routes
for their "forwarding problem".

> DKIM risk falling into the same waste land if we don't resolve
> the SSP issue.

I don't get it, how can DKIM fall into waste land when GMail,
Ironport, and others use it ?  Unfortunately GMail doesn't
publish SPF FAIL, but they offer at least a PASS, apparently
they also reject FAIL.  No waste land in sight, or did you
mean PRA ?

Domainkeys also didn't fall into waste land, it was published
as historic after DKIM was ready, intentionally.

> I am not looking to lock in DKIM implementation with some
> very limited "batteries required" Trust Service concept.

If you use DKIM as receiver without some kind of white list
I've no idea what you are actually doing, but IMO you don't
need a Trust Service to create a white list, roll your own.

You could even check some kind of "best guess SSP" before
SSP is ready, like "best guess SPF" that's nothing that will
end up in a RFC, it's deep in "receiver policy" territory.

 Frank

---

From: Hector Santos <[email-masked]>
Date: Sun, 09 Dec 2007 00:08:26 -0500

> doesn't have any "forwarding problem", no need to "solve" it.

I know one thing Frank, there is no way on this living earth am I going 
to get into a semantics game with you. But ........

If I send mail to a host which is listed as the MX destination, and 
unbeknown to me this SPF ignorant host receives and relays to mail to 
some "real final destination" host using SPF, the real host will result 
with a SPF=FAIL.

If I was DKIM signing my mail, the "real final destination" host 
supporting DKIM, won't reject this multiple hop relay issue that raw SPF 
has.

> audience, victims of phishing.  

SSP is not targeted at phishing targets nor can address it.  Its a 
chicken and egg situation.

> RFC, what's that good for ?  

I know you like to  compare the RFC documents.  :-) I will compare the 
implementations where they are *almost nearly* the conceptual same when 
SSP is not considered.  After all, if not all, most people who 
supporting DKEYS and DKIM are using the same code.  Take away SSP and we 
have the same low benefits with DKIM that DKEYS has.

> Ironport, and others use it?  

Because by far the majority of the receivers are not processing it.
There is little payoff in processing it without a policy concept.

For example, I just send this from my gmail account to my isdg.net 
account, and the message had this gmail DKIM-Signature, and the 
Domainkey-Signature header (I broke it up for readability should only 
the relevant parts)

DKIM-Signature:
   v=1; a=rsa-sha256; c=relaxed/relaxed;
   d=gmail.com; s=gamma;
   h=domainkey-signature:
     received:
     received:
     message-id:
     date:
     from:
     to:
     subject:
     mime-version:
     content-type:
     content-transfer-encoding:
     content-disposition;

DomainKey-Signature:
   a=rsa-sha1; c=nofws;
   d=gmail.com; s=gamma;
   h=message-id:
     date:
     from:
     to:
     subject:
     mime-version:
     content-type:
     content-transfer-encoding:
     content-disposition;

There is no SSP record for gmail.com.  The only reliance I have that 
this is even worthy of complex processing is when its valid 1st party 
domain.  Which has no value in the trust field unless I just want to say 
that "Ok, it came from GMAIL, there was no mail integrity changes."

Here the problem:

   1) 3rd party signer, but uses From: [email-masked]

      If this is spam, I have a lot of wasted processing time,
      never mind the potential harm to end users.  They can
      also continue to spoof my gmail.com against me and others.

   2) No Signature,  someone can continue to use my gmail.com
      and send spam, malicious mail.

   3) DKIM exploits can use a fake signature or the same
      signature for all its bulk spamming.  The idea is to
      make it "look ok" even if its not valid.
      Wasted processing.

By having an SSP record, GMAIL.COM will be able to have some level of 
control. It helps protect my server, my users, other users and the 
GMAIL.COM brand name is better protected.

Now GMAIL.COM is an ESP and like other free accounts large ESPs, the 
gmail.com domain is already considered a junk address, people use it for 
JUNK, just look at your JUNK address.

          [email-masked]

If you don't think people see that with a "hmmmmm" pause, you should 
because it appears to be just like all the other spam junk. But thats 
besides the point.

GMAIL.COM has just increased the potential harm on others by exposing a 
no SSP DKIM operation.  There is little benefit without some policy concept.

Now, change that to BANK.COM where it is a much more guarded domain of 
high value, the issue is even more problematic. In other words, 
gmail.com is a big company but its domain is not a "High Value" domain 
because it can be used for anything.  Most people I know use the 
gmail.com account to direct their junk to and also use it for junk sign 
ups or to hide their identity, etc.

With Bank.com, would be a high-value concept because its limited in its 
usage - at least the bank would prefer it that way.

If bank.com does not have a strict SSP policy, it will be just as 
vulnerable as gmail.com.

A strict BANK.COM policy would prevent ALL 3rd party abuse, spoofs with 
no signature and also mail integrity problems it does not expect.

> Unfortunately GMail doesn't

I meant SSP.

Frank, just as a side note, you can not assume that all parties will be 
used every technology in place. DKIM/SSP must have a benefit on its own. 
  Of course, smarter systems will offer SPF/PRA or other things as well, 
but you can't design the DKIM/SSP protocols on the assumption they will 
be using other stuff as well.

> as historic after DKIM was ready, intentionally.

Well, again, I wasn't referring to "RFC" stuff.  I was referring to the 
thousands of message we received with Domainkey-Signatures and its 
ignored.  However, I am interested in processing DKIM if it comes with a 
SSP concept.

> need a Trust Service to create a white list, roll your own.

I did say local or 3rd party.

For us, in this particular area, we use an automated white/black list 
system.  Automated white when users send mail out to people, automated 
black when outbound mail deliver attempts is exhausted. I don't wish to 
get into the actual details so please don't nit pick on that. :-)

> end up in a RFC, it's deep in "receiver policy" territory.

My mentality in all this is solid, automated first level deterministic 
methods.  Leave the subject guess work to other artificial intelligence 
and/or heuristic concept at the second layer.

-- 
Sincerely

Hector Santos, CTO

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 9 Dec 2007 13:08:46 +0100

Hector Santos wrote:
 
> If I send mail to a host which is listed as the MX destination,
> and unbeknown to me this SPF ignorant host receives and relays
> to mail to some "real final destination" host using SPF, the
> real host will result with a SPF=FAIL.

Yep, that's precisely what happens if nobody cares about it.  If
you are lucky you get a nice 551 emulation (NDR from forwarder),
and you <eai> can make another plan </eai>.

> If I was DKIM signing my mail, the "real final destination"
> host supporting DKIM, won't reject this multiple hop relay
> issue that raw SPF has.

Right, to get in trouble with DKIM you need a clueless mailing
list or resender, and SSP.  On the other hand DKIM without SSP
might not really help you, if nobody bothers to whitelist you.

> There is no SSP record for gmail.com.  The only reliance I
> have that this is even worthy of complex processing is when
> its valid 1st party domain.

That they don't have SSP *yet* is no surprise.  They also have
no SPF FAIL, maybe they don't like FAIL because they fear that
it causes more support costs than not adding it.  Or they want
that users can use their GMail address as envelope sender via
other routes to some ("NEUTRAL") degree, and there was so far
no issue with massive forgeries.  AOL also uses only PASS, it
helps - you can accept PASS on probation, and bounce it later.
Or add white lists on top of a PASS, same idea as with DKIM...

>   also continue to spoof my gmail.com against me and others.

...right, so you won't add that third party to your white list.
 
>   and send spam, malicious mail.

You could emulate SSP by treating "no signature from gmail" as
less than NEUTRAL.  Admitteldly I don't like this, "less than
NEUTRAL" mails will often die after 30 days in a spam folder,
especially if it's a reliable spam folder otherwise.  But less
than NEUTRAL is also not bad enough for a reject, "SSP" is not
per se a bad idea.  Only the "first author" part hardwired in
RFC 5016 limits it to shaky assumptions about what "Bob" does.

> Now GMAIL.COM is an ESP and like other free accounts large ESPs,
> the gmail.com domain is already considered a junk address, 
> people use it for JUNK, just look at your JUNK address.

Nope, after twenty rounds of trying to find a free user account
for something (it wasn't GMail at this point in time, maybe it
was googlepages) I had enough and started the keyboard-random-
generator.  It's my second best address at the moment (the best
has of course SPF FAIL like my old addresses) for public use,
testing if IMAP is better today, etc. 

> If you don't think people see that with a "hmmmmm" pause, you
> should because it appears to be just like all the other spam
> junk.

Not really worse than nobody@xyzzy, no wannabe-spam deterrent.
 
> Most people I know use the gmail.com account to direct their
> junk to and also use it for junk sign ups or to hide their
> identity, etc.

Using a *Google* service to hide their identity, now here's a
seriously flawed idea.  I'd try "mailinator" for this, if it
still exists, only for harmless cases.

> If bank.com does not have a strict SSP policy, it will be 
> just as vulnerable as gmail.com.

If bank.com is too timid for SPF FAIL like gmail.com it also
won't be happy with SSP, mechanisms having an effect measured
by "rejects" cut in both directions depending on the receiver.

If legit mails can be trapped in spam folders they are lost,
no matter whose fault that was, and maybe bank.com fears this
outcome more than forgeries.  Look at Ebay and Paypal.  Either
a mechanism is toothless, or not, and then it can bite you.

> DKIM/SSP must have a benefit on its own. 

Sure.  DKIM alone must have a benefit of its own, I'd bet on
"more reliable than PRA PASS" wrt "traditional forwarding".

> we use an automated white/black list system.
[...]
> I don't wish to get into the actual details so please don't
> nit pick on that. :-)

Don't worry, I thought about some "auto-white" DKIM-PASS-no-
spam feedback loop, but then didn't mention it because five
minutes thinking weren't enough, not obviously trivial... ;-)

 Frank

---

From: [email-masked] (Wietse Venema)
Date: Sun, 9 Dec 2007 10:07:10 -0500 (EST)

After yesterday's massive agreement, today I'll expand some of my
statements with examples, and expose some limits.

Statement 1

Having the bank's Signer Domain in my local address book, I can
distinguish between mail that has The Bank's signature (known to
be good) and mail that does not. When I get mail from a criminal
bank with a name and logo similar to that of my bank, the criminal
Signer Domain won't match any bank that I know I have a business
relationship with, and I can treat it accordingly.

Although I wrote that signers make no statement on content, there
are valid reasons why a signer might want to do so.  For example,
an email security service provider might want to say "I signed this
mail" and thus offer assurance that mail is free from malware. Of
course they would leave any pre-existing signatures intact.

Statement 2

Some position SSP as a tool against phishing. For example, SSP can
make statements about mail that claims it is sent in The Sender
Domain's name, urging receivers not to open any letters that lack
a valid signature by The Sender Domain.

Unfortunately, this protection is effective only under the assumption
that the bad guys are stupid; namely that they will try to send
mail in the name of my bank without a valid signature by my bank.
But criminals don't necessarily play by the rules.

Specifically, SSP statements by my bank won't protect ME against
mail from a Criminal bank with a name and logo similar to that of
my bank. The Criminal bank will make it 100% SSP compliant and will
specify the strictest policy settings. Just like the real bank,
the Criminal's SSP will say "Trust me. I am a high-value target".

+------------------------------------------------------------------+
|Why would I believe the SSP from my bank, and not the SSP from the|
|criminal bank? Based on SSP alone, both have equal credibility.   |
+------------------------------------------------------------------+

As discussed under "statement 1", mail from the criminal is easily
exposed with a simple query against my local address book. The
criminal Signer Domain won't match any banks that I know I have a
business relationship with. I don't even have to go to an external
reputation service for that.

Conclusion

We have a paradox where DKIM-BASE does not promise protection
against phishing attacks, but it's near trivial to use for that
purpose with a local address book; while SSP protection against
phishing can be sidestepped near trivially because it is grounded
in statements by a Sender Domain whose trustworthiness is unproven.

In other words, SSP needs an external service to attest that the
Sender Domain's self-declared SSP does indeed represent a bona fide
business.  Supposedly, criminals won't be able to purchase such
attestation.  This is the dirty secret behind SSP.

        Wietse

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 08:37:19 -0800

> mine) internal policies in the process, but that's a side effect.

So, when I stood at the microphone and asked whether SSP was seeking to 
recruit recipients in enforcing contractual arrangements between a signer and 
their agents, and was told yes, that statement was incorrect?

This is merely one more example that, at base what we have here is a very 
serious challenge for anyone seeking to obtain clear, precise and consistent 
statements about SSP's purpose and use that have anything approaching working 
group consensus.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 08:42:41 -0800

Michael Thomas wrote:
> That and "organization" gives a lot more legitimacy to the kind of third
> parties that SSP is trying stop. But this whole formulation is problematic
> though. Better is:
> 
> SSP is an organization's attempt to *inform* receivers what its practices
> are so that receivers can make better disposition decisions about mail
> purporting, but without DKIM substantiation, to have originated from that
> organization.

Orwell is getting a lot of discussion, these days.  As well he should. The
tendency to deny or re-cast the meaning of simple, basic words has become common.

I will therefore suggest careful consideration that:

>    handling=  Non-compliant message handling request for the domain
>       (plain-text; OPTIONAL).  Possible values are as follows:
> 
>       process  Messages which are Suspicious from this domain SHOULD be
>          processed by the verifier, although the SSP failure MAY be
>          considered in subsequent evaluation of the message.  This is
>          the default value.
> 
>       deny  Messages which are Suspicious from this domain MAY be
>          rejected, bounced, or otherwise not delivered at the option of
>          the verifier.

is nothing so passive as "informing" receivers about a potential signer's 
practices.

Language like "message handling request" is requesting a specific behavior by 
the receiver.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 08:44:35 -0800

I would be interested in knowing whether anyone can explain the basis under 
which this sort of posting from an IETF working group document author is 
acceptable?

d/

Eric Allman wrote:
> I do not agree with your position, which, as I understand it, seems to 
> be that SSP is attempting to impose its will upon verifiers.  It's not, 
> and it never was.  You've been choosing to ignore the parts of the spec 
> that make that clear, and focus on the words that we have chosen and 
> explicitly defined, interpreting them out of context and in your own way.
> 
> feel that your input has been unhelpful, and the fact that you've read 
> over earlier versions of relevant documents without apparent concern 
> until now is troublesome.
> 
> their mail be treated by recipients.  Of course they can't be sure their 
> preferences will be honored, but they have every right to make the request.
> 
> eric
> 
> 
> 
> --On December 7, 2007 11:49:26 AM -0800 Dave Crocker <[email-masked]> 
> wrote:
> 

-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Sun, 09 Dec 2007 08:57:41 -0800

Please remind me which issue on the tracker we're discussing.

-Jim

Dave Crocker wrote:
> So, when I stood at the microphone and asked whether SSP was seeking
> to recruit recipients in enforcing contractual arrangements between a
> signer and their agents, and was told yes, that statement was incorrect?
>
> This is merely one more example that, at base what we have here is a
> very serious challenge for anyone seeking to obtain clear, precise and
> consistent statements about SSP's purpose and use that have anything
> approaching working group consensus.
>
> d/

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 9 Dec 2007 23:29:05 -0500

> no controversy about this aspect of SSP.

Agreed, particularly the "without valid signature by The Sender Domain".

> But criminals don't necessarily play by the rules.

I disagree.  I think that while the difference is small, I believe there is 
worthwhile benifit to preventing what I would call exact domain forgery.  
This is not a complete solution to phishing (I'm not sure such a thing 
exists), but one small piece.  While the difference between (for example - I 
didn't check to see if Paypal owns the alternate I show here) paypal.com and 
paypa1.com is small, it's a step.

> the Criminal's SSP will say "Trust me. I am a high-value target".

Agreed.  Neither (necessarily) will the address book trick you describe in 
Statement 1.  The address book trick is only one social engineering trick 
away from being on the good list.

Why would criminal bank's SSP matter?  SSP doesn't exist to help make positive 
assertions about good messages.  It exists to identify messages that fall 
outside the senders policy (or whatever we decided the P stood for).  Trying 
to assert "Passes SSP" as a criteria for acceptance would be a poor idea.

Assuming SSP asserts something positive beyond what DKIM asserts.  It doesn't.  
It allows a negative to be identified.

> attestation.  This is the dirty secret behind SSP.

I disagree.  I think it's the other way around.  I think without SSP, some 
additional secret secret sauce (could be a list of banks you deal with), DKIM 
buys you little.  With SSP there is a complete protocol set available that 
allows some subset of 'bad' messages to be identified and dealt with 
appropriatedly.

In reality, I think that you are correct and the bad guys will be deterred 
from sending messages exactly forging domains publishing restrictive SSPs.  
This will be a victory (albeit a small one).  

Scott K

---

From: [email-masked] (Wietse Venema)
Date: Mon, 10 Dec 2007 08:36:08 -0500 (EST)

> to assert "Passes SSP" as a criteria for acceptance would be a poor idea.

Does the Bank's SSP matter? I assume your answer is "yes".

My point is that SSP alone cannot distinguish between mail from my
Bank and mail from a Criminal who pretends to be a slightly different
bank.  It distinguishes only the stupid criminals who send mail in
the Bank's name without signature by the Bank.

> It allows a negative to be identified.

It is not in the Bank's interest to say negative things about the
Banks mail.

Likewise, it is not in the Criminal's interest to say negative
things about the Criminal's mail.

SSP alone does not distinguish between mail from a Bank and mail
from a Criminal who pretends to be a bank. That is SSP's dirty
little secret.

This was my final attempt to illustrate this fundamental problem.
I can lead the horse to the water but I can't force it to drink.

	Wietse

---

From: Graham Murray <[email-masked]>
Date: Mon, 10 Dec 2007 13:56:05 +0000

> the Bank's name without signature by the Bank.

Surely the Bank's SSP means that the criminal will not be able to send
mail in the banks name as he will not have access to the Bank's signing
key. Therefore such mail, irrespective of how stupid or clever the
criminal is, would not carry the Bank's signature. The criminal would,
of course, be able to send from a domain which makes you think,
erroneously, that it comes from your Bank - which is a different
problem entirely.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 10 Dec 2007 09:27:25 -0500

> > On Sunday 09 December 2007 10:07, Wietse Venema wrote:
...

> > Assuming SSP asserts something positive beyond what DKIM asserts.  It
> > doesn't. It allows a negative to be identified.
>

Fair enough.  Thank you for trying again.  I think we are in agreement about 
what SSP can't do.  It seems to me that the fundamental disagreement is about 
whether the relatively small thing is can do is worth doing or not.

What you describe as a "Dirty little secret", I don't think is a secret at 
all.

SSP can help receivers identify exact domain use by external entities.  For 
some classes of domains such use is overhwhelmingly likely to be fradulent 
and SSP can give receivers a way to reliably identify unauthorized use and 
reject such mail.  It's only a very narrow piece of the phishing problem, but 
one that I find worth dealing with (even if the end result is just that such 
messages don't get sent anymore because they stop working).

Scott K

---

From: Hector Santos <[email-masked]>
Date: Mon, 10 Dec 2007 09:47:51 -0500

> erroneously, that it comes from your Bank - which is a different

+1. Thank your Graham.

phishing also includes the form of using a "correctly spelled" domain 
name.  I just got one from eBay this morning which is 100% directly on 
pay with nearly everything that was discussed here, include the PHISHER 
awareness that new systems are taking into the account the SENDER.

Here is the relevant DNA of the message:

   Received: from socrate.agmasys.com ([193.201.171.65])
             by winserver.com (Wildcat! SMTP v6.2.452.2) with ESMTP
             id 101035781; Mon, 10 Dec 2007 07:22:20 -0500
   Received-SPF: softfail (winserver.com: domain of transitioning
                           [email-masked] does not designate
                           193.201.171.65 as permitted sender)
   Received: from User ([77.237.90.55])
           by socrate.agmasys.com (Merak 7.4.2) with ASMTP id EBY38091;
           Thu, 06 Dec 2007 22:17:40 +0100
   From: "eBay Member look4deals999"<[email-masked]>
   Subject: Question from eBay Member regarding Item #320189950244
   To: [email-masked]

But here is the clever phishing that was added to the top of the body:

    eBay sent this message on behalf of an eBay member via My Messages.
    Responses sent using email will not reach the eBay member. Use the
    Respond Now button below to respond to this message. [LEARN MORE!]

    [RESPOND NOW]

Bot the Learn Mode and Response Now buttons were wrapped with webbot 
phisher hexed base IP (0x58.0xf8.0x2.0x81)links.

So this is a prime case, if ebay was to become a DKIM signer, it can use 
SSP to help protect against these obvious low level abuses.

Of course, eBay.com is a bad example because obviously it has an open 
policy of providing users email domain addresses.  I don't use ebay, so 
I don't sure what their open policy is.

But for a more restricted high value domain, like a Bank and so many 
others in the commercial world, including us, no doubt, we can benefit 
from non-signed or fake signature or 3rd party valid signature frauds 
using SSP with strict DKIM signing policies.

-- 
Sincerely

Hector Santos, CTO

---

From: <[email-masked]>
Date: Mon, 10 Dec 2007 10:25:25 -0500

SSP consists of what the following statements mean
1. I sign all mail
2. I sign some mail
3. I sign no mail
4. I sign other domains mail
5. Other domains sign my mail

Number 3 has been declared out of scope.  4 and 5 appear problematic 1
and two are clearly defined and somewhat in agreement when it comes from
a single FROM: address with a single signature. 

In what circumstances is SSP to be used.
When a signature arrives broken and possibly, no signature=broken

What to do with broken signatures?
Receiver side policy determines that.

So that leaves multiple signatures, multiple FROM: and mixed SSP records
from a list posting.
No change, receiver side policy determines what to do.

Scores can be addeed and subtracted for each scenario, but SSP is not so
much a technology but a informational description of sender intent.

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Saturday, December 08, 2007 6:00 PM
To: Michael Thomas
Cc: [email-masked]; [email-masked]
Subject: Re: [ietf-dkim] A perspective on what SSP is attempting

Mike,

Given the existence of thousands of messages in the archive, it won't be
much 
effort for you to point me to a thread of them.  The one thing I will
ask, 
however, is that it not merely be a reference to the issue, but rather a

thread in which the perspective is in fact, considered and incorporated
into 
the design process.

I ask for the pointer because I'm not aware of such consideration taking
place.

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2007 08:10:23 -0800

Dave Crocker wrote:
> Language like "message handling request" is requesting a specific 
> behavior by the receiver.

   I have requested that this new section be removed as well. That
   said, there's a fair amount of Orwell floating around about
   making a request into a command without benefit of royalty.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Dec 2007 08:31:59 -0800

>   making a request into a command without benefit of royalty.

There are two problems with the attempt to dismiss the import of the 
specification's style of directing receive-side behavior:

1. Specification is specification

    When a document has normative language that directs behavior, it directs 
behavior.  While the difference among may, must, and should is intended to be 
significant, we have no empirical basis for knowing exactly what difference 
they have among implementers and operators.  We certainly have no empirical 
basis for knowing the impact of a normative assertion in a specification like 
SSP, because SSP is operates in a semantic realm for which the IETF has no 
precedent.

2. IETF standard-track status carries its own level of force.  When an IETF 
standard-track specification calls for a behavior, its impact depends upon 
basic adoption of the specification.  That is, the mere presence of approval 
lends weight to every aspect of the document's content.  While one or another 
working group participant might impart more or less casualness to the 
language, we need to consider what average readers will see, in the context of 
basic standardization.  We need to particularly consider this for normative 
language that pertains to basic mechanisms within SSP.  For example, if the 
reader imparts any credibility to the handling directives at all, they are 
pretty much forced to treat the MAY as, at least, a SHOULD.

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Mon, 10 Dec 2007 12:10:47 -0500

[email-masked] wrote:
> Number 3 has been declared out of scope.  

That has always been a very ambiguous declaration and I believe many 
take the literal meaning incorrectly unfortunately, and began to ram it 
down other people's throats.

The fact is, SSP-01 specifically highlights the potential for it.

      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.

Specifically, you can have a strict SSP policy and no DKIM key or NULL 
key, and this is effectively a NO MAIL EXPECTED situation.  Both Eric 
and Jim clearly pointed that out as a reason to not require a specific 
tag saying "No Mail" as the original SSP-00 has.  The end result is the 
same using a bad key, null key with a strict policy.

So in other words, a "no mail" concept is quite possible if a company 
domain owner chooses to lock out any usage of its domain property for 
unauthorized, erroneous external email usage.  Companies should not be 
restricted from implementing this policy.

 > 4 and 5 appear problematic 1

This has always been viewed as contractual issues between two parties: 
the domain owner and any mail handler for it.

Its the same like many systems today that have "IP Allow Relay Tables" 
or require some authentication concept for Smart Hosting.  Otherwise, 
you can have harms that an undoubtedly Open Relay can give you today.

Same idea with the 3rd party signers (3PS) issue.  So either its open 
ended (Unmanaged) or its restricted (Managed) 3PS.

The problem has been how it is implemented.  How do you expose the 
managed 3PS?

Conceptually, you need some "list" concept. There has been proposals 
(Doug's proposals, my own DSAP) who provided various forms of that 
"List" concept.

SSP-01 choose not to use that idea and simplified it with the t=s (1st 
party only tag).

         DKIM=strict, t=s      ; 1st party only

> Receiver side policy determines that.

The toughest part is dealing with mail integrity issues, but I think it 
is generally viewed that this is mostly a problem when the domain is 
being used outside the domain owner's submission source.  i.e., a 
mailing list or some ESP web mail service or roaming users.

In my view, this is all natural and part of the domain owner's policy 
making decision in how its domain is going to be used internally and 
externally.

In addition, it should also be a natural part for an DKIM/SSP ESP 
implementator to leverage this information when a user tries to use a 
domain that is exclusive in its operations.

Of course, if the domain owner expectation is such that its domain can 
be used externally, then it really doesn't make any sense for them to 
use strong policies.  They are really not a candidate for DKIM/SSP 
because with a relaxed policy, as with all thing relaxed, they can 
exploited and it just make things very complicated for all parties.

So you're right, local policy dictates, but we risk the problem of "Cry 
Wolf" where the incoming mail is so filled with broken messages that 
there is high risk of apathy to occur where more and more verifiers will 
simply begin to stop processing DKIM mail altogether.

In other words, it will be sad when verifiers begin to turn off DKIM 
verifiers for some domains simply because it is always broken.

In the end, it is still the domain's decision on how he plans to use 
DKIM and SSP.  They can't just simply turn it on and hope for the best. 
  It could make things worst for them.  And the implementation, 
including the ESP and Mailing List system, they should leverage SSP as a 
way to help protect the domain owner for unauthorized usage in the first 
place.

Remember, the ESP also needs to take into account the down link 
receivers may be completely ignorant of DKIM/SSP. In fact, that will 
very true for a very long time, hopefully short, but we can't assume all 
receivers will be DKIM/SSP verifier ready.

This idea was also touched upon in past discussions and reflected in the 
DSAP proposal where a high-value domain, such like a BANK, when it 
getting new customer accounts and has a "e-Banking" framework, that it 
is to its benefit it makes sure the  new customers are DKIM/SSP receiver 
ready. If they, they can either create their own intranet email domain, 
or they can enlist a DKIM/SSP ready ESP that will provide this service 
and give the new customer one of these Bank Certified ESP addresses.

These engineering concept is all part of the total policy and operations 
picture to help closed the loopholes in the DKIM/SSP world.

> No change, receiver side policy determines what to do.

Same thing, this has been worked out too. SSP policies will help here. 
The issue is mostly with 3rd parties or resigning.

As my proposal suggest and other current implementation already do, when 
it comes to a 3rd party, like a mailing list server, it MAY help to 
strip all signatures and add your own - but that should depend again on 
the intentions of the domain owner.  My proposal says that should only 
be allowed if the domain's policy is relaxed.

> Scores can be addeed and subtracted for each scenario, but
 > SSP is not so much a technology but a informational description
 > of sender intent.

+1

-- 
Sincerely

Hector Santos, CTO

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2007 09:22:20 -0800

Dave Crocker wrote:
>    When a document has normative language that directs behavior, it 
> directs behavior.  While the difference among may, must, and should is 
> intended to be significant, we have no empirical basis for knowing 
> exactly what difference they have among implementers and operators.  We 
> certainly have no empirical basis for knowing the impact of a normative 
> assertion in a specification like SSP, because SSP is operates in a 
> semantic realm for which the IETF has no precedent.
> 
> 2. IETF standard-track status carries its own level of force.  When an 
> IETF standard-track specification calls for a behavior, its impact 
> depends upon basic adoption of the specification.  That is, the mere 
> presence of approval lends weight to every aspect of the document's 
> content.  While one or another working group participant might impart 
> more or less casualness to the language, we need to consider what 
> average readers will see, in the context of basic standardization.  We 
> need to particularly consider this for normative language that pertains 
> to basic mechanisms within SSP.  For example, if the reader imparts any 
> credibility to the handling directives at all, they are pretty much 
> forced to treat the MAY as, at least, a SHOULD.

   My position is that these new dispositions directives should be
   removed, and that the discussion of sender desire should be moved
   to non-normative discussion in the practices (eg, "strict"). I'd
   even be happy with removing them altogether though Scott's experience
   with SPF is well taken.

	Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Dec 2007 09:24:31 -0800

...
> from a Criminal who pretends to be a bank. That is SSP's dirty

I think this goes to a core issue point of discrimination that should be used 
for considering SSP features:  The difference between near-term, essentially 
tactical, concerns, versus concerns that are strategic.

A standard is a very expensive thing.  Expensive to develop, expensive to 
deploy and typically expensive to use when it pertains to operations issue and 
especially to policy issues.

Hence, a standard should pertain to core, strategic issues, especially when 
they are in the security and operations realm.

Fraudulent From domains are a problem, and they certainly occur in massive 
numbers, but if bad actors can trivially use alternatives that are not equally 
protected, fixing only the fraudulent From domain issue is of no long-term 
benefit.

As such, anything that SSP attempts needs to be evaluated in terms of 
long-term benefits and the likelihood that there is a simple work-around 
available to bad actors.

My own preference is to look for mechanisms that would be good to have, even 
if spam and phishing were not serious problems, and then use their presence 
merely as motivators for taking immediate action.

We have extensive, real world precedent for signing messages.

I believe we do not have any real-world precedent for telling recipients what 
to do with mail that is not signed. And we certainly have not done a threats 
and work-arounds analysis for SSP.

For each proposed SSP feature, there needs to be a statement describing the 
thread, the way that the feature will mitigate it and some discussion of 
possible work-arounds and the ease with which they can be used.

d/
-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 10 Dec 2007 12:37:02 -0500

On Monday 10 December 2007 12:24, Dave Crocker wrote:
> I think this goes to a core issue point of discrimination that should be
> used for considering SSP features:  The difference between near-term,
> essentially tactical, concerns, versus concerns that are strategic.
>
> deploy and typically expensive to use when it pertains to operations issue
> and especially to policy issues.
>
> numbers, but if bad actors can trivially use alternatives that are not
> equally protected, fixing only the fraudulent From domain issue is of no
> long-term benefit.
>
> My own preference is to look for mechanisms that would be good to have,
> even if spam and phishing were not serious problems, and then use their
> presence merely as motivators for taking immediate action.
>
> I believe we do not have any real-world precedent for telling recipients
> what to do with mail that is not signed. And we certainly have not done a
> threats and work-arounds analysis for SSP.
>

-1.  Been there.  Done that.  And no, I'm not going to look it up for you.

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Dec 2007 17:37:49 +0000

Dave,

Just looking for a bit more on one of the points you raised.

I also changed the subject since this is specific to one of
the new issues you raised. [1]

Dave Crocker wrote:
> And we certainly have not done
> a threats and work-arounds analysis for SSP.
> 
> For each proposed SSP feature, there needs to be a statement describing
> the thread, the way that the feature will mitigate it and some
> discussion of possible work-arounds and the ease with which they can be
> used.

RFC 4868 [2] does contain some analysis of SSP from a year or
so ago. Can you describe some additional threats that aren't
covered there that we ought be considering? Or are there parts
of the analysis that need revisiting?

S.

[1] https://rt.psg.com/Ticket/Display.html?id=1527
[2] http://tools.ietf.org/html/rfc4686
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Dec 2007 09:42:46 -0800

Graham Murray wrote:
> key. 

The challenge is the phrase "in the bank's name".

1. SSP does nothing to mitigate against use of the Bank's actual "name" 
(brand) anywhere in the message, including the display string of the From 
field, the Subject line or the body.

2. SSP does nothing to mitigate against use of cousin domain's which are 
likely to confuse some significant percent of recipients.

As a consequence, SSP needs to distinguish between attacks on the bank's 
domain name, versus attacks on the bank's brand and it needs to explain how 
SSP mitigates each.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Dec 2007 09:47:45 -0800

> of the analysis that need revisiting?

My review of what is covered in the earlier threats analysis, with regard to 
SSP, is extremely minimal.

Are you saying that you think it is sufficient to provide a technical basis 
for what is in the current specification?

Since you are the designated expert from the Security area, and since you make 
technical contributions to the working group, your assessment is significant.

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Mon, 10 Dec 2007 13:05:53 -0500

Dave Crocker wrote:

> Fraudulent From domains are a problem, and they certainly occur in 
> massive numbers, but if bad actors can trivially use alternatives that 
> are not equally protected, fixing only the fraudulent From domain issue 
> is of no long-term benefit.

Yes and No.

Part of investing in solution comes with an expecting there will be high 
payoff. Thats a given.

In my engineering view, there is a high payoff in eliminating one of the 
most obvious frauds there is that today we have no real reliable 
protection against.

More importantly, when done as a group, you begin to do something that 
was never done before - force the bad guy to change or adapt.  Help 
shift the burden and cost to the bad guy.  Do nothing?  Like today, the 
bad guy has no incentive to adapt.

So if adapting to the other "look-alike" domains, then this will narrow 
the focus of developing augmented solutions that begin to require 
learning, heuristics and artificial intelligence methods.

But in the mean time, we closed one of the biggest loopholes we have 
today.  We force the bad guys to change - a shift in the cost burden.

> long-term benefits and the likelihood that there is a simple work-around 

That has been done Dave.  Unfortunately, you have your own filtering 
process.

> And we certainly have not done a threats and work-arounds 
 > analysis for SSP.

This is so not true David. What will it take to prove it was already 
done?  What are you looking for?

> discussion of possible work-arounds and the ease with which they can be 

The analysis had already been done. There were a few proposals centered 
around it and the RFC 5016 Requirements document and SSP-01 draft are 
reflections of that 2+ year analysis.

That said, I do agree with you there are troubling aspects of it and 
they were predicted to occur by a few people in the group.

I always felt that sound engineering will engineering prevail. To my 
surprise, I wonder why it took you so long to bring up a few of these 
critical points that were clearly highlighted many times here. They are 
the reasons why had did other I-D proposals written.

Unfortunately, David, with all due respect, you seem to have your own 
process of dissemination information.  I can suggest that you begin 
reading input from all interested parties and not just a selected few 
you deem worthy of your attention.  This is not an attack on your 
person, I have a tremendous amount of respect for you, but it is an 
observation of whats going on here.

-- 
Sincerely

Hector Santos, CTO

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Dec 2007 18:10:45 +0000

Dave Crocker wrote:
> My review of what is covered in the earlier threats analysis, with
> regard to SSP, is extremely minimal.

I'm confused by that sentence. It could mean your reading of 4868 was
minimal, or that you consider the analysis in 4868 minimal.

> Are you saying that you think it is sufficient to provide a technical
> basis for what is in the current specification?

No. I was asking for an example from you of what is missing or
wrong in 4868. I assume you have something in mind, since you raised
the specific issue.

> Since you are the designated expert from the Security area, and since
> you make technical contributions to the working group, your assessment
> is significant.

Thanks. Though I'm not sure I'm a designated expert at anything:-)

I've not done the comparison as it happens, but I did ask Jim to do
that - in his slides from last week he indicated that he plans to
compare the SSP I-D against both 4868 and 5016 and report back. I
think that'll be a useful exercise, that might be a starting point for
more work or may be sufficient that the WG are happy to close this
issue.

Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Dec 2007 10:20:03 -0800

> minimal, or that you consider the analysis in 4868 minimal.

The text on SSP threats is minimal.

> wrong in 4868. I assume you have something in mind, since you raised

I understood that you seek to throw the issue back onto me.  I think that a 
threats review should be performed by folks with a background in security, 
such as yourself.

> Thanks. Though I'm not sure I'm a designated expert at anything:-)

Can't think of how to say this differently, so fwiw I'll simply note that it 
is means only what it says:  You think that if you did not have a history in 
the security area you would still have been named co-chair?

> more work or may be sufficient that the WG are happy to close this

ack. tnx.

d/
-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Dec 2007 18:29:45 +0000

Dave Crocker wrote:
> I understood that you seek to throw the issue back onto me.  

Well you did raise the issue, so its fair to ask.

> I think
> that a threats review should be performed by folks with a background in
> security, such as yourself.

I take it from that that 1527 is therefore not related to a
specific perceived threat, but is rather a generic request
for additional threat analysis. I'm ok with that.

Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Dec 2007 10:37:59 -0800

> Well you did raise the issue, so its fair to ask.

yup.

> for additional threat analysis. I'm ok with that.

To expand on this:  Over the flurry of exchanges in the last week or so -- 
actually going much farther back, but this past week is enough for this point 
-- a number of different participants have asked about the perceived threats 
that provide a motivation for one or another SSP feature.  None or few of 
these are discussed in the existing threats analysis RFC.

All of which suggests that there is a formal exercise needed.  As we saw with 
the original exercise, these efforts can be pushed to extremes seeking 
mathematical precision.  Like everyone else in the group, I think that that is 
not productive.  However we do need at least the basics that, for example, 
distinguish deep, strategic threats versus distracting tactical ones, in order 
to give some ranking to the issues that an SSP must solve, versus issues that 
it can provide, at best, only superficial relief.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Mon, 10 Dec 2007 15:19:04 -0500

Dave Crocker wrote:
> To expand on this:  Over the flurry of exchanges in the last week or so 
> -- actually going much farther back, but this past week is enough for 
> this point -- a number of different participants have asked about the 
> perceived threats that provide a motivation for one or another SSP 
> feature.  None or few of these are discussed in the existing threats 
> analysis RFC.

David, just for the record, it was you who did not want any SSP 
considerations done in order to to facilitate the completion of the TA:

   [ietf-dkim] Expediting the threat analysis for -core
   http://mipassoc.org/pipermail/ietf-dkim/2005q4/001470.html

But all the formal exercise was well on its way of being done, the 
engineering, insight were all debated, deep threat analysis and boundary 
conditions were presented, analyzed, discussed, expanded upon, etc, etc.

But you preferred it to be out of scope for the TA and thats what you got.

The only reason there is a minimal official reference now in the final 
TA RFC was because there were certain clear threats to DKIM-BASE which 
could not be addressed without a reference to a POLICY concept and these 
were the only threats the key cogs, including yourself wanted to have in 
the TA.

Why do you did I wrote the DSAP I-D?   To highlight those security 
threats with DKIM-BASE the cogs did not want to address or deemed 
irrelevant or not deemed possible or had no perceived threat.

 > All of which suggests that there is a formal exercise needed.

With all the work has been done, it should be quite easy to produce it.

-- 
Sincerely

Hector Santos, CTO

---

From: "J D Falk" <[email-masked]>
Date: Wed, 12 Dec 2007 20:53:28 -0500

>    removed, and that the discussion of sender desire should be moved
to
>    non-normative discussion in the practices (eg, "strict").

That seems like a potential compromise, but I'd still rather see sender
desires left to best practices documents and blogs instead of technical
standards.