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

From: Steve Atkins <[email-masked]>
Date: Wed, 8 Nov 2006 08:43:58 -0800

On Nov 8, 2006, at 8:10 AM, Scott Kitterman wrote:

> On Wed, 8 Nov 2006 07:55:15 -0800 Steve Atkins <[email-masked]>  
> 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.

Many of them use their own domains, for which they could trivially
publish SSP data.

So SSP will have minor, and temporary, effect on phishing using
the real domain. It will have minor negative effect on legitimate email.
Depending on what recipient ISPs do with the information ("SSP
validated sender!!!") it may actually make phishing more effective.

(I expect banks will take a look at SSP, decide it's entirely  
inappropriate
and work together for some sort of centralized authentication
eventually, so ISPs can really say "this email came from a real
bank" - functionality that SSP, or any pure self-signing approach, can
never offer.)

So phishing is clearly not a real use case. "I send no mail" is
a mildly interesting use case, but clearly doesn't require the
complexity being put together. So what is the real poster
child for SSP deployment?

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 09 Nov 2006 12:33:49 -0000

> You point out the underlying issue nicely.

Well at least it is a start to force the phishers into using look-alikes.
> Many of them use their own domains, for which they could trivially

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

-- 
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: Steve Atkins <[email-masked]>
Date: Thu, 9 Nov 2006 07:25:21 -0800

> Well at least it is a start to force the phishers into using look- 

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.

> 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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 09 Nov 2006 07:46:33 -0800

> 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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 09 Nov 2006 07:40:37 -0800

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

> 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

---

From: Steve Atkins <[email-masked]>
Date: Thu, 9 Nov 2006 08:04:33 -0800

On Nov 9, 2006, at 7:46 AM, Dave Crocker wrote:

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

"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

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 9 Nov 2006 11:16:59 -0500

On Thu, Nov 09, 2006 at 12:33:49PM -0000, Charles Lindsey wrote:
<snip>
> signature succeeds, and even where it doesn't").

So what I'm about to state has been said by others before:

Reputation has to start as neutral or negative. One can not start out
with a good reputation. Phishers don't need their domains to be around
that long to make some money.

Starting with a negative reputation means legitimate small companies
will be penalized. A possible solution to that is accreditation.

However, I think a better way is to state a relationship between two
entities and allow the ISP to validate such a relationship. That isn't
DKIM though.

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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 09 Nov 2006 09:28:44 -0800

Steve Atkins wrote:

>> Please explain.  If a sender publishes a policy that says I sign  all 
>> mail

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 09 Nov 2006 09:37:27 -0800

> ways in which it makes it worse."
...
> 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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 9 Nov 2006 10:11:30 -0800

On Nov 9, 2006, at 7:40 AM, Dave Crocker 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?

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.

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

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  

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

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.

> 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

---

From: Steve Atkins <[email-masked]>
Date: Thu, 9 Nov 2006 10:03:52 -0800

On Nov 9, 2006, at 9:37 AM, Dave Crocker wrote:

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 09 Nov 2006 11:05:11 -0800

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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 09 Nov 2006 11:50:48 -0800

Dave Crocker wrote:

>>> ways of
>> technical
> 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

---

From: John Levine <[email-masked]>
Date: 9 Nov 2006 20:17:06 -0000

> 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 <[email-masked]>" <[email-masked]>

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Nov 2006 20:39:52 +0000

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.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 10 Nov 2006 11:22:44 -0000

> will be penalized. A possible solution to that is accreditation.

Yes, reputation is neutral if there is no evidence to suggest otherwise.

But what I have in mind is the organizations that currently publish  
DNS-based blacklists of spams such as spamhaus.org, which curently seems  
to hold the best reputation among them.

These organizations try to spot spams/phishes/whatever with hours of their  
appearance (mainly by the use of honeypots AIUI) and promptly put them in  
their blacklists (this will tend to catch both spam-friendly ISPs and  
compromised zombies).

In the future, I would be expecting such organizations also to be  
maintaining blacklists of signers with bad reputations, and I would expect  
a phisher who started sending signed phishes from a look-alike domain  
would find himself in such a blacklist within hours.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 10 Nov 2006 11:33:00 -0000

On Thu, 09 Nov 2006 15:40:37 -0000, Dave Crocker <[email-masked]> 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).

---

From: Michael Thomas <[email-masked]>
Date: Fri, 10 Nov 2006 07:15:59 -0800

Charles Lindsey wrote:

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

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 10 Nov 2006 10:18:25 -0500

> people don't for the phishers to make a decent living, it seems).

It seems clear to me MUAs need to change.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Nov 2006 07:49:27 -0800

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

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

> therefore ought to be ignored if it is not whitelisted? 

Please review John Levine's note of today.

> 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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Nov 2006 07:49:38 -0800

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Nov 2006 08:04:31 -0800

Michael Thomas wrote:
>>> ... but training users to only expect to hear from paypal from
...
> 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.

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

> 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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 10 Nov 2006 08:46:04 -0800

Dave Crocker wrote:

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

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

---

From: "Powers, Jot" <[email-masked]>
Date: Fri, 10 Nov 2006 12:46:46 -0700

> relatively low investment and that it appeals to their dislike of brand name

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             <[email-masked]>
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

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 11 Nov 2006 12:26:44 -0000

On Fri, 10 Nov 2006 15:49:27 -0000, Dave Crocker <[email-masked]> wrote:

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

>> and therefore ought to be ignored if it is not whitelisted?
>

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

---

From: John Levine <[email-masked]>
Date: 11 Nov 2006 18:34:35 -0000

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

 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

---

From: <[email-masked]>
Date: Sat, 11 Nov 2006 14:31:00 -0500

The FDIC certifies a bank and authorizes them to use a logo, won't the
phishers immediately certify their mail with that logo?
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of John Levine
Sent: Saturday, November 11, 2006 1:35 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Collection of use cases for SSP requirements

 3) Done.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Sat, 11 Nov 2006 11:45:34 -0800

> phishers immediately certify their mail with that logo?

Yes. But that logo will be in the body of the message, not in the
MUA where it would be for a real bank messge.

Think web browser-ssl-padlock or web browser coloured address
bar, rather than an attached gif.

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Sat, 11 Nov 2006 11:57:10 -0800

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

The above is intuitively reasonable.  Simple procedure.  Very solid logic basis 
for asserting trust.  Very solid method of signaling to the user.

The only question is whether it would work.

There is some indication that it won't. (I know of a vendor who tried the 
approach you describe and their research caused them to fall back to something 
much simpler.)

Average users -- ie, possibly none of us reading this note, but possibly all of 
us, too, and certainly me --  are astonishingly good at getting confused among 
the different signals placed on a screen.  (And elsewhere in real life, but 
let's stay within our own area of concern.)

I don't have the/an answer, but I do not know the procedure you describe is only 
capable of working

    a) when considered in the context of the many *different* signals an average 
user will get, as your model is expanded to include other trust certifiers 
(doctors, accountants, lawyers, city government, charities, credit agencies, 
...), and

    b) when validated empirically within an environment having such a mix.

d/

-- 

   Dave Crocker

---

From: "John Levine" <[email-masked]>
Date: 11 Nov 2006 15:08:12 -0500

> phishers immediately certify their mail with that logo?

No, the idea is that the FDIC certifies a set of signing domains, and  
the logo goes with the certifier, so your MUA would show the logo  
only on mail with a sig from a domain in the list.

Bad guys could certainly put the logo in their mail and try to fool  
people. I don't know enough about user interface design to know how  
much of a problem that will be.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 11 Nov 2006 12:46:40 -0800

Dave Crocker wrote:
>
>
> John Levine wrote:
>>>>> But how do you tell, automatically, that a message is from a 
>>>>> "bank",  and therefore ought to be ignored if it is not whitelisted?
>>
> The above is intuitively reasonable.  Simple procedure.  Very solid 
> logic basis for asserting trust.  Very solid method of signaling to 
> the user.
>
> There is some indication that it won't. (I know of a vendor who tried 
> the approach you describe and their research caused them to fall back 
> to something much simpler.)
>
> Average users -- ie, possibly none of us reading this note, but 
> possibly all of us, too, and certainly me --  are astonishingly good 
> at getting confused among the different signals placed on a screen.  
> (And elsewhere in real life, but let's stay within our own area of 
> concern.)
>
> I don't have the/an answer, but I do not know the procedure you 
> describe is only capable of working
>
>    a) when considered in the context of the many *different* signals 
> an average user will get, as your model is expanded to include other 
> trust certifiers (doctors, accountants, lawyers, city government, 
> charities, credit agencies, ...), and
>
Not to mention what they'd do when they got a Dutch Ruble or a French 
Kroner.
The other thing here is that I think that it subtly assumes that there's 
trust within
the group subsumed under the symbol, which doesn't seem especially good. Not
to mention that the Giver of the Golden $ Seal is a great way to create 
a trust or
other abusive old boy's clubs.

It's not entirely clear to me that what we shouldn't be placing more 
emphasis on
doing the things that make law enforcement more possible though.

       Mike, does this have anything to do with SSP or DKIM though?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "David Sanchez" <[email-masked]>
Date: Sat, 11 Nov 2006 22:27:51 +0100

>        Mike, does this have anything to do with SSP or DKIM though?

I really think we are losing focus here.

I thought DKIM purposes does not include specific actions of MTA nor
MUA for mails, being signed, not signed or badly signed.

IMHO, DKIM purpose is making information available, Is up to the
MTA/MUA what it does with this information. But i can be tremendously
wrong :-S .

BTW: European currency symbol is € (euro) :-P

---

From: Steve Atkins <[email-masked]>
Date: Sat, 11 Nov 2006 14:47:42 -0800

> MTA/MUA what it does with this information. But i can be tremendously

If nobody is ever going to use a piece of information, then expending
a lot of effort and complexity to make it available is a mistake.

Given that, plausible use cases are part of the process of deciding
what to keep and what not to.

Also, if there's a dependency on other standards for some functionality
(for example, a third party accreditation system of some sort) then that
dependency needs to be understood, so as to make sure that they
are flexible enough to work with some subset of reasonable systems.

(I don't see much along those lines with dkim-base, so none of these
issues should slow dkim development and deployment, but I do see
them all over with SSP).

Cheers,
   Steve

---

From: "David Sanchez" <[email-masked]>
Date: Sun, 12 Nov 2006 17:27:32 +0100

All this is IMHO (with H being Humble ) :-)

> a lot of effort and complexity to make it available is a mistake.

Agreed

> what to keep and what not to.

That's true, but where is the difference between plausible use cases
and all the use cases in the world?

My thought just was about this thread, becoming a little strange
talking about $, € signs, in MUA and windows popping or something.

In my humble opinion this specific thread was getting too much into
implementation details, that has to the best of my knowledge little to
do within a standard.

> are flexible enough to work with some subset of reasonable systems.

IMHO this not apply to current thread.

There is a lot of real world use cases to discuss before getting into
MUA GUI details, i think.

> issues should slow dkim development and deployment, but I do see

:-)

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 12 Nov 2006 17:13:53 +0000

>       Mike, does this have anything to do with SSP or DKIM though?

No. Most of this is off-topic. So why don't we stop discussing
it here? I'm sure there are other fora where this UI stuff is
on-topic, but its not here.

This is the 2nd time in a week I've had to ask that we stick
to the work at hand. Bit disappointing that.

Stephen.

---

From: John Levine <[email-masked]>
Date: 12 Nov 2006 19:08:56 -0000

>No. Most of this is off-topic.

Just to be sure I understand correctly, is it on- or off-topic to
discuss usage scenarios for SSP?

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 12 Nov 2006 11:41:56 -0800

...
> issues should slow dkim development and deployment, but I do see

+1

Nicely said.

 > and all the use cases in the world?

An entirely fair question, and one that we should all maintain constant 
vigilance about, in order to carve away the ones the group feels are not 
plausible, not within scope, or otherwise need to be excluded.

 > talking about $, € signs, in MUA and windows popping or something.

There is are two elephants in our room.

One gets acknowledged regularly and the other less often.  The first is the 
difference between a potential signer's saying what they do, versus a potential 
signer's attempting to tell a recipient what to do.  I think the wg has 
(finally) gotten a stable position on this.

The second elephant is the broadly-held view that some/all of the work of the 
DKIM effort is really for end-user consumption.  That leads to assumptions about 
how the end-user in brought into the mix, particularly in terms of what will be 
presented to them.  The problem with this elephant is that it is so pervasive 
and so entirely appealing, but is so poorly understood (by experts, nevermind by 
this working group.)  So it repeatedly gets added to the discussion mix.

So my own purpose in citing MUA specifics is to try to get us to keep them out 
of the wg's scope...

d/

-- 

   Dave Crocker

d/

-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 12 Nov 2006 15:06:23 -0500

> issues should slow dkim development and deployment, but I do see

This is all constrained by the quality of the crystal balls we all posses in 
order to _know_ no one will ever use a piece of information.  Given the IETF 
track record with predictive use analysis, I don't think we should feel 
particularly comfortable with the idea that we know what will and won't be 
used.

Scott K

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 13 Nov 2006 10:31:54 -0000

> implementation details, that has to the best of my knowledge little to

It is no use putting a feature into a standard if there is some doubt  
whether a viable implementation is possible. In that case, discussion of  
implementation is very much on topic.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 13 Nov 2006 10:40:48 -0000

> bar, rather than an attached gif.

Well that implies that every MUA worldwide needs to be upgraded before  
this whitelist solution will work.

And before that, you have to define a communication protocol to convey  
this information from the verifier/whitelist-looker-up/whatever to the MUA  
that the Bad Guys cannot spoof.

It can't go in the body, because I read all my mail as plain text, and  
drop HTML on sight as being sure evidence of spam. And Bad Guys can write  
bodies too.

You can't do it in the headers, because Bad Guys can write headers too.

You might be able to do it in some special feature of POP3 or IMAP, but  
that would mean an upgrade to the POP3 and IMAP protocols, and some people  
don'e use POP3 and IMAP anyway (mail arrives at my machine by SMTP).

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Nov 2006 12:23:01 +0000

> discuss usage scenarios for SSP?

(That's a reasonable-sounding, but basically misleading question,
to which I guess you most likely already know the answer,
nevertheless...)

The ssp-reqs document discusses use cases. Feel free to comment on
that text or propose new text for those sections of the document.

We should not feel free to endlessly debate SSP use cases on the
list, especially when there's already been so much repetition on
this topic.

Lastly, UI design issues are not particularly relevant for a
protocol where none of the current use cases have a warm body
attached. That was what I said was off-topic.

Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Nov 2006 08:20:07 -0800

> this whitelist solution will work.

A whitelist is useful as soon as a single recipient (filter, user, whatever) can 
apply it.  It's benefit improves as it is incrementally adopted.  There are 
plenty of black- or white- lists that demonstrate this.

> this information from the verifier/whitelist-looker-up/whatever to the 
> MUA that the Bad Guys cannot spoof.

Although true, there is no requirement that it be "standardized".  Different 
existing lists have different access methods.

Enough of them tend to have strong similarities to make standardization worth 
pursuing, but that is only recent. (eg., 
<http://www.domain-assurance.org/protocol-overview.phtml>.)

> drop HTML on sight as being sure evidence of spam. And Bad Guys can 
> write bodies too.

I believe the mechanism that Steve was describing does not carry the trusted 
logo along with the message, but affixes it as a result of out-of-band 
validation methods.  His reference to the browser lock was, I believe, an 
exemplar of user interface design, rather than information-carriage along a path.

> You can't do it in the headers, because Bad Guys can write headers too.

Not when the headers are signed.  (eg, <http://goodmailsystems.com>.)

d/

-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Mon, 13 Nov 2006 07:47:44 -0800

> list, especially when there's already been so much repetition on

The three I see mentioned are

   1. I sign all mail I send with DKIM.

   2. Someone else is sending mail with my domain in RFC822 From:

   3. I send no mail.

It'd be nice to see something fleshed out that shows the benefit
to sender or recipient in a real-world case in a little more detail,
along with a fuller analysis of the benefit SSP adds to the
scenario.

> attached. That was what I said was off-topic.

One of the most obvious useful uses for DKIM will be to combine DKIM
sender identity with a domain based whitelist in order to communicate
information about the message to the recipient.

Are you suggesting that this is off topic for discussion on this list?

Cheers,
   Steve

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 13 Nov 2006 17:17:03 +0100

Charles Lindsey wrote:

> you have to define a communication protocol to convey this
> information from the verifier/whitelist-looker-up/whatever
> to the MUA that the Bad Guys cannot spoof.

Yes, that point is hidden near the end of the WG Charter:

| Once the primary goals are met, the DKIM working group may
| also study whether to adopt a work item for specifying a
| common mechanism to communicate the results of message
| verification to the message recipient. The generation of a
| standards-track specification on this topic will require an
| update to the DKIM working group charter.

One proposal in that direction is
http://www3.tools.ietf.org/html/draft-kucherawy-sender-auth-header

> It can't go in the body, because I read all my mail as plain
> text, and drop HTML on sight as being sure evidence of spam.

You might miss some interesting articles on mailing lists with
that strategy.  Admittedly I do press Del very fast if it uses
some less than 8 points font in blue "style" (with font-tags,
I won't see similar CSS-follies).

> You can't do it in the headers, because Bad Guys can write

They have serious difficulties to add their forgeries _above_
the timestamp line of your favourite DKIM-verifier.

Frank

---

From: Steve Atkins <[email-masked]>
Date: Mon, 13 Nov 2006 12:41:12 -0800

On Nov 13, 2006, at 2:40 AM, Charles Lindsey wrote:

> Well that implies that every MUA worldwide needs to be upgraded  
> before this whitelist solution will work.

No. There is immediate benefit to incremental upgrades.

> And before that, you have to define a communication protocol to  
> convey this information from the verifier/whitelist-looker-up/ 
> whatever to the MUA that the Bad Guys cannot spoof.

Yes. This is not rocket science, though, it's a solved problem.

(TLS with a restricted certificate list would be the proof of  
principle, but the technical details are out of scope and really  
don't matter).

> It can't go in the body, because I read all my mail as plain text,  
> and drop HTML on sight as being sure evidence of spam. And Bad Guys  
> can write bodies too.
>

If we had some standard for signing the body and headers of the  
message, such that we could authenticate that the message had been  
sent by, or authorised by, some particular domain and  
cryptographically demonstrate that the message hadn't been modified  
significantly since then then we could solve both of those problems.

> You might be able to do it in some special feature of POP3 or IMAP,  
> but that would mean an upgrade to the POP3 and IMAP protocols, and  
> some people don'e use POP3 and IMAP anyway (mail arrives at my  
> machine by SMTP).

No.

We're talking about a third-party domain based whitelist keyed by  
cryptographically authenticated (DKIM) sender domains, with  
(optional, but valuable) MUA support for querying the whitelist. It  
requires nothing more complex than DK and a whitelist.

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Nov 2006 12:54:52 -0800

>   2. Someone else is sending mail with my domain in RFC822 From:

I thought the group had agreed to defer #2, on the basis that use of selectors 
or sub-domains by the outsourced signer is sufficient.

d/

-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Mon, 13 Nov 2006 13:00:04 -0800

On Nov 13, 2006, at 12:54 PM, Dave Crocker wrote:

> I thought the group had agreed to defer #2, on the basis that use  
> of selectors or sub-domains by the outsourced signer is sufficient.

Possibly. I was just reading along with draft-ietf-dkim-ssp- 
requirements-02.txt sections 4.1 through 4.3.

Cheers,
   Steve

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Nov 2006 21:08:48 +0000

>   2. Someone else is sending mail with my domain in RFC822 From:

No. The use cases the WG is working on are documented in the
ssp-reqs draft. I hope you've read that. If not, please do so
and the comment on that text.

(Note that it doesn't matter whether your list above is right
or wrong. What matters is that there's already a list in the
ssp-reqs draft.)

> Are you suggesting that this is off topic for discussion on this list?

I suggest you read the WG charter [1]. You'll notice a sentence
starting "Once the primary goals are met..."

Stephen.

[1] http://www.ietf.org/html.charters/dkim-charter.html
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Mon, 13 Nov 2006 13:18:13 -0800

> or wrong. What matters is that there's already a list in the

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

Perhaps you could read the draft, and clarify if I've misunderstood
something.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Mon, 13 Nov 2006 13:36:00 -0800

> Perhaps you could read the draft, and clarify if I've misunderstood
As the person who wrote 4.2, it definitely does not correspond to
your #2. I'm somewhat at a loss as to how you could have interpreted
it that way.

          Mike

---

From: Steve Atkins <[email-masked]>
Date: Mon, 13 Nov 2006 13:43:12 -0800

> your #2. I'm somewhat at a loss as to how you could have interpreted

It's a (one-line, hence possibly open to misinterpretation) summary of
the situation described in the first paragraph of 4.2.

Cheers,
   Steve

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Nov 2006 22:00:30 +0000

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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 13 Nov 2006 14:16:32 -0800

> the situation described in the first paragraph of 4.2.
I hope you're not misunderstanding me because I really don't understand
how you could have thought this had to do with third party signing. This
scenario is #1 with some expectation on the part of the signer that it ought
to arrive with signature intact. Can you tell me what led you to believe 
that
it had to do with 3rd party signing? If there's something misleading, I'd
like to fix it.

       Mike

---

From: Steve Atkins <[email-masked]>
Date: Mon, 13 Nov 2006 14:23:23 -0800

On Nov 13, 2006, at 2:16 PM, Michael Thomas wrote:

> to arrive with signature intact. Can you tell me what led you to  
> believe that

I didn't use the term "signing" at all, and am certainly not confused
in the 3rd party signing direction by anything in the draft. I don't see
any real problem with the phrasing there.

The issue discussed in 4.2 is someone other than A sending mail
to B with A's domain in the 822 From: address, without authorization
from A.

Throwing the word "unauthorized" into my description might have
made that clearer.

Cheers,
   Steve

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 14 Nov 2006 12:43:47 -0000

On Mon, 13 Nov 2006 16:20:07 -0000, Dave Crocker <[email-masked]> wrote:

> A whitelist is useful as soon as a single recipient (filter, user,  
> whatever) can apply it.

Be careful there. We want people out there to welcome and accept these  
protocols when they start to be deployed. A huge spate of false positives  
and false negatives will rapidly cause it to come into disrepute and to  
wither. This is not a technical problem - it is a social problem, but we  
ignore it at our peril.

Q. "My cousin John, who uses the same bank as me, gets nice "SAFE" logos  
on his bank messages. I don't see them. Should I be worried?"
A. "You need to use a different MUA."

Q. "I bank with Bank of America. I always used to get those "SAFE" logos.  
Now they have suddenly stopped".
A. "I see from your headers that you are on holiday in the Netherlands  
Antilles. The ISP you are using there doesn't use whitelists for American  
Banks - just for the Bank of the Antilles and ABN/AMRO."

> Although true, there is no requirement that it be "standardized".   
> Different existing lists have different access methods.

No implementor of the popular MUAs is going to invest effort in  
implementing this "SAFE" Logo if there are lots of different protocols  
which might be used. But I see now this is "work for later" according to  
our charter.

> Not when the headers are signed.  (eg, <http://goodmailsystems.com>.)

And there you gave a good answer (and it also brings the thread back on  
topic :-). OK, such schemes are possible. But the Bad Guy can still insert  
the "SAFE" header and sign it, so there is still work for the verifying  
agent to do by way of spotting such already present headers and acting  
accordingly. Trouble is, lots of ISPs are going to do a poor job of this  
if left to their own devices, so it needs a very tightly drawn  
specification of how to do it. Otherwise we shall have those false  
positives/negatives and the whole scheme will fail.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 24 Nov 2006 20:52:11 -0800

Charles Lindsey wrote:
> protocols when they start to be deployed. A huge spate of false 
> positives and false negatives will rapidly cause it to come into 
> disrepute and to wither. This is not a technical problem - it is a 
> social problem, but we ignore it at our peril.

I do not see how your statements relate to the one of mine to which you appear 
to be responding.

Are you suggesting that my statement was incorrect?

If so, how?  Please remember that the topic was as stated in the Subject line 
and my comment was in that context.

> A. "You need to use a different MUA."

There is a new car that automatically performs parallel parking.  Is there some 
sort of problem creating by observing that you get that feature only by buying a 
different car?

Or a different end-user feature by using a different MUA?

In other words, if your example is intended to be cautionary, please clarify, 
with substantial detail.

> Q. "I bank with Bank of America. I always used to get those "SAFE" 
> logos. Now they have suddenly stopped".
> Antilles. The ISP you are using there doesn't use whitelists for 
> American Banks - just for the Bank of the Antilles and ABN/AMRO."

This, I think, is a very interesting example, conceptually.

The detail you supply, however, is confusing.  Your sentence beginging "The 
ISP..." does not make sense to me.

I guess that you are presuming that all of the relevant email functions are 
under control of the local-access ISP and that, therefore, when traveling, I 
might get a different MUA?

> which might be used. 

Statements containing firm absolutes, when they involve human decision-making, 
tend to be problematic.  By way of example, note that web page designers 
actually do have a wide variety of pages, with the same content, designed for 
different devices and browsers.  That such a situation is absurd and often does 
not work correctly is not the point.  The point is that I believe it disproves 
your absolute.

That said, of course, simplification is the reason competitors collaborate on 
unified protocols.

But again, I find myself not understanding how your point is responsive to the 
discussion in this thread.  Perhaps my commenting that standardization was not 
required was taken to mean that standardization is not a huge win?  Gosh I hope 
no one thinks I would believe such a thing...

> topic :-). OK, such schemes are possible. But the Bad Guy can still 
> insert the "SAFE" header and sign it, so there is still work for the 
> verifying agent to do by way of spotting such already present headers 
> and acting accordingly. .

Typical discussions, about such indications of safety, distinguish between what 
is carried in the message, across the Internet, versus what is generated within 
the trusted Administrative Management Domain (ADMD) of the recipient.  (It might 
be generated at presentation time or it might be added to the message within the 
trust domain, but that is a minor point, I think, for this discussion.

User-visible safety indicators are typically viewed as the realm of the 
delivering ADMD and not of the message as it is received from the open Internet.

In that context, how does your described threat survive?

d/
-- 

   Dave Crocker

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 28 Nov 2006 13:36:18 -0000

On Sat, 25 Nov 2006 04:52:11 -0000, Dave Crocker <[email-masked]> wrote:

> I do not see how your statements relate to the one of mine to which you  
> appear to be responding.

Just that if a feature is deployed with an inadequate infrastructure to  
support it, it may make matters worse initially, and so bring the whole  
idea into disrepute.

> The detail you supply, however, is confusing.  Your sentence beginging  
> "The ISP..." does not make sense to me.
>
> I guess that you are presuming that all of the relevant email functions  
> are under control of the local-access ISP and that, therefore, when  
> traveling, I might get a different MUA?

You have connected your laptop to the system provided by the person you  
are staying with, the conference organizers, the hotel, or whatever. Or  
perhaps you are without your laptop and are a guest on someone else's  
system. And the system you are connected to just just not provide the  
particular set of whitelists you were used to back home.
> Statements containing firm absolutes, when they involve human  
> decision-making, tend to be problematic.....  That such a situation is  
> absurd and often does not work correctly is not the point.  The point is  
> that I believe it disproves your absolute.

My statement does not need to be absolute to reflect the likely  
consequence of trying to implement whitelists piecemeal.

>>  And there you gave a good answer (and it also brings the thread back  
>> on topic :-). OK, such schemes are possible. But the Bad Guy can still  
> Typical discussions, about such indications of safety, distinguish  
> between what is carried in the message, across the Internet, versus what  
> is generated within the trusted Administrative Management Domain (ADMD)  
> of the recipient.

If you are wanting that "SAFE" logo to appear on your MUA when a  
whitelisted email is received, then that information has to be  
communicated somehow from the site that checked the whitelist (which is  
usually in a diferent ADMD to yourself). That means it must be possible to  
communicate it by SMTP (you cannot assume that everybody uses POP3 or IMAP  
to access their mail, and even there it would need upgrades to those  
protocols).

The only place in SMTP to hide it is in the headers of the message. So  
those would have to be signed, which means verifying capability in the  
MUA, together with means to spot alleged signings by the Bad Guy. This is  
all, in principle, doable (that is how the 'Padlocks' on web browsers  
work), but it will not be a simple system to set up and deploy.