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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 16 Nov 2006 21:20:14 -0800

I think we need to organize the use cases differently. We need to do a differential use case analysis.

We have two essential classes of message: Genuine and Fake.

FOR DKIM BASE:
We have three possible outcomes: Definitely Genuine, Definitely Fake and Undetermined

[We can if people think there is value further break down Undetermined according to probability but bear with me]

A proposed processing algorithm is BROKEN if it it generates the outcome Definitely Genuine for a Fake message or Definitely Fake for a Genuine Message.

So we have a set of use cases that describe 'good behavior' and a set of use cases that describe 'bad behavior and we have evaluated DKIM base against them. As it happens due to the vagaries of the Internet there is (almost) always the possibility that a failed signature verification is due to network operator error or mangling by an intermediary so the only two outcomes from the DKIM system are Definitely Authentic and Undetermined.

To look at policy we have to look at a wider scope. Policy is not an input to DKIM it is an input to the system which uses DKIM, a system that will inevitably use some form of authorization input, in our terminology 'reputation'.

The outcome from the Authentication backed reputation module has the following values:
	Definite Accept, Definite Reject, Further Processing

In this case we do want to distinguish between different further processing outcomes. In particular we want to use guidance from the domain name owner, i.e. policy to guide the further processing that takes place. A message that is NOT compliant with the guidance from the domain name owner SHOULD be treated less favorably that a message that is.

The outcome from the Authentication backed reputation module thus has the following values:
	Definite Accept, Definite Reject, Compliant, Not Complaint

The objective of the design of the policy language is therefore to allow the creation of the most accurate processing algorithm, that is the one which assigns the most desirable outcome in the highest proportion of cases without assigning an undesirable outcome.

That is a processing algorithm that assigns definite accept to a fake message is broken and must be rejected. 

We need to order the use cases according to the acceptable and the desirable outcomes. Then evaluate the processing algorithms according to their ability to correctly assign outcomes to the use cases.

This is the differential use case analysis.

I am constructing a matrix with the outcomes for my processing algorithm and the best algorithms I can construct for the Fenton proposal. Its on paper at the moment and I can't spread it out here on the plane. So should have it on Monday or so.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Monday, November 13, 2006 5:01 PM
> To: Steve Atkins
> Cc: ietf-dkim WG
> Subject: Re: [ietf-dkim] Collection of use cases for SSP requirements
> 
> 
> 
> Steve Atkins wrote:
> 
> > Well, I believe the list is wrong, however it isn't my 
> list, it's the 
> > list in dkim-ssp-requirements-02.
> > 
> >   4.1.  Problem Scenario 1: All Mail Signed with DKIM
> >   4.2.  Problem Scenario 2: Illegitimate Domain Name Use
> >   4.3.  Problem Scenario 3: Domain Sends No Mail
> 
> Good. You have read the draft.
> 
> In that case I'm sure you'll agree that we can best progress 
> if we deal with what's in there and not with some re-wording 
> that (with this list on this topic), amounts to starting over.
> 
> My problem is not with your or the draft's list. It is with 
> the endless wandering about in the wilderness that this 
> thread represents. (If it was a bit unfair to jump on your 
> message, then I'm sorry but I've now seen this entire 
> discussion fizzle out enough times that I'm not very tolerant of it.)
> 
> I look forward to you raising an issue against the -02 draft 
> saying how you'd like to fix section 4. Please do that in a 
> new thread.
> 
> Stephen.
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 

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

---

From: John Levine <[email-masked]>
Date: 17 Nov 2006 05:45:27 -0000

>We have three possible outcomes: Definitely Genuine, Definitely Fake and Undetermined

How can dkim-base tell that something is definitely fake?

R's,
John

---

From: [email-masked] (Wietse Venema)
Date: Fri, 17 Nov 2006 07:27:43 -0500 (EST)

Hallam-Baker, Phillip:
> [We can if people think there is value further break down
> Undetermined according to probability but bear with me]

My understanding is that DKIM-base can produce only two results:
signature verification succeeds or signature verification fails.
I may be mistaken, but it seems to me that expanding these two
results into >2 involves information outside DKIM-base.

	Wietse

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Nov 2006 14:01:08 +0100

Hallam-Baker, Phillip wrote:
 
> I am constructing a matrix with the outcomes for my processing algorithm
> and the best algorithms I can construct for the Fenton proposal.

Good, use Hector's matrix for comparison.  Hector had those odd "first
party doesn't permit third party signatures" cells, if you drop this
the decision table should be clearer.  Third party signatures are the
business of the third party, the sender can't get a veto, that would
force third parties into an expensive "check before sign" situation.

Wrt the requirements we might need some "MUST be clear what the h***
an SSP is talking about" (from, sender, pra, etc. - probably I won't
believe a single word if it's a naive "from" approach, or if it uses
the word "sender" without defining what that might be, spiced with 
literal RFC 822 quotes).

It's not the same situation as in BASE, where a valid signature tells
us what it is about.  As you have shown in earlier articles the SSP
is mostly interesting for mails without a valid signature.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Nov 2006 14:29:59 +0100

> signature verification succeeds or signature verification fails.

Where fails includes cases like no signature at all, yes.  But we
have first party (0 or 1) signatures, and third party signatures
(0 or more), and valid signatures from unknown strangers are not
relevant for receivers.

> expanding these two results into >2 involves information outside
> DKIM-base.

Yes, we're in an SSP thread, that's info outside BASE.  For some
mail claiming to be "from" paypal there are more than two cases:

It can have a valid Paypal signature (assuming you know paypal)
It can have a broken or no Paypal signature
It can have another signature from somebody you know
It can have another signature from somebody you don't know
Any valid signature you don't know can be from a bad actor

It can be resent / redistributed / digested with odd side-effects
for naive decision tables, and some of these cases are perfectly
legit mail uses.  Most of these cases will be spam and fraud like
almost all mail, but the decision to treat it as spam can't be
based on the signature decision table without hurting the legit
mail uses.

Whatever paypal claims in their SSP, they can't tell legit users
that resend etc. isn't allowed for mail "from paypal".  An SSP
declaring major parts of RFC 2822 as obsolete likely won't fly.
While I'm no fan of PRA for lots of reasons, it's IMO the best
we can do after we've decided to ignore the Return-Path (as it
is the case for DKIM, because it's bound to 2822, not to 2821).

Frank

---

From: Steve Atkins <[email-masked]>
Date: Fri, 17 Nov 2006 06:20:31 -0800

> results into >2 involves information outside DKIM-base.

While I strongly agree with this interpretation of dkim-base,
some have argued that there are three states
in dkim-base: signature verification suceeds, signature
verification fails and "no signature".

Others have tried to tie other attributes of the
mail into DKIM (is the signing domain the same as the
 From address, the Sender address, the envelope from,
the return path, the .signature etc), in an attempt to
multiply the number of signature types beyond the
one that's actually defined.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Fri, 17 Nov 2006 06:47:32 -0800

> results into >2 involves information outside DKIM-base.
Part of the problem here, I think, is that it depends on who the result is
for. From a forensics standpoint, broken signatures are clearly a lot
different than no signature. For your average automaton, however, they 
should
*never* be taken as different if the difference leads to preferential 
treatment
of broken/none (or visa versa).

The other part of this is that it's rather misleading to say that the 
only outcome
of a positive signature verification is that it verified. Once it 
verifies, there's
a wealth of information both in the signature header and the rest of the 
message
that is now known to be tied to the signing entity. How that information 
is used
is outside of the scope of the DKIM work, but we shouldn't be giving the
impression that it doesn't exist, or that it is improper to take 
advantage of,
or anything else like that.

       Mike

---

From: [email-masked] (Wietse Venema)
Date: Fri, 17 Nov 2006 09:58:26 -0500 (EST)

> Any valid signature you don't know can be from a bad actor

My understanding is that SSP provides statements by the rfc822.from
domain, about domains that they know, and that sign their mail.

Specifically, SSP does not answer the following questions:

1 - Do I know the signing party. Finding the signing domain listed
    in the rfc822.from's SSP record does not mean that I "know"
    the signing domain: the bad guys can use SSP too. The answer
    requires information outside SSP and outside DKIM-base.

2 - Is the signing party a bad actor. I don't recall the SSP design
    has a feature to say "caution: example.com is a bad actor". Such
    information could be provided by SSP if it were suitably extended.

3 - Is the signing party a good actor. Such statements are meaningless
    unless we already know and trust the rfc822.from domain. The answer
    requires information outside SSP and outside DKIM-base.

SSP allows us to expand DKIM-base's two results into just five:

1 - no valid signature                   (DKIM-base sans SSP)
2 - no valid signature, SSP requires one (DKIM-base plus SSP)
3 - valid signature                      (DKIM-base sans SSP)
4 - valid signature, blessed by SSP      (DKIM-base plus SSP)
5 - valid signature, not blessed by SSP  (DKIM-base plus SSP)

I hope that this bottom-up analysis will help to clarify what
information DKIM-base and SSP actually provide. Corrections are
of course welcome.

	Wietse

---

From: [email-masked] (Wietse Venema)
Date: Fri, 17 Nov 2006 10:18:01 -0500 (EST)

> of broken/none (or visa versa).

This is an excellent point. There is a wealth of additional
information. Once there is confidence that it is valid, it should
not be ignored.

But we have to be careful, or else we end up with a chicken and
egg problem.

My analysis takes the position of the automaton, and looks at what
information is available before we declare the wealth of additional
information valid.

	Wietse

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Nov 2006 21:36:49 +0100

Wietse Venema wrote:
 
> domain

Okay, let's assume that's the case.  You take the 2822-From, assuming
there's exactly one address in it, extract the domain, and get the SSP
 
> 2 - no valid signature, SSP requires one (DKIM-base plus SSP)

How does that work for resent / redistributed / news2mail gatewayed 
etc. cases ?  Maybe my SSP says "my mail is always signed".  And that
still allows me to say "From: me" in jabber or news or elsewhere, and
without DKIM signature (so far only defined for mail).

And somebody getting that message can inject it into SMTP using his
or her "Sender: somebody" + "From: me".  Still without DKIM signature,
or at best the signature of somebody, not me.  That's IMO a perfectly
legal use of 2822-header fields, and any SSP claiming that this is
"wrong" is FUBAR.

> 5 - valid signature, not blessed by SSP  (DKIM-base plus SSP)

That's the case where somebody (e.g. the news2mail gateway) adds its
signature and some corresponding Sender or Resent-From header field.

A policy talking about _only_ the 2822-From is strictly limited to
mail with PRA == 2822-From.  If that's the case, we could also say
that a policy always talks about the PRA, which would be logical to
some degree (determined by RFC 2822, not DKIM base).

Limiting SSP to mails with PRA == 2822-From is hocuspocus, the bad
guys simply add some dummy Resent-Sender (with a SenderID +all PASS
while they're at it), and the limited SSP would be bypassed.

We _could_ ask MUA implementors to flag mails with PRA != 2822-From
as "suspicious", but does that make any sense ?  Header fields like
Sender, Resent-From, and Resent-Sender are in use for decades, can
some obscure RFC suddenly claim that that's "suspicious" ?  
   
Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 17 Nov 2006 21:06:09 -0000

> results into >2 involves information outside DKIM-base.

No, there is a lot more than that.

There is 'signature absent'
          'signature present but invalid'
For failed signatures there is
          'the failure was in the header/the body/both'
For good signatures there is
          'the headers that were signed were the ones expected to be signed'
          'the length of the body was longer than the l-tag said'

Which of these are relevant to automatic decision making, and which only  
for forensics, is a question for imploementors of verifiers. Experience  
may show that all sorts of unexpected scams can be caught by looking for  
obscure cases.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 17 Nov 2006 21:16:15 -0000

> domain, about domains that they know, and that sign their mail.

And if there are two addresses in the From header? And if there is a  
Sender as well (as there must be when there are two or more in the From)?

And then the various signatures on offer may be for domains that intersect  
in all sorts of interesting ways with the domains of the From(s), Sender,  
Resent- versions thereof, the List-* headers, etc. All taken in  
conjunction with which of those various headers were included in the hash.  
And also the order in which they appeared (assuming intermediate sites  
have respected the instruction to preserve the order of the Trace headers).
>     information could be provided by SSP if it were suitably extended.

Reputation information cannot come from SSP. All SSP can tell you is what  
the owner of each domain chooses to tell you. Reputation information will  
come from third parties, so you have to decide which third parties to  
believe.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 17 Nov 2006 13:44:51 -0800

On Nov 17, 2006, at 1:16 PM, Charles Lindsey wrote:

> Reputation information cannot come from SSP. All SSP can tell you  
> is what the owner of each domain chooses to tell you. Reputation  
> information will come from third parties, so you have to decide  
> which third parties to believe.

Reputation, good or bad, can not come from the DKIM signature either.

DKIM only indicates who signed the content of the message, not who  
addressed the envelope and sent the message.  Reputation information  
seldom depends upon the message's content for asserting a bad  
reputation.  Only when the content is perhaps criminal in nature  
could content alone provide enough information for asserting a  
negative reputation.  A good reputation is equally problematic.   
Reporting that example.com has a "good" reputation will likely invite  
spammers to this domain.  Spammers would then send themselves  
messages signed by example.com.  These messages can then be  
immediately replayed from all parts unknown.  Saying anything bad  
about a domain will be problematic, as will saying anything good.

Being able to associate the signing domain with that of the SMTP  
client safely allows white-listing which protects the "good"  
assertion from being abused.  This technique could also be used to  
associate the various email-address fields with that of the signing  
domain as well.  An association technique would allow email-address  
domain owners to freely select their providers.  Domain owners would  
not need to coordinate the exchange of private keys, zone  
delegations, or allowing them to create your private keys and  
referencing their public key using a CNAME record.  The providers  
would also have abuse feedback directed to them.

Security is improved by providing an association scheme. The cost of  
the email service is reduced, and there would be greater consumer  
freedom.  The converse of sharing your domain zone or provide keys  
with these providers does not enhance anyone's freedom.  A message  
signed by a large domain is no better than that signed by a smaller  
domain.  When a smaller domain is known to be good, the smaller  
domain has the advantage.  Clearly allowing signing domain  
designation would be beneficial to the smaller entities.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 17 Nov 2006 17:14:07 -0500

My 2 cents:

The first thing that needs to be work out which is what I find fundamentally 
flawed in DKIM is that idea of separating VALID vs NON-VALID conditions.

The fundamental idea is simple:

   - No Good system is will have NON-VALID conditions!

By GOOD I don't mean reputation.  I mean operations wise - it is the FIRST 
condition that must be met.    Violate this and you must as well throw DKIM 
into the waste basket - "with full force."

All rules or any applied FUZZY logic, including repuation must be based on 
this.

Otherwise, you get into nonsense ideas that a GOOD system MAY infact have 
invalid conditions and you might as well OVERRIDE this with some other 
undefined, non-standard processing.  At that point, we are back to square 
one where there is no consistency nor expectation for consistency.  It 
doesn't matter what DKIM says.  Something else will override it.

In any case, I am not too excited any more with the direction DKIM has taken 
with placing hope on Reputations systems to solve its issues.  Its defeats 
the purpose in my view.

---
HLS

----- Original Message ----- 
From: "Douglas Otis" <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 17, 2006 4:44 PM
Subject: Re: [ietf-dkim] Re: Collection of use cases for SSP requirements

>> Reputation information cannot come from SSP. All SSP can tell you  is 
>> what the owner of each domain chooses to tell you. Reputation 
>> information will come from third parties, so you have to decide  which 
>> third parties to believe.
>
> seldom depends upon the message's content for asserting a bad  reputation. 
> Only when the content is perhaps criminal in nature  could content alone 
> provide enough information for asserting a  negative reputation.  A good 
> reputation is equally problematic.   Reporting that example.com has a 
> "good" reputation will likely invite  spammers to this domain.  Spammers 
> would then send themselves  messages signed by example.com.  These 
> messages can then be  immediately replayed from all parts unknown.  Saying 
> anything bad  about a domain will be problematic, as will saying anything 
> good.
>
> Being able to associate the signing domain with that of the SMTP  client 
> safely allows white-listing which protects the "good"  assertion from 
> being abused.  This technique could also be used to  associate the various 
> email-address fields with that of the signing  domain as well.  An 
> association technique would allow email-address  domain owners to freely 
> select their providers.  Domain owners would  not need to coordinate the 
> exchange of private keys, zone  delegations, or allowing them to create 
> your private keys and  referencing their public key using a CNAME record. 
> The providers  would also have abuse feedback directed to them.
>
> Security is improved by providing an association scheme. The cost of  the 
> email service is reduced, and there would be greater consumer  freedom. 
> The converse of sharing your domain zone or provide keys  with these 
> providers does not enhance anyone's freedom.  A message  signed by a large 
> domain is no better than that signed by a smaller  domain.  When a smaller 
> domain is known to be good, the smaller  domain has the advantage. 
> Clearly allowing signing domain  designation would be beneficial to the 
> smaller entities.
>
> -Doug
>

---

From: Douglas Otis <[email-masked]>
Date: Fri, 17 Nov 2006 19:18:55 -0800

>   - No Good system is will have NON-VALID conditions!

As found with other authorization schemes, bad actors are not  
curtailed when insisting upon this requirement.  A negative  
reputation based upon behaviors logged by DKIM bad acts is difficult  
to defend.  Positive reputation is also prone to be being abused, but  
this is where DKIM can shine.  Positive reputation can be applied at  
the MUA by simply using the recipient's address book, for example.  A  
large bulk sender might also wish to use DKIM to get their messages  
accepted, which are often for the domains of their customers.

Alas, even when there are no NON-VALID conditions allowed, a white- 
list assertion is still prone to be being abused.  A customer of the  
bulk sender might know the bulk sender is commonly white-listed and  
that the bulk sender carefully vets their customer's mailing lists.   
The customer of the bulk sender only needs to send themselves a few  
of their own messages, and then send these to anyone they wish,  
taking advantage of the once good reputation of the bulk-sender.

One solution is for the bulk sender to demand that their customer's  
take the risk of a positive reputation being abused.  This is done by  
the bulk sender controlling their customer's private keys.  The bulk  
sender pretends to be their customer, which is a common ploy used  
today for other reasons.  Any abuse reporting however is sent to the  
wrong entity, and the IP address of the bulk sender remains at risk  
of being block-listed.  There is a better way to solve this problem  
that better protects the bulk sender and does not pass risks onto the  
bulk sender's customers.

Establish an association scheme where messages are accepted on the  
basis of being white-listed _only_ when an association is found  
between the signing-domain and SMTP client.  This technique has  
nothing to do with whether NON-VALID conditions are allowed.  This  
same technique also allows email-addresses to be a associated with  
that of the signing domain using a similar technique.

There is no need to hunt for these associations.  When not found, the  
message is treated as any other message without preferential  
treatment.  When a message can not be delivered, an ability to  
associate the Mail From Address with that of the signing domain  
improves upon DSNs being returned.  Unless white-listed by signing  
domain, without finding a desired association with that of the  
signing domain, there is little reason to even check the validity of  
the signature.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 18 Nov 2006 16:27:56 +0000

(Chair hat decidedly on.)

So this thread started out useful but I've seen nothing that
we can process as a WG for the last N messages. Its nice to
know what you all think, but there's no sign of progress
here that I can see.

If you have a new issue to raise, please do so in a new
thread, saying what change you want to see in the ssp-reqs
document.

If its an old issue, please don't slow us down by raising it
yet again. If you don't know how to tell, ask off list.

Stephen.