Collection of use cases for SSP requirements

Charles Lindsey wrote:
> Well at least it is a start to force the phishers into
using look-alikes.

As soon as banks start signing their messages and there are
credible whitelists 
for their domain names, doesn't this end the ability for
phishers to use those 
domain names in the rfc2822.From field?

Therefore, how does SSP have any effect?

That is, if the message is signed and the whitelist says the
signer is a Good 
Actor, the the message is handled with a favorable eye.  If
the message is not 
signed, it is handled with a suspicious eye.

Exactly where does SSP fit into the protection scheme?

What use case does it cover?

Exactly which SSP flag/mechanisms is it that provide this
additional benefit?


>> Many of them use their own domains, for which they
could trivially
>> publish SSP data.
> 
> Which is where we need sites on which
"reputations" can be queried. 

Exactly.  In which case, what is the need for SSP?



And, since I happen to think that SSP *can* provide some
utility, here's the 
case that makes sense to me:

For domain names that are in the whitelist, an SSP flag that
says "I sign 
everything" gives me the ability to handle unsigned
messages using that domain 
name in the rfc2822.From (or rfc2822.sender?) field with
*extreme* prejudice.

This seems useful to me.

Not earth-shakingly great, but at least useful.

d/
-- 

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

On Nov 9, 2006, at 7:40 AM, Dave Crocker wrote:
> Charles Lindsey wrote:
>>
>> Well at least it is a start to force the phishers
into using look- 
>> alikes.
>
> As soon as banks start signing their messages and there
are  
> credible whitelists for their domain names, doesn't
this end the  
> ability for phishers to use those domain names in the
rfc2822.From  
> field?

Unfortunately, a DKIM signing-domain white-list based upon
trust or  
reputation is prone to abuse.  Someone with access to a
domain can  
send themselves messages that can be replayed from anywhere.
 For the  
MTA, without some mechanism to identify when it is safe to
apply a  
white-list, DKIM would not be validated to conserve
resources.  The  
MUA may wish to validate DKIM signatures to confirm the
recognized  
identity before annotation is applied.


> Therefore, how does SSP have any effect?
>
> That is, if the message is signed and the whitelist
says the signer  
> is a Good Actor, the the message is handled with a
favorable eye.   
> If the message is not signed, it is handled with a
suspicious eye.
>
> Exactly where does SSP fit into the protection scheme?

When attempting to defeat spoofing, message annotation is
required.   
The annotation should be based upon:

A) Matching with trusted email-address assured valid via
signature  
semantics or policy assertions.

B) Matching email-address trusted domain where policy
asserts the  
specific email-address as trustworthy.

The annotation scheme defined in DOSP provides a formidable
defense  
against phishing or other types of spoofing.

> What use case does it cover?

White-listing protection:

When a receiver wishes to white-list big-isp.com because a
few of  
their users run afoul of their block-lists.  Once it becomes
 
understood by the bad actors able to gain access to
big-isp.com, then  
any white-listing hoping to bypass block-lists will prove  
disastrous.  DOSP offers a means to associate the SMTP
client with  
the signing domain.  This association allows white-listing
to be  
safely applied based upon either trust or reputation.

DSN assurance:

The same association strategy can assure the 2821.MailFrom
address  
without the problems related to address-path registration.

Autonomous designation of providers:

The same association strategy eliminates an exchange private
keys,  
delegation of DNS zones, or publishing CNAMEs at specific
selector  
leafs.  This association strategy also allows autonomous
management  
of a customer's relationship with their providers.  (Good
for the  
customer and good for the provider as they will receive
abuse feedback.)


> Exactly which SSP flag/mechanisms is it that provide
this  
> additional benefit?

<hash:signing-domain>.<email-address-domain> RR 
"a=signing-domain f=A

>>> Many of them use their own domains, for which
they could  
>>> trivially publish SSP data.
>>
>> Which is where we need sites on which
"reputations" can be queried.
>
> Exactly.  In which case, what is the need for SSP?

When there is a desire to secure private keys and still
having  
messages receive an authorization signed by the providers
domain.

> And, since I happen to think that SSP *can* provide
some utility,  
> here's the case that makes sense to me:
>
> For domain names that are in the whitelist, an SSP flag
that says  
> "I sign everything" gives me the ability to
handle unsigned  
> messages using that domain name in the rfc2822.From (or
 
> rfc2822.sender?) field with *extreme* prejudice.

So what?  In reality this blocking effort affords little
protection.   
When the domain also wishes to use mailing lists, extreme
prejudice  
will significantly reduce the integrity of their email. 
Different  
policies within sub-domains only increases the likely
success of  
phishing attempts.

> This seems useful to me.
>
> Not earth-shakingly great, but at least useful.

Not really.  It establishes bad practices and will create
problems  
for virtually no benefit.  DKIM can not be applied with
respect to  
white-listing except perhaps in a select few cases such as
bulk  
senders.  Attempting qualify email-address originating
domains only  
when matching with the signing domain creates additional
problems.   
These problems can be resolved without requiring any
additional DNS  
transaction as described in DOSP.

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

On Thu, 09 Nov 2006 15:40:37 -0000, Dave Crocker <dhcdcrocker.net> wrote:


> As soon as banks start signing their messages and there
are credible  
> whitelists for their domain names, doesn't this end the
ability for  
> phishers to use those domain names in the rfc2822.From
field?

I fail to see how "credible whilelists" are going
to work. You cannot  
expect all the millions of honest internet users to get into
such  
whitelists. Rather, it seems that what is suggested is that
there will  
exists whitelists of "respectable banks".

But how do you tell, automatically, that a message is from a
"bank", and  
therefore ought to be ignored if it is not whitelisted? Will
messages from  
banks routinely carry text or headers which say "this
message is from a  
bank, and is to be ignored if it is not whitelisted".
Naturally, phishers  
will not include such texts/headers (or they will include
them in a subtly  
altered form).

But you still have the problem of educating users to expect
such  
texts/headers, and educating them to do that is just as hard
as educating  
them to recognise present-day phishes (I expect most people
do, but enough  
people don't for the phishers to make a decent living, it
seems).

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

Charles Lindsey wrote:

> On Thu, 09 Nov 2006 15:40:37 -0000, Dave Crocker
<dhcdcrocker.net> 
> wrote:
>
>
>> As soon as banks start signing their messages and
there are credible  
>> whitelists for their domain names, doesn't this end
the ability for  
>> phishers to use those domain names in the
rfc2822.From field?
>
>
> I fail to see how "credible whilelists" are
going to work. You cannot  
> expect all the millions of honest internet users to get
into such  
> whitelists. Rather, it seems that what is suggested is
that there 
> will  exists whitelists of "respectable
banks".
>
> But how do you tell, automatically, that a message is
from a "bank", 
> and  therefore ought to be ignored if it is not
whitelisted? Will 
> messages from  banks routinely carry text or headers
which say "this 
> message is from a  bank, and is to be ignored if it is
not 
> whitelisted". Naturally, phishers  will not
include such texts/headers 
> (or they will include them in a subtly  altered form).
>
> But you still have the problem of educating users to
expect such  
> texts/headers, and educating them to do that is just as
hard as 
> educating  them to recognise present-day phishes (I
expect most people 
> do, but enough  people don't for the phishers to make a
decent living, 
> it seems).

The problem here is actually twofold: the phished company
side and the
user side. At present, there's absolutely no reason for
companies with 
big names
to limit their own use of lookalike domains. Which of course
they use 
with relish,
so even a diligent end user can't ever be sure. I'd claim
that this 
ambiguity must change
*before* any sort of education campaign can have any
realistic chance of 
working.

But there's no incentive for the companies to reign in their
marketing arms
now. DKIM and especially DKIM+SSP may provide some incentive
to do that
since they get to regain control of their brand names. It's
unclear whether
it's enough incentive, but it's at least plausible
especially given that 
it's a
relatively low investment and that it appeals to their
dislike of brand name
dilution.

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

On Fri, Nov 10, 2006 at 11:33:00AM -0000, Charles Lindsey
wrote:
> But you still have the problem of educating users to
expect such  
> texts/headers, and educating them to do that is just as
hard as educating  
> them to recognise present-day phishes (I expect most
people do, but enough  
> people don't for the phishers to make a decent living,
it seems).

It seems clear to me MUAs need to change.


-- 
:: Jeff Macdonald | Principal Engineer, Messaging
Technologies
:: e-Dialog | jmacdonalde-dialog.com
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

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

Charles Lindsey wrote:
> On Thu, 09 Nov 2006 15:40:37 -0000, Dave Crocker
<dhcdcrocker.net> wrote:
> 
> 
>> As soon as banks start signing their messages and
there are credible 
>> whitelists for their domain names, doesn't this end
the ability for 
>> phishers to use those domain names in the
rfc2822.From field?
> 
> I fail to see how "credible whilelists" are
going to work. You cannot 
> expect all the millions of honest internet users to get
into such 

DKIM is about domain names, not users.  This means
"organizations" and not 
"users".  I do not see why we cannot expect
organizations to get on whitelists.


> whitelists. Rather, it seems that what is suggested is
that there will 
> exists whitelists of "respectable banks".

There will probably be many different whitelists.  Some will
be for specific 
categories of senders, and others will be broader.  Note
that the non-Internet 
world already has lots of whitelists and we have learned how
to deal with them. 
   (For example, Michelin for restaurants.)  Some are better
than others... We 
develop a means of ranking them.


> But how do you tell, automatically, that a message is
from a "bank", and 
> therefore ought to be ignored if it is not whitelisted?


Please review John Levine's note of today.


> But you still have the problem of educating users to
expect such 
> texts/headers, and educating them to do that is just as
hard as 
> educating them to recognise present-day phishes 

Teaching users to recognize a symbol on the screen that
means "safe" is not as 
difficult as teaching them to recognize the various forms of
deception used by 
phishers.  (Again, see John Levine's note.)

d/
-- 

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

Charles Lindsey wrote:
> On Thu, 09 Nov 2006 15:40:37 -0000, Dave Crocker
<dhcdcrocker.net> wrote:
> 
> 
>> As soon as banks start signing their messages and
there are credible 
>> whitelists for their domain names, doesn't this end
the ability for 
>> phishers to use those domain names in the
rfc2822.From field?
> 
> I fail to see how "credible whilelists" are
going to work. You cannot 
> expect all the millions of honest internet users to get
into such 

DKIM is about domain names, not users.  This means
"organizations" and not 
"users".  I do not see why we cannot expect
organizations to get on whitelists.


> whitelists. Rather, it seems that what is suggested is
that there will 
> exists whitelists of "respectable banks".

There will probably be many different whitelists.  Some will
be for specific 
categories of senders, and others will be broader.  Note
that the non-Internet 
world already has lots of whitelists and we have learned how
to deal with them. 
   (For example, Michelin for restaurants.)  Some are better
than others... We 
develop a means of ranking them.


> But how do you tell, automatically, that a message is
from a "bank", and 
> therefore ought to be ignored if it is not whitelisted?


Please review John Levine's note of today.


> But you still have the problem of educating users to
expect such 
> texts/headers, and educating them to do that is just as
hard as 
> educating them to recognise present-day phishes 

Teaching users to recognize a symbol on the screen that
means "safe" is not as 
difficult as teaching them to recognize the various forms of
deception used by 
phishers.  (Again, see John Levine's note.)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

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

On 11/10/06 8:15 AM, "Michael Thomas" <mikemtcc.com> scribbled:

> But there's no incentive for the companies to reign in
their marketing arms
> now. DKIM and especially DKIM+SSP may provide some
incentive to do that
> since they get to regain control of their brand names.
It's unclear whether
> it's enough incentive, but it's at least plausible
especially given that
> it's a
> relatively low investment and that it appeals to their
dislike of brand name
> dilution.

I think I can say with some authority that certainly heavily
phished
companys do understand and have executive buy in to prevent
marketing use of
look-a-like domains.  There may be some exceptions, but I
expect as this
filters down that those will become roughly 0 (at least for
us)

The problem is bad enough that, in spite of the fact that I
think it's not
feasible, I have heard the statement that it's getting to
the point that we
may eventually consider valueless to our customers due to
this.  Virtually
no one thinks that using postal mail is a more economical
means of
communication.  

-Jot
-- 
Jot Powers             <jpowerspaypal.com>
Phone: 602-474-9404    Cell: 480-221-1157
Skype: jotebay

"Trimming quoted text in email leaves more room for you
in heaven."
   -Ricardo Signes in irc://irc.perl.org/#perl

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

On Fri, 10 Nov 2006 15:49:27 -0000, Dave Crocker <dhcdcrocker.net> wrote:

> Charles Lindsey wrote:
>> On Thu, 09 Nov 2006 15:40:37 -0000, Dave Crocker
<dhcdcrocker.net>  
>> wrote:
>>
>>> As soon as banks start signing their messages
and there are credible  
>>> whitelists for their domain names, doesn't this
end the ability for  
>>> phishers to use those domain names in the
rfc2822.From field?
>>  I fail to see how "credible whilelists"
are going to work. You cannot  
>> expect all the millions of honest internet users to
get into such
>
> DKIM is about domain names, not users.  This means
"organizations" and  
> not "users".  I do not see why we cannot
expect organizations to get on  
> whitelists.

Sure. s/millions of honest internet users/tens of thousands
of domains  
used by millions of honest internet users/.
>
>
>> whitelists. Rather, it seems that what is suggested
is that there will  
>> exists whitelists of "respectable banks".
>
> There will probably be many different whitelists.

Which still leaves the question of which whitelist(s) you
apply to each  
particular mail. Granted that final delivery agents, who are
likely to do  
the verifying, can make a slightly better guess at this than
the average  
end user, it is still a near-impossible task.

>> But how do you tell, automatically, that a message
is from a "bank",  
>> and therefore ought to be ignored if it is not
whitelisted?
>
> Please review John Levine's note of today.

Sorry, I didn't identify any note from John relating to
whitelists.

> Teaching users to recognize a symbol on the screen that
means "safe" is  
> not as difficult as teaching them to recognize the
various forms of  
> deception used by phishers.  (Again, see John Levine's
note.)

The first thing you need to do is to ensure that the symbol
appears with  
high reliability on the message. There is nothing like too
many false  
negatives to put people off the whole idea.

And the second thing is to teach the users a simple rule to
recognize  
which messages might be expected to bear that symbol.
"You tell me that I  
should ignore messages without that symbol, but the messages
I get from  
Aunty Mary never have that symbol on them".

The third thing is to prevent the bad guys from causing that
symbol to  
appear (which depends on the exact nature of the protocol
which puts it  
there, which we have not yet examined yet).

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

>>> But how do you tell, automatically, that a
message is from a "bank",  
>>> and therefore ought to be ignored if it is not
whitelisted?

Your computer doesn't tell automatically, you tell by
looking at it.
This is a task that humans do much better than computers do.
 As I
said:

 On the other hand, if we encourage whitelists of real
banks, the
 user's model is like this:

 1) Incoming message appears to be from a bank.

 2) Does the MUA show the golden dollar sign that means it's
from a
 real bank?

 3) Done.

As I hope is obvious here, I'm assuming that existing
organizations
that know who the real banks are, such as the FSA in the UK
and the
FDIC in the US will certify their members and somehow
associate a logo
with the certification.  That's technically trivial.

R's,
John

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