Collection of use cases for SSP requirements

Steve Atkins wrote:

>
> On Nov 8, 2006, at 8:10 AM, Scott Kitterman wrote:
>
>> On Wed, 8 Nov 2006 07:55:15 -0800 Steve Atkins
<steveblighty.com>  
>> wrote:
>>
>>>
>>> On Nov 8, 2006, at 4:24 AM, Charles Lindsey
wrote:
>>>
>>>>
>>>> I think some site like a Bank, that is
heavily phished, might go so
>>>> far as to declare
>>>>    "I sign all mail. Please
delete/reject/drop/whatever (perhaps
>>>> even silently)
>>>>     all messages that fail to verify".
>>>>
>>>> That site would have to be pretty confident
that the genuine mail
>>>> it sent out was 100% clean, but it might
well decide that it was a
>>>> lesser risk to have some genuine messages
dropped than to let
>>>> phishes go through.
>>>>
>>>> BTW, are there any plams to have keywords
for some of the various
>>>> policies that might be declared, so that
verifiers (or rather their
>>>> policy modules) could recognize them and
adjust their policy
>>>> accordingly)?
>>>
>>>
>>> I do have to point out that SSP will not affect
phish emails  
>>> noticeably,
>>> after a very short transition period.
>>>
>>> So if a bank were to do this it would mean 1)
phishing mails won't
>>> be affected and 2) legitimate mail from the
bank is likely to be
>>> affected.
>>>
>>> So... what's the _real_ use case, again?
>>
>>
>> Please explain.  If a sender publishes a policy
that says I sign  all 
>> mail
>> and a receiver rejects, deletes, etc. all mail that
isn't signed by  
>> that
>> sender, what is the phisher's transition path to
work around it?
>>
>> I agree that this does not help with look-alike
domains, but for  
>> phishing
>> that uses a sender's domain, I'm noy sure what you
are getting at?
>
>
> You point out the underlying issue nicely.
>
> Phishing doesn't have to use the real domain. There are
*countless*
> ways of phishing that don't require it. Even now, a lot
of phish mails
> don't bother using the real domain, even though there's
no real
> disincentive to do so in most cases. If there were even
a minor
> disincentive then they could move away from that today
with
> minimal inconvenience.

This assumes that social problems have to be solved only in
the
technical realm in order to be useful. I'm sure that John
will snort his
coffee through his nose, but training users to only expect
to hear from
paypal from paypal.com is most likely part of the solution.
SSP can help on
this front, and at least gives some incentive for the
marketdroids to stop
confusing the issue of legitimacy with self-inflicted wounds
of using
look-alike domain names themselves.

Is this a whole solution? Of course not. We already know
that no such
silver bullet exists. Can or should we lessen the degrees of
freedom in
which bad guys can act? Sure seems like a reasonable idea to
me. The
only real question in my mind is whether this particular
piece of technology
is really worth the effort in the short/medium and long run.
I think that
reasonable people can have reasonable differences of opinion
on that.
For the dissenters, so long as there's not active harm
what's the problem?
Don't use it if you think it's useless.

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

Michael Thomas wrote:
>> Phishing doesn't have to use the real domain. There
are *countless* ways of
>> phishing that don't require it. ...
> 
> This assumes that social problems have to be solved
only in the technical
> realm in order to be useful. I'm sure that John will
snort his coffee through
> his nose, but training users to only expect to hear
from paypal from
> paypal.com is most likely part of the solution. 


Unfortunately, I was in fact drinking coffee when I read
this.  Even though my 
name is not John, there was indeed some risk of a nasal
flush... happily just 
barely avoided.

However my own view is that it is entirely reasonable to
include the possibility 
of user training in discussions about problems and solutions
that directly 
involve users.

On the other hand, training users is known to be
particularly difficult and to 
be plausible only when satisfying some rather severe
constraints that ensure 
very high motivation, very simple mechanisms, very clear
information, and a slew 
of additional "very"s.

Best of all is that the realm of human factors usability and
training is 
entirely outside the skillset of an IETF working group, no
matter the skills of 
any particular participant.

At a minimum, any proposal in the working group that entails
multiple changes 
throughout the system -- such as including user training --
needs to specifify 
all of the components that need changing, what the changes
need to be, and what 
the basis is for believing that the aggregate set of changes
will have efficacy.

Oh, and it also needs to include a cost/benefit discussion,
since anything 
entailing changing multiple components is certain to be
expensive and likely to 
be risky.

Your following paragraph raised exactly this concern:

> Is this a whole solution? Of course not. We already
know that no such silver
> bullet exists. Can or should we lessen the degrees of
freedom in which bad
> guys can act? Sure seems like a reasonable idea to me.
The only real question
> in my mind is whether this particular piece of
technology is really worth the
> effort in the short/medium and long run. I think that
reasonable people can
> have reasonable differences of opinion on that. For the
dissenters, so long
> as there's not active harm what's the problem? Don't
use it if you think it's
> useless.

d/

-- 

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

Dave Crocker wrote:

>
>
> Michael Thomas wrote:
>
>>> Phishing doesn't have to use the real domain.
There are *countless* 
>>> ways of
>>> phishing that don't require it. ...
>>
>>
>> This assumes that social problems have to be solved
only in the 
>> technical
>> realm in order to be useful. I'm sure that John
will snort his coffee 
>> through
>> his nose, but training users to only expect to hear
from paypal from
>> paypal.com is most likely part of the solution. 
>
> However my own view is that it is entirely reasonable
to include the 
> possibility of user training in discussions about
problems and 
> solutions that directly involve users.
>
> On the other hand, training users is known to be
particularly 
> difficult and to be plausible only when satisfying some
rather severe 
> constraints that ensure very high motivation, very
simple mechanisms, 
> very clear information, and a slew of additional
"very"s.
>
> Best of all is that the realm of human factors
usability and training 
> is entirely outside the skillset of an IETF working
group, no matter 
> the skills of any particular participant.


Good thing that none of this is predicated on that being the
_only_ reason.
Or that there need be an _only_ reason.

>
> At a minimum, any proposal in the working group that
entails multiple 
> changes throughout the system -- such as including user
training -- 
> needs to specifify all of the components that need
changing, what the 
> changes need to be, and what the basis is for believing
that the 
> aggregate set of changes will have efficacy.


Good thing that nobody's proposing that then because it
sounds hard. 
Something
that might as a side benefit help that along seems worth
considering as 
a plus. Just like
we hope that a side benefit of DKIM will be to enable better
reputation, 
etc.

> Oh, and it also needs to include a cost/benefit
discussion, since 
> anything entailing changing multiple components is
certain to be 
> expensive and likely to be risky.


I don't know what "it" is here because it doesn't
seem to have anything 
to do
with what I was talking about.

       Mike

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

> This assumes that social problems have to be solved
only in the
> technical realm in order to be useful. I'm sure that
John will snort
> his coffee through his nose, but training users to only
expect to
> hear from paypal from paypal.com is most likely part of
the
> solution.

John had fortunately put his coffee down before reading your
message.

I entirely agree that user education is a key part of the
approach
to phishing.  As you may have heard, I've written a few
books somewhat
relevant to education of Internet users.

But if we're going to educate users, wouldn't it be better
to tell
them to do something that they can plausibly do and that
works?
Forcing bad guys to use lookalike domain names, expecting
senders to
use only a handful of domains, and expecting users to
reliably tell
the real domains from the fake ones flies in the face of
experience.

Bad guys are already using all sorts of tricks to fake out
the
appearance of domain names.  Some are pretty obvious, like
this,
which I think still works in many Windows MUAs:

 From: "Paypal Security <securitypaypal.com>" <phisherhighschool.ro>

or they use typo-alikes like paypa1 and, with the advent of
IDNs, the
number of typo-alikes vastly increases.  Or they use HTML to
put a
fake From: line buffer at the top of the message window that
matches
the appearance of popular MUAs.  Or any of a dozen other
things they
already do now.

What's the point of a security measure that the bad guys
already know
how to get around?

Here's the approximate model of the educated user depending
on SSP:

1) Incoming message appears to be from a bank.

2) Try and remember exactly what domain your bank uses.

3) Find the domain name in the return address.  Are you sure
that's
really the domain?  Maybe you should do a right-click and
view the
message source just to be sure.

4) Compare the domain name pixel by pixel, checking for
typo-alike
characters.  Are the pixels exactly right?  Are you sure
that's a letter
O rather than a greek or cyrillic omicron?

5) Name doesn't match?  Did your bank merge or change its
name lately?
Return to step 2.

6) ad nauseam

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.

If banks want to use 37 funky domains, they can register
them all with
the whitelist.  If the bank's name changes, it's one
whitelist update
rather than a million re-educated users.

I hope we all agree that phishing is basically a social
problem with
social solutions, but some technology is a lot more helpful
than
others when putting those social solutions in place.

R's,
John
_______________________________________________
NOTE WELL: This list operates according to 
http://
mipassoc.org/dkim/ietf-list-rules.html

Great. Another mail explosion about the purpose of SSP.

As a couple of people have said, this has been done before.

If there's something new to be said then do say it. If
not, let's please stop repeating ourselves. (The mail
that started the thread did contain something new, but
most of the messages don't.)

Meanwhile, we have an ssp-reqs document that we want to
finish, so why don't we do that instead.

Stephen.


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

Michael Thomas wrote:
>>> ... but training users to only expect to hear
from paypal from
>>> paypal.com is most likely part of the solution.

>>
...
>> Best of all is that the realm of human factors
usability and training 
>> is entirely outside the skillset of an IETF working
group, no matter 
>> the skills of any particular participant.
> 
> 
> Good thing that none of this is predicated on that
being the _only_ reason.
> Or that there need be an _only_ reason.

Michael, please review your original text, noted above.

1) No one said anything about "only", so I'm not
clear why you introduced it.

2. )You cite a specific training goal.  I do not claim to be
an expert in human 
factors, usability, cognitive psychology or in in the
techniques of deception, 
but I have enough training in all of them to be quite
certain that your 
assertion of likelihood is simply wrong.

Rather than make that direct, flat statement, I was
attempting to respond to the 
larger issue of this working group's making the kind of
predictions you made 
and, most significantly, making technical design decisions
that assume such 
predictions will be correct.


>> At a minimum, any proposal in the working group
that entails multiple 
>> changes throughout the system -- such as including
user training -- 
>> needs to specifify all of the components that need
changing, what the 
>> changes need to be, and what the basis is for
believing that the 
>> aggregate set of changes will have efficacy.
> 
> 
> Good thing that nobody's proposing that then because it
sounds hard. 

Then why did you make a prediction about users having to
distinguish between 
valid and invalid paypal strings?


>> Oh, and it also needs to include a cost/benefit
discussion, since 
>> anything entailing changing multiple components is
certain to be 
>> expensive and likely to be risky.
> 
> 
> I don't know what "it" is here because it
doesn't seem to have anything 
> to do with what I was talking about.

c.f., "any proposal", above.  The comment was
responding to your including 
predictions of needed user training.  Forgive me if I
thought you were making 
that prediction as part of the working group's technical
discussion.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

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

Dave Crocker wrote:

> Michael Thomas wrote:
>
>>>> ... but training users to only expect to
hear from paypal from
>>>> paypal.com is most likely part of the
solution. 
>>>
>>>
> ...
>
>>> Best of all is that the realm of human factors
usability and 
>>> training is entirely outside the skillset of an
IETF working group, 
>>> no matter the skills of any particular
participant.
>>
>>
>>
>> Good thing that none of this is predicated on that
being the _only_ 
>> reason.
>> Or that there need be an _only_ reason.
>
>
> Michael, please review your original text, noted above.
>
> 1) No one said anything about "only", so I'm
not clear why you 
> introduced it.

Steve Atkins -- who I was replying to -- asked what
"the" reason for SSP 
was.
As if there were one and only one. It's an unfair question
on its face 
because it
limits you to choose exactly one reason which can then be
shot down because
it in and of itself is inadequate justification. There are a
range of 
possible reasons
for SSP, both tangible and intangible. I offered one in each
category: the
spamassassin rule and the possibility that SSP's constraints
may lead to 
better
outcomes given user and phished company training.

> 2. )You cite a specific training goal.

I suggested no such goal for this working group.  Just like
there's a 
lot of people
who think that DKIM-base could be a useful tool with
reputation -- it 
just becomes
one of many reason why the protocol is worthwhile
standardizing. We 
don't have
to go down any of those paths to do our work, nor was I
suggesting that.

Frankly, if justifying any IETF work requires the degree of
prescience some
people seem to be demanding, we might as well pick up our
marbles and go 
home.
I happen to think that paralysis due to lack of a
functioning crystal 
balls is really lame.

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