Collection of use cases for SSP requirements

On Nov 9, 2006, at 4:33 AM, Charles Lindsey wrote:

> On Wed, 08 Nov 2006 16:43:58 -0000, Steve Atkins  
> <steveblighty.com> wrote:
>
>> On Nov 8, 2006, at 8:10 AM, Scott Kitterman wrote:
>>>
>>> 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.
>
> Well at least it is a start to force the phishers into
using look- 
> alikes.

No, it isn't. There is no way in which SSP makes this
better.
Depending on how it's implemented by recipients there are
ways
in which it makes it worse.

>> 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.
>>
>> 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.  
> I envisage these will operate rather like the present
DNSBL  
> blacklists. You choose such a site that you trust, and
then ask its  
> advice on the action you should take according to the
signer, From  
> address, etc. I would suppose that phishers own domains
would  
> rapidly acquire a rather poor reputation (and the
advice should be  
> to "delete all mail where the signature succeeds,
and even where it  
> doesn't").

If you need an external trust model to tell you whether you
should
trust SSP, then you can simply use just the external model
and
avoid the whole self-publication thing altogether.

Then whence SSP?

(And, more to the point, if we all agree that SSP is
pointless
without a third party trust model then the SSP specification
is
neither complete, nor ready to review, until that trust
model
is also defined).

Cheers,
   Steve

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

Steve Atkins wrote:
>> Well at least it is a start to force the phishers
into using look-alikes.
> 
> No, it isn't. There is no way in which SSP makes this
better.
> Depending on how it's implemented by recipients there
are ways
> in which it makes it worse.


Steve,

Anything said that firmly -- and saying something many will
consider unexpected 
-- really does require the details that justify it.

This is a hearty "please" requesting that you
elaborate.

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:46 AM, Dave Crocker wrote:

>
>
> Steve Atkins wrote:
>>> Well at least it is a start to force the
phishers into using look- 
>>> alikes.
>> No, it isn't. There is no way in which SSP makes
this better.
>> Depending on how it's implemented by recipients
there are ways
>> in which it makes it worse.
>
>
> Steve,
>
> Anything said that firmly -- and saying something many
will  
> consider unexpected -- really does require the details
that justify  
> it.
>
> This is a hearty "please" requesting that you
elaborate.

"There is no way in which SSP makes this better."

Phishing does not require the use of the real domain and,
in current practice, some of the better phishes already do
not
use the original domain (for a variety of reasons, including
the remnants of previous attempts to defend against
byte-for-byte
usage of domains by those unauthorized to use them).

Most users don't look at the headers of the mail, other than
the subject line and the "friendly from", as our
ESP friends describe
the comment in the From: header.

There is no common usage of a single canonical domain in
the headers of the legitimate email from many financial
institutions
anyway, so even those users who do look at the From: field
have no expectation of seeing anything specific there.

SSP concentrates on protecting byte-for-byte duplicates
on the wire of the original domain in a small minority of
the
contexts in which it's used. It is not concerned with
different
domains that render to identical or near-identical glyphs
(1-vs-l,
punycode and other approaches), it isn't concerned with
homonyms and synonyms, it isn't concerned with plausible
lookalike domains, nor does it concern itself with use of
domains in the body of the message.

If phishers chose to be similarly constrained in their
concerns
then SSP would be a useful tool against phishing.

"Depending on how it's implemented by recipients there
are
ways in which it makes it worse."

Any phisher can create valid DKIM+SSP records for the domain
they
use. Without some sort of external trust model there is no
difference
between that mail and valid mail from a bank.

If (and this is where the "implemented" bit comes
in) recipient ISPs
or MUAs annotate mail in any way that suggests that mail
that is
validly DKIM signed and claims that no non-signed mail is
ever
sent is, in any way at all, more trustworthy than, say,
non-DKIM
mail or mail with no SSP constraints that will make the
phish
more plausible than it would be in an MUA which pays no
attention to DKIM or SSP.

Lest you suggest that no ISP would ever be foolish enough to
do such a thing, look at Hotmails past behaviour with
SenderID.

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

Steve Atkins wrote:

> "Depending on how it's implemented by recipients
there are
> ways in which it makes it worse."
...
> If (and this is where the "implemented" bit
comes in) recipient ISPs
> or MUAs annotate mail in any way that suggests that
mail that is
> validly DKIM signed and claims that no non-signed mail
is ever
> sent is, in any way at all, more trustworthy than, say,
non-DKIM
> mail or mail with no SSP constraints that will make the
phish
> more plausible than it would be in an MUA which pays no
> attention to DKIM or SSP.
> 
> Lest you suggest that no ISP would ever be foolish
enough to
> do such a thing, look at Hotmails past behaviour with
SenderID.

I think you are exploring a realm that I class as
"creative misunderstanding" 
where the problem is with someone going significantly beyond
what is said or 
promised.  And, indeed, there is a solid basis for believing
that any 
interesting mechanism will produce at least some creative
misunderstanding.

So, I think, a response to a concern about this needs to ask
a couple of basic 
questions:

1. For those who use the mechanism "correctly" is
there substantial value-add?

2. Is there something about the mechanism, or its
specification, that 
*encourages* the misunderstanding?  Answers might go as far
an noting common 
characteristics of human tendencies or as near as observing
particular language 
usage in the spec.

By way of priming this line of query a bit, your noting the
hotmail/sender-id 
example certainly seems useful to me.  More generally, we
have plenty of 
evidence that people thoroughly misunderstand what signing
is and is not useful 
for.

My concern is that this line of observation quickly
justifies doing nothing at 
all.  (Since any action is subject to abuse, take no
action.)

My own answer to question #1 is that being able to
trivially, accurately and 
reliably being able to reject a class of bogus mail is
rather nice.  If someone 
says their domain is always signed, then I can choose to
toss mail that I get 
with that domain that is not signed (... ummmmm, assuming
that the email service 
is not breaking signatures very much.)

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 9:37 AM, Dave Crocker wrote:

>
>
> Steve Atkins wrote:
>
>> "Depending on how it's implemented by
recipients there are
>> ways in which it makes it worse."
> ...
>> If (and this is where the "implemented"
bit comes in) recipient ISPs
>> or MUAs annotate mail in any way that suggests that
mail that is
>> validly DKIM signed and claims that no non-signed
mail is ever
>> sent is, in any way at all, more trustworthy than,
say, non-DKIM
>> mail or mail with no SSP constraints that will make
the phish
>> more plausible than it would be in an MUA which
pays no
>> attention to DKIM or SSP.
>> Lest you suggest that no ISP would ever be foolish
enough to
>> do such a thing, look at Hotmails past behaviour
with SenderID.
>
> I think you are exploring a realm that I class as
"creative  
> misunderstanding" where the problem is with
someone going  
> significantly beyond what is said or promised.  And,
indeed, there  
> is a solid basis for believing that any interesting
mechanism will  
> produce at least some creative misunderstanding.
>
> So, I think, a response to a concern about this needs
to ask a  
> couple of basic questions:
>
> 1. For those who use the mechanism
"correctly" is there substantial  
> value-add?
>
> 2. Is there something about the mechanism, or its
specification,  
> that *encourages* the misunderstanding?  Answers might
go as far an  
> noting common characteristics of human tendencies or as
near as  
> observing particular language usage in the spec.
>
> By way of priming this line of query a bit, your noting
the hotmail/ 
> sender-id example certainly seems useful to me.  More
generally, we  
> have plenty of evidence that people thoroughly
misunderstand what  
> signing is and is not useful for.
>
> My concern is that this line of observation quickly
justifies doing  
> nothing at all.  (Since any action is subject to abuse,
take no  
> action.)
>
> My own answer to question #1 is that being able to
trivially,  
> accurately and reliably being able to reject a class of
bogus mail  
> is rather nice.  If someone says their domain is always
signed,  
> then I can choose to toss mail that I get with that
domain that is  
> not signed (... ummmmm, assuming that the email service
is not  
> breaking signatures very much.)

Remember that the context of the mail to which you're
replying
is specifically use of SSP to reduce the problem of
phishing.

In the context of phishing emails (that is emails which are
intentionally sent by a well-informed sender with the intent
of deceiving the recipient) then the size of your class of
bogus
email will rapidly converge towards zero.

Broadening the scope of the discussion of
"value-add" and
"creative misunderstanding" to non-phishing use
cases would be
worthwhile, sure, but lets do it explicitly.

Cheers,
   Steve

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