Subject: RE: [ietf-dkim] SSP = FAILURE DETECTION

From: Arvel Hathcock <[email-masked]>
Date: Fri, 08 Sep 2006 16:16:00 -0500

> The purpose of a valid DKIM signature is to identify the party that
> signed the message. 

Here, you are completely correct.

> Whether this is a first-party or third-party signature is largely 
> irrelevant. 

Here, you are correct only if you restrict your vision to DKIM-BASE.  Once we start talking about DKIM-SSP, first-party vs third-party becomes extremely relevant.

-- 
Arvel 

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

---

From: [email-masked] (Wietse Venema)
Date: Fri, 8 Sep 2006 20:40:58 -0400 (EDT)

Arvel Hathcock:
> Here, you are correct only if you restrict your vision to DKIM-BASE.
> Once we start talking about DKIM-SSP, first-party vs third-party
> becomes extremely relevant.

The importance of first/third party is easily overstated.

Here is an example why first-party signatures can be dangerous.

If I get mail with a perfectly valid first-party DKIM signature,
it could very well be a cleverly disguised domain clone attack
(say, bigbank versus big-bank etc.).  Naively believing a valid
first-party DKIM signature can be a costly mistake.

And here is an example why third-party signatures can be safe.

If I receive mail from my bank and I know their signing domain,
then it does not matter what the from domain says.  I already know
that the mail comes from the bank, regardless of whether this mail
has a first-party or third-party signature. The signing domain is
the basis for trust.

To summarize: naively believing a valid first-party DKIM signature
can be a costly mistake. The signing domain is a better basis for
trust.

	Wietse

---

From: Dave Crocker <[email-masked]>
Date: Sat, 09 Sep 2006 09:07:38 -0700

> Here is an example why first-party signatures can be dangerous.

Right.

They key point, to me, is that a signature by the rfc2822.From domain is 
likely to help control against some existing types of phishing, but it 
clearly will not help against others.

Worse, we have no empirical data about what is or is not effective, in 
helping end-users to detect phishing.  So, to the extent that end-users 
figure into anyone's expectations about DKIM's benefits against 
phishing, we are flying quite blind.

Therefore, to the extent that anyone touts a DKIM-based mechanism as 
defeating phishing, we run the risk of undermining all of DKIM's 
credibility, by setting expectations far too high.

d/
-- 

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

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 9 Sep 2006 12:35:17 -0400

> clearly will not help against others.
I don't think anyone would disagree with this.

> phishing, we are flying quite blind.
The best way to help end-users avoid getting phished it to not accept phishing 
messages for delivery.  DKIM-SSP where strict policy statements are published 
offer a mechanism for this.  From my perspective, the utility of DKIM as it 
relates to end-users is, I agree, quite uncertain.

> credibility, by setting expectations far too high.
Agreed.  Is anyone doing this?

Scott K

---

From: [email-masked] (Wietse Venema)
Date: Sat, 9 Sep 2006 12:45:04 -0400 (EDT)

> > > Here is an example why first-party signatures can be dangerous.
...
> relates to end-users is, I agree, quite uncertain.

This is exactly the trap that I was describing in the mail cited above.

Blindly believing DKIM-SSP gives a false sense of security, and
provides criminals with even more convincing ways to rob people.
I really recommend that you read my entire email message.

> Agreed.  Is anyone doing this?

See my point above. We're already raising expectations too high,
by claiming that DKIM-SSP will block phishing mail. It will only
make phishing mail look more authentic.

	Wietse

---

From: John Levine <[email-masked]>
Date: 9 Sep 2006 17:26:37 -0000

>The best way to help end-users avoid getting phished it to not accept
>phishing messages for delivery.  DKIM-SSP where strict policy
>statements are published offer a mechanism for this.

I get a message from [email-masked].  It has a valid
signature.  I check the SSP for ebay-verify.com, which says "MAJOR
PHISHING TARGET, ACCEPT ONLY WITH SIGNATURE."  So I drop it into the
recipient's mailbox with a gold star on it.

What have we just accomplished?

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 9 Sep 2006 13:40:27 -0400

> What have we just accomplished?
A bad thing.  Don't put the gold star on it.  That would be a mistake.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 9 Sep 2006 13:47:17 -0400

On Saturday 09 September 2006 12:45, Wietse Venema wrote:
> > phishing messages for delivery.  DKIM-SSP where strict policy statements
> > are published offer a mechanism for this.  From my perspective, the
> > utility of DKIM as it relates to end-users is, I agree, quite uncertain.
>
I believe that I understand your point and I don't think it is. 

> I really recommend that you read my entire email message.
If you had said that Blindly believing [positive indications from] 
DKIM-SSP ... then I would agree 100%.  I do not think that SSP can help 
assert anything about the goodness of a message.  I think it's only utility 
is in finding some that are definitely bad.

> make phishing mail look more authentic.
I fear we are talking past each other some how.  

I agree that if anyone takes an SSP 'Pass' as meaningful, that is exactly what 
would happen.  I agree that users and systems should not do that.

To narrow the scope to where I think there is some potential utility, I think 
SSP could be helpful for the case of what I would call 'exact domain 
phishing'.  The utility is that exact domain phishes could be rejected and so 
the potential phishee never sees the message.  While many users might mistake 
mail from look-alike domains, getting the exact domain phishes out of the 
message stream is, I think, useful.

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 9 Sep 2006 14:07:55 -0400

----- Original Message -----
From: "John Levine" <[email-masked]>
To: <[email-masked]>

> What have we just accomplished?

Nothing and it would be DANGEROUS to do so.

But read the subject title:

        SSP = FAILURE DETECTION

If ebay-verify.com's SSP has exposed an inconsistency in the signature, then
it can eliminate the JUNK with no HARM done and with 0% FALSE POSITIVES.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: [email-masked] (Wietse Venema)
Date: Sat, 9 Sep 2006 14:10:39 -0400 (EDT)

> is in finding some that are definitely bad.

Criminals switch strategy, and use look-alike domains to make their
mail look even more authentic than it does today.

If this is how SSP stops phishing mail, we have achieved nothing.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Sat, 09 Sep 2006 11:12:46 -0700

On Sat, 2006-09-09 at 12:35 -0400, Scott Kitterman wrote:
> > They key point, to me, is that a signature by the rfc2822.From
> > domain is likely to help control against some existing types of
> > phishing, but it clearly will not help against others.
>
> > Worse, we have no empirical data about what is or is not effective,
> > in helping end-users to detect phishing.  So, to the extent that
> > end-users figure into anyone's expectations about DKIM's benefits
> > against phishing, we are flying quite blind.

This is _not_ an accurate statement.  While treating DKIM base in
isolation may expedite its completion, ignoring how policy relates to
the employment of this mechanism minimizes vital protections needed in
the face of a growing threat.  Effective strategies have been
demonstrated.

> statements are published offer a mechanism for this.  From my
> perspective, the utility of DKIM as it relates to end-users is, I
> agree, quite uncertain.

A blocking strategy is reactive, and not proactive.  Blocking is
unlikely to keep pace and be effective against a highly dynamic phishing
problem.  Blocking should not be considered a primary method of
protection.

> Agreed.  Is anyone doing this?

DKIM used in isolation will be ineffective at defeating phishing.
Anyone who thinks DKIM + Policy defeats phishing is also confused. 

For DKIM to be effective against phishing, DKIM MUST be used in
conjunction with a list of recognized email-addresses.

These email-addresses could be in the form of a trusted domain-list with
some out-of-band offering of local-part components, or some method of
publishing this local-part information.  These email-addresses can also
be gleaned from the recipient's address-book as well.  It is common
place to use the address-book to enable message related components or
features.

DKIM provides a means for making "safe" associations with retained
email-addresses and those seen within a message.

 - The signing domain MUST be associated with the email-address.

 - The signing domain MUST indicate that the email-address is valid.

When a retained email-address association has been discovered between an
assured email-address, the message can receive annotations making this
association apparent to the recipient.  These annotations do not require
the recipient to visually recognize the email-address.  Safe placement
into the address-book can be established by using pass-phrases and an
out-of-band method of communication, such as a web page.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 9 Sep 2006 14:27:13 -0400

On Saturday 09 September 2006 14:10, Wietse Venema wrote:
> > assert anything about the goodness of a message.  I think it's only
> > utility is in finding some that are definitely bad.
>
I agree they will switch strategies when one stops working.

I also agree that they will continue to evolve the content to make them look 
more authentic than they do today.

It seems to me you may be saying that a look-alike domain can be made to look 
more authentic than the actual domain.  Is that right?  If so, I'd like to 
understand that.

> If this is how SSP stops phishing mail, we have achieved nothing.
I wouldn't call it nothing, but I guess that's a matter of opinion.  I don't 
know what else it could accomplish.

I would call forcing phishers to switch from exact domains to look-alikes 
progress.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Sat, 09 Sep 2006 11:33:25 -0700

Dave Crocker wrote:

> They key point, to me, is that a signature by the rfc2822.From domain 
> is likely to help control against some existing types of phishing, but 
> it clearly will not help against others.
>
> helping end-users to detect phishing.  So, to the extent that 

This is where Dave Oran's Preparation H disclaimer comes into effect: 
Preparation
H doesn't cure, it helps. On the other hand, saying that SSP vs. 
first-party signatures
being "dangerous" vastly overstates the risks -- just because something 
doesn't provide
a complete solution means that it's as dangerous as however you're 
misusing it.

          Mike

---

From: John Levine <[email-masked]>
Date: 9 Sep 2006 18:35:49 -0000

>A bad thing.  Don't put the gold star on it.  That would be a mistake.

I think we all agree it would be a mistake.

How does DKIM-SSP help us not to put the gold star on it?  Someone
said that DKIM-SSP offers a mechanism to not accept phishing messages
for delivery.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 09 Sep 2006 11:40:40 -0700

Michael Thomas wrote:
>> Therefore, to the extent that anyone touts a DKIM-based mechanism
>> as defeating phishing, we run the risk of undermining all of DKIM's
>  Preparation H doesn't cure, it helps. On the other hand, saying that
> SSP vs. first-party signatures being "dangerous" vastly overstates
> the risks -- just because something doesn't provide a complete
> solution means that it's as dangerous as however you're misusing it.

Lest anyone read Michaels note as countering my concern, I'll stress 
that it doesn't.

My comment was not that it is bad to have partial solutions, but that it 
is bad to set expectations inappropriately and that the discussion on 
this list suggests that we are at serious risk of promoting DKIM as an 
anti-phishing "solution" inappropriately.

d/
-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 9 Sep 2006 14:41:30 -0400

> said that DKIM-SSP offers a mechanism to not accept phishing messages

For exact domain phishes, I think this is true.

If I get a message 2822.From a domain that has published an SSP record saying 
that the domain signs all messages and the message does not have a valid 
signature signed by that domain, then the message can be rejected.

Unless you are in the habit of putting gold stars on all messages that go into 
the inbox, then you don't need any help to not put a gold star on it.  The 
part where you normally don't put a gold star on it, do that.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Sat, 9 Sep 2006 11:35:19 -0700

> A bad thing.  Don't put the gold star on it.  That would be a mistake.

That's right.

And, _within the framework we're discussing here_, it's equally
true for mail from any other domain.

I think that that quite strongly demonstrates that discussing
phishing and SSP at the same time is pretty pointless, as SSP
is all about self-declaration, and people who send phish emails
tend not to tell the truth.

Any value DKIM has w.r.t. phishing is to provide a strong proof
of the identity of the sender, allowing some external third
party to verify that it's really a bank / D&B certified business /
registrar / or what have you.

Cheers,
   Steve

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 9 Sep 2006 14:50:01 -0400

----- Original Message -----
From: "Scott Kitterman" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, September 09, 2006 2:27 PM
Subject: Re: [ietf-dkim] SSP = FAILURE DETECTION

> I would call forcing phishers to switch from
> exact domains to look-alikes progress.

+1.

SSP as a signature policy failure detection concept, it will offer an
optimal migration path with backward compatibility with a high payoff
compared to a non-SSP DKIM-base only environment where there is no incentive
for bad-actors to adapt or change their current ways.

When there is no incentive to adapt, the receiver market is left in limbo
with little to no benefits in checking for DKIM-BASE mail.

My proposal is a natural consideration for a SMTP vendor in how to best
implement DKIM-BASE with SSP to offer protection for DKIM while still
supporting legacy systems.

A receiver can only find out if a sender is a LEGACY system or a new DKIM
based system by checking for domain signing attributes.

Its a YES or NO question.

   NO  - Legacy Operations
   YES - Non-Legacy DKIM operations

This is why I say in a DKIM-BASE only environment, the #1 loophole is for
bad actors to do nothing, simply because SMTP systems MUST still support
legacy operations.

So if we want to protect against this Legacy vs. Non-Legacy loophole, we
need a way to check for the domain status and it has to be based on the
minimum x822 header requirements. In this case, it is the x822.From header.

So SSP at the very least has to be about closing the "loopholes" that
DKIM-BASE promotes.

Anything beyond that it can not do.  It will not stop phishers and it will
not stop the compliant DKIM bad guy.

But as you say, if we move them in the direction of using DKIM or moving
away from direct exploitation of domains, then that is indeed progress.

Once we close these deterministic loopholes, then the content related
HEURISTIC systems become themselves more powerful.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 09 Sep 2006 12:02:10 -0700

> said that DKIM-SSP offers a mechanism to not accept phishing messages

I agree.  A policy of any form will be unable to reliably block phishing
messages or identify what messages should be annotated in isolation of
other information.  However, DKIM related information can be applied
beyond the MTA.  Think outside the MTA box. : )

Blocking a phish should not be a primary goal, although that might be
all an MTA offers.  Validating and annotating associated "retained
email-addresses" is something DKIM enables.  There are two forms of
retention in current use, a trusted list and an address-book.  These
retained email-addresses allow safe "gold-star" annotations to be
applied in conjunction with DKIM.  Policy allows DKIM to more broadly
validate "retained email-addresses."

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 9 Sep 2006 15:08:33 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "Michael Thomas" <[email-masked]>

> My comment was not that it is bad to have partial solutions,
> but that it is bad to set expectations inappropriately and
> that the discussion on  this list suggests that we are at
> serious risk of promoting DKIM as an anti-phishing
> "solution" inappropriately.

Just so you know, no one, atleast not me, has said that SSP or DKIM-BASE
itself will protect against near-domain style spoofing A.K.A phishing.  So
it be a mistake to believe this is what being advocated.  No. Absolutely
not.  I could be wrong, but I think it is only Mr. Otis talking about
phishing and I think he is promoting something different and beyond from
DKIM-BASE and SSP as it is currently drafted, depending on MUA "Address
Books" etc.

That's beyond DKIM-BASE and SSP considerations in my "book."

---

From: John Levine <[email-masked]>
Date: 9 Sep 2006 19:12:34 -0000

>It seems to me you may be saying that a look-alike domain can be made
>to look more authentic than the actual domain.  Is that right?  If
>so, I'd like to understand that.

It doesn't have to look more authentic.  It only has to look as
authentic.  With SSP, everyone can publish equally authentic "PHISH
TARGET" notices.

>I would call forcing phishers to switch from exact domains to
>look-alikes progress.

Well, OK.  Here's a small selection from a recent .COM zone file.
Let's pretend they all just sent you mail, and they all have valid
signatures and the most draconian SSP.  Which one is really Paypal?
(One of them is.)

Claims that SSP is a meaningful anti-phishing tool are nuts.

MYPAYPAL.COM
PAYPALSHOPS.COM
PAYPALSTORES.COM
PAYPALCARDSERVICES.COM
PAYPALMC.COM
PAYPALVISA.COM
PAYPALVERIFY.COM
SECURITY-PAYPAL.COM
PAYPALSTORE.COM
PAYPALSYS.COM
PAYPALMAIL.COM
SECURITIES-PAYPAL.COM
PAYPAL-EBAY.COM
PAYPALESCROW.COM
SECUREDPAYPAL.COM
PAYPALSERVICE.COM
WWW--PAYPAL.COM
PAYPALESHOP.COM
PAYPAL-SIGN-IN.COM
PAYPAL-VERIFYD.COM
PAYPALEMAIL.COM
PAYPAL-DATABASE.COM
PAYPAL-REDIRECT.COM
PAYPAL-BILLING.COM
PAYPALCOM.COM
PAYPALINC.COM
PAYPAL-MEMBERS.COM
PAYPAL-MEMBER.COM
WWWWPAYPAL.COM
PAYPAL-VERIFIC.COM
PAYPALMONITOR.COM
SECURITY-MEASURES-PAYPAL.COM
PAYPAL-SECURE-UPDATES.COM
PAYPALPURCHASE.COM
RELOGIN-PAYPAL.COM
WWWPAYPALL.COM
PAYPAL-VERIFICATION-SYSTEM.COM
PAYPALCODE.COM
PAYPAL-SECURED-UPDATE.COM
PAYPAL-SERVICE.COM
PAYPAL-SECURE-INFO.COM
PAYPAL-VERIFICATION-MEMBERS.COM
CUSTOMER-PAYPAL.COM
USERS-PAYPAL.COM
CGI5-PAYPAL-VERIFYUSER.COM
PAYPAL-DBS.COM
ACCOUNTS-PAYPAL.COM
VERIFY-PAYPAL-ACCOUNT.COM
BILLINGUPDATEPAYPAL.COM
SSLSERVER-PAYPAL.COM
PAYPAL-HOME.COM
INFOUPDATE-PAYPAL.COM
PAYPAL-COM.COM
PAYPALSECURITY.COM
UPDATED-PAYPAL.COM
CLIENTS-PAYPAL.COM
REACTIVATE-PAYPAL.COM
SECURIZED-CGI-PAYPAL.COM
PAYPALSUPPORT.COM
EBAYPAYPAL.COM
PAYPALUPD.COM
PAYPAL-UPDATE-VERIFY.COM
WWW-PAYPAL.COM
EXPIRE-PAYPAL.COM
RE-PAYPAL.COM
WWW-PAYPAL-COM-LOGIN-CGI-WEBSCR-CMD-LOGIN-RUN.COM
PAYPAL-CGI.COM
SECURE-PAYPAL-LOGIN.COM
UPDATE-YOUR-PAYPAL-ACCOUNT.COM
PAYPAL-INFORMATION-UPDATE.COM
SUSPENDED-PAYPAL.COM
PAYPAL-UPDATE-INFO.COM
UPDATE-PAYPAL-INFORMATION.COM
PAYPAL-UPDATE-INFORMATION.COM
UPDATE-YOUR-PAYPAL-ACCOUNT.COM
UPDATE-YOUR-PAYPAL.COM
PAYPAL-ACCOUNT-UPDATE.COM
PAYPAL-CONTROL.COM
PAYPAL-UPDATE-YOUR-INFO.COM
PAYPALINSURANCE.COM
USERS-UPDATES-PAYPAL.COM
SERCURE-PAYPAL.COM
PAYPAL-INFOUP.COM
SAFE-PAYPAL.COM
PAYPALREPORT.COM
VERIFYBILLING-PAYPAL.COM
PAYPALACCOUNTSERVICE.COM
PAYPAL-CREDITCARD.COM
VERIFYBILLING-PAYPAL.COM
PAYPALACCOUNTSERVICE.COM
SUPPORTS-PAYPAL.COM
PAYPALBILLING.COM
PAYPALACCOUNTSERVICES.COM
PAYPALCUSTOMERCARE.COM
US-PAYPAL.COM
PAYPAL-UPGRADE.COM
PAYPAL-SSL.COM
PAYPAL-EUROPE.COM
ALERTS-PAYPAL.COM
PAYPAL-ONLINEINFO.COM
CGI-PAYPAL-UPDATE.COM
SSL-PAYPAL.COM
PAYPAL-CONFIRMINFO.COM
PAYPALNEWUPDATE.COM
PAYPAL-CGI-UPDATE.COM
PAYPAL-CGI-BIN.COM
RESTORE-PAYPAL-ACCOUNTS.COM
CUSTOMER-UPDATE-PAYPAL.COM
PAYPAL1.COM
PAYPAL-CUSTOMER-CENTER.COM
PAYPAL-ACCOUNT-UPDATES.COM
PAYPAL-SM.COM
SERVICE-ACCOUNT-PAYPAL.COM
PAYPAL-ONLINECONFIRM.COM
PAYPAL-INFOCONFIRM.COM
PAYPAL-VALIDATEINFO.COM
PAYPAL-INFO-UPDATE.COM
INFO-PAYPAL-UPDATE.COM
CGI-UPDATE-PAYPAL-ACCOUNT.COM
PAYPAL-SECUREINFOS.COM
PAYPAL-CGI-BIN-SECURE.COM
SECURE-PAYPAL-CGI-URL.COM
PAYPALAUSTRALIA.COM
PAYPAL-INTL-SERVICE.COM
ACCOUNTUPDATE-PAYPAL.COM
PAYPALNEWUPDATES.COM
EMAIL-PAYPAL.COM
PAYPAL-ORGANIZATION.COM
PAYPAL-CUSTOMER-CENTRE.COM
EBAY-AUCTION-PAYPAL.COM
EMAILPENDING-PAYPAL.COM
PAYPALSERVIICE.COM
SSLCONNECTION-PAYPAL.COM
E-PAYPAL.COM
PAYPAL-ACOUNT-CENTER.COM
PAYPAL-UPDATE-CENTER.COM
PAYPALCUSTOMERSERVICES.COM
PAYPALSECUREDPAYMENT.COM
CGI-INFO-PAYPAL.COM
PAYPAL-CLIENT-SUPPORT.COM
CONFIRM-PAYPAL-ACCOUNTS.COM
PAYPAL-INFOVALIDATE.COM
RESTORE-PAYPAL-INFO.COM
CS-PAYPAL.COM
IMG-PAYPAL.COM
PAYPAL-COM-CGI-BIN-CONFIRMATION-PP545454.COM
SIGNIN-ACCOUNT-PAYPAL.COM
PAYPAL-MEMBERS-VALIDATION.COM
PAYPAL-SECURE-UPDATE.COM
PAYPAL-ACCOUNT-SERVICE.COM
UNLOCK-PAYPAL.COM
EMAILS-PAYPAL.COM
PAYPAL-SUBMIT.COM
PAYPAL-SECURITY-SYSTEM.COM
UPDATE-PAYPAL-SYSTEM.COM
CONFIRM-PAYPAL.COM
PAYPAL-SETUP.COM
PAYPAL-SECURITY-UPDATES.COM
ONLINE-PAYPAL-UPDATE.COM
US-PAYPAL-SUPPORT.COM
PAYPAL-SUPPORT-SSL.COM
PAYPAL-PAYMENTS.COM
PAYPAL-SERVERS.COM
PAYPAL3.COM
PAYPAL-LOGIN.COM
VERIFY-PAYPAL-US.COM
VERY-PAYPAL.COM
RESUBMIT-PAYPAL.COM
UPDATEUSER-PAYPAL.COM

R's,
John

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 9 Sep 2006 15:23:07 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "John Levine" <[email-masked]>

> I agree.  A policy of any form will be unable to
> reliably block phishing messages or identify what
> messages should be annotated in isolation of other
> information.  However, DKIM related information can be
> applied beyond the MTA.  Think outside the MTA box. : )

Doug, its hard to follow you, so if I am wrong, I apologize but I think I
think you need to stop saying DKIM-BASE or SSP can help with anti-phishing.
It can not and AFAIK no one on the either side of the SSP camp believes that
is the case.

I believe you are promoting a MUA solution and you doing so from an
application standpoint when in fact the DKIM-BASE and SSP discussions are
pretty much focused on the MTA level (or server side).

But then again, maybe this is part of the problem:

 - MTA DKIM promoters (SMTP vendors, Admins)
 - MUA DKIM promoters (MUA authors, plug-ins, DMA)

These are TWO conflictive solutions.  Keep in mind we have both MTA and MUA
products so my technical engineering is purely based on whats the most
effective and feasible solution.  Centralizing the mail operaton will no
doubt provide the most benefits.

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 9 Sep 2006 15:28:32 -0400

----- Original Message -----
From: "John Levine" <[email-masked]>
Sent: Saturday, September 09, 2006 3:12 PM
Subject: Re: [ietf-dkim] SSP = FAILURE

> Claims that SSP is a meaningful anti-phishing tool

No one saying it is.  Maybe Doug is, but I believe he is promoting something
beyond DKIM-BASE and SSP with a MUA solution.  Maybe Doug should clarify
that.

But thats not SSP.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 9 Sep 2006 15:39:28 -0400

> authentic.  With SSP, everyone can publish equally authentic "PHISH
I don't recall seeing anything about PHISH TARGET notices in Mike's 
requirements draft, so I think you are arguing that the SSP you are arguing 
against is a different one than the WG is working on.

> signatures and the most draconian SSP.  Which one is really Paypal?

None of them are Paypal domains that have sent messages to me.  I have no 
idea.  I don't think I'd trust any of them (even if one is real, I'd be 
suspicious).  This is, however, irrelevant.  

The point is that none of them are paypal.com.  I think it was PHB that said 
that the advice being given for the last several years to financial 
institutions was to use their main domain name for their transactional mail.  
> Claims that SSP is a meaningful anti-phishing tool are nuts.

I imagine it all revolves around the significance one places on blocking exact 
domain forgery/phishes.  If you don't think that's meaningful, then sure.

I think it's meaningful.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Sat, 09 Sep 2006 12:55:44 -0700

> authentic.  With SSP, everyone can publish equally authentic "PHISH

The list discussion seems to be spending an awful lot of time on issues 
that are theoretical, poorly understand, and lacking in a clear 
community consensus that we need a solution.

How is this productive?

d/
-- 

   Dave Crocker

---

From: Jeff Macdonald <[email-masked]>
Date: Sat, 9 Sep 2006 17:31:50 -0400

> community consensus that we need a solution.

While I agree with this observation, I find the discussion very
educational.

-- 
:: 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: "william(at)elan.net" <[email-masked]>
Date: Sat, 9 Sep 2006 14:40:20 -0700 (PDT)

On Sat, 9 Sep 2006, Dave Crocker wrote:

> The list discussion seems to be spending an awful lot of time on issues that 
> are theoretical, poorly understand, and lacking in a clear community 
> consensus that we need a solution.
>
> How is this productive?

Your own message is perfect example of unproductive messages on this list.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Sat, 9 Sep 2006 15:19:12 -0700

On Sep 9, 2006, at 12:23 PM, Hector Santos wrote:

>> I agree.  A policy of any form will be unable to reliably block  
>> phishing messages or identify what messages should be annotated in  
>> isolation of other information.  However, DKIM related information  
>> can be applied beyond the MTA.  Think outside the MTA box. : )
>
> Doug, its hard to follow you, so if I am wrong, I apologize but I  
> think I think you need to stop saying DKIM-BASE or SSP can help  
> with anti-phishing.  It can not and AFAIK no one on the either side  
> of the SSP camp believes that is the case.

There should be serious doubts regarding the entirety of _any_  
domain's email as being trustworthy.  There should be serious doubts  
about blocking messages based upon policy as a means to prevent  
spoofing.  However...

Annotation selectivity can be achieved by recipients retaining  
"specific" email-addresses found within the address-book, and by a  
list of trusted-domains and "specific" local-part addresses.  A  
trusted-domain list that combines with "specific" local-part  
addresses can be used safely in conjunction with an MTA or MUA  
annotation scheme.  Few domains will desire the entirety of their  
email annotated as trustworthy, even when specific messages are  
trustworthy.  Solving this concern is where policy should play a  
critical role in facilitating selective annotations.  Annotations are  
effective at improving open rates of valid messages and preventing  
recipients from mistaking the source of illegitimate messages.  This  
is _not_ theory.

> application standpoint when in fact the DKIM-BASE and SSP  
> discussions are pretty much focused on the MTA level (or server side).

There is no reason to focus upon only one aspect of how DKIM offers  
protection.  The use of trusted-domain list annotations can be  
applied at either the MUA or the MTA.  Annotations at the user agent  
can be more uniform and offer a consistent user experience regardless  
which MTA provided the message.  When done at the user agent the  
address-book is also readily available.

> These are TWO conflictive solutions.  Keep in mind we have both MTA  
> and MUA products so my technical engineering is purely based on  
> whats the most effective and feasible solution.  Centralizing the  
> mail operation will no doubt provide the most benefits.

The best solution to combat phishing encompasses both the MTA and the  
user message application.  These are not in conflict unless someone  
goes overboard on message blocking and disrupts email-delivery.  The  
best place for applying the DKIM signature appears to be at the MTA;  
the best place to apply DKIM related annotation that associates a  
retained and validated email-address is at the MUA.  When annotations  
are based upon the address-book, no external services are required  
which you should find pleasing.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 9 Sep 2006 19:05:34 -0400

Doug,

Not everyone will be able to produce a cross the board solution.  Only the
"Microsofts" and the likes will have the capacity to address a consistent
solution across their applications.   Although we are a small company with
one of the oldest and most complete total mail design frameworks in the
market, even I realize we can't do that.  We can make it work for us in an
integrated fashion, but we can't dictate our TOTAL solution will be the
right TOTAL solution for everyone else.  Its unrealistic and it would be
unrealistic for others here who might feel their total solution is right for
us as well.

But what is common with all of us, is the MTA or more specifically x822/x821
internet mail operations.  Reading mail, while there is are standards on the
OFFLINE side with popular methods (POP3, IMAP), there are a multiple MAIL
ACCESS methods which you can't control, online, proprietary, API based,
gateways, etc.

For example, using us, we have the following mail access methods all
controlled using a single source backend system:

    - Console mode (Dialup, Telnet)
    - Browser (WebMail)
    - Online GUI Navigator
    - XML/SOAP API
    - POP3 Email
    - News
    - Sysop Editor (GUI)
    - Reports Manager

And a bunch of 3rd party mail readers.   It would be a mistaken to believe
that x822 is the common format between all of them (for the internet
clients, yes) but not necessary the rest.

The buck really stops at the server side if we really want this to work. A
centralize source.  Your nor my MUA needs should not stop the progress with
implementing DKIM-BASE/SSP solutions at the MTA.

In my opinion, if you have a MUA application in mind, you should concentrate
on how it will communicate with the server side.   I would first concentrate
on reading any results that the MTA produces.  If you intend to sign at the
MUA, then you need to make sure the MSA understands what you are doing too
because if you don't, you can find it overwritten, destroyed or even
removed.

Thanks my opinion.

---

From: [email-masked] (Wietse Venema)
Date: Sat, 9 Sep 2006 19:16:30 -0400 (EDT)

Hector Santos:
> itself will protect against near-domain style spoofing A.K.A phishing.

Actually, the discussion has demonstrated that SSP can't detect
look-alike phishing, while DKIM-BASE can.

This involves a list of trusted DKIM-BASE signing domains (*).
Given this list, potential look-alike or exact-name phishing attempts
stand out because their signing domain isn't in the trusted list.

That list could be recipient maintained (a bit like the way SSH
asks for permission when it encounters an unknown hostkey).  Or it
could be maintained externally.

I think that a list of trusted DKIM-BASE signing domains can go a
long way towards the elimination of look-alike and exact-name
forgeries.

	Wietse

(*) Doug Otis wants to maintain more attributes, but these are for
    features beyond the detection of unknown signing domains.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Sat, 09 Sep 2006 17:55:00 -0700

On Sat, 2006-09-09 at 19:05 -0400, Hector Santos wrote:
> solution across their applications.

Browser and MUAs are extensible in a manner similar to MTAs.  One does
not need to design an entire application to add a feature.

> Although we are a small company with one of the oldest and most
> complete total mail design frameworks in the market, even I realize we
> can't do that.

Your company does not need to do anything for these extensions to be
available.

> We can make it work for us in an integrated fashion, but we can't
> dictate our TOTAL solution will be the right TOTAL solution for
> everyone else.  Its unrealistic and it would be unrealistic for others
> here who might feel their total solution is right for us as well.

Annotating a message at the presentation layer will not make physical
changes to the message.  This approach will not impact applications in
current use.

> But what is common with all of us, is the MTA or more specifically
> x822/x821 internet mail operations.  Reading mail, while there is are
> standards on the OFFLINE side with popular methods (POP3, IMAP), there
> are a multiple MAIL ACCESS methods which you can't control, online,
> proprietary, API based, gateways, etc.

POP3, IMAP, and various web mail presentations are extended in the
manner suggested.

> controlled using a single source backend system:

These other modes of reading email will not likely warrant being
extended initially, although scripts can often be invoked that are able
to apply the algorithm suggested.  If the features becomes popular,
someone may bake them into less popular interfaces.

> clients, yes) but not necessary the rest.

Covering IMAP, POP3, and web mail presentations offers protection for a
a high percentage of users.

> implementing DKIM-BASE/SSP solutions at the MTA.

Conversely, efforts at the MTA should not jeopardize the integrity of
email delivery.  Don't break the signature.  Ensure a false positive
rate does not increase.

A highly selective policy at the MTA should be okay.  Overly broad and
aggressive policies will likely cause a problem.

> In my opinion, if you have a MUA application in mind, you should
> concentrate on how it will communicate with the server side.

The interface at the server and the message does not change.

Only email-addresses that are retained and assured valid by DKIM can
offer safe annotations.  Exploring policies that increase the coverage
of DKIM's validations, and that offer increased selectivity is where the
WG should be focused.  Providing greater coverage with less
administration will improve the DKIM user experience and better support
its deployment.

And yes, DKIM in conjunction with these other efforts can substantially
prevent phishing.  Just don't try to do this with blocking alone.  My
worry is that John might be right and no blocking should be attempted.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 9 Sep 2006 21:27:24 -0400

> look-alike phishing, while DKIM-BASE can.

Not without getting beyond the scope of the WG charter.  DKIM-BASE certainly 
gives a more reliable name basis for name based reputation and accept/reject 
decisions.  It does not, however, provide a complete mechanism for doing so 
on it's own.

Another question I would have is how a message from a sender on the trusted 
list that was received without a valid signature would be treated.  Without 
SSP to determine is the domain signs all mail, it would seem problematic to 
either accept or reject such messages.  It may be that SKIM-SSP would 
complement such efforts.
> stand out because their signing domain isn't in the trusted list.
Agreed, but this list is outside the scope of what I understand the WG was 
chartered to do.

> long way towards the elimination of look-alike and exact-name

Agreed, but that requires additional mechanism beyond what we are chartered to 
do.  I'd be interested to know if someone was working on an open solution to 
this part of the problem.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Sat, 09 Sep 2006 19:15:09 -0700

On Sat, 2006-09-09 at 21:27 -0400, Scott Kitterman wrote:
> Not without getting beyond the scope of the WG charter.  DKIM-BASE
> certainly gives a more reliable name basis for name based reputation
> and accept/reject decisions.  It does not, however, provide a complete
> mechanism for doing so on it's own.

,---
| The DKIM working group will produce standards-track specifications 
| that allow a domain to take responsibility, using digital signatures,
| for having taken part in the transmission of an email message and to 
| publish "policy" information about how it applies those signatures. 
| Taken together, these will assist receiving domains in detecting (or 
| ruling out) certain forms of spoofing as it pertains to the signing 
| domain.
'__

Providing policy information to associate email-addresses with a signing
domain for the purpose of ruling out spoofing seems well within the DKIM
WG charter.

> Another question I would have is how a message from a sender on the
> trusted list that was received without a valid signature would be
> treated.  Without SSP to determine is the domain signs all mail, it
> would seem problematic to either accept or reject such messages.  It
> may be that SKIM-SSP would complement such efforts.

When using an annotation approach, validated email-address are normally
annotated based upon an association with a list or retained
email-addresses. Messages that are not signed or assured valid in some
manner do not receive annotations.  The recipient may still have
phishing attempts appear in their inbox, but they are easily
distinguished by lacking the expected annotation.

While the details of this annotation scheme are beyond the scope of the
WG, the critical aspect is just the normal association and assurances
offered by DKIM.  This information is leveraged by these external
schemes into offer substantial protections.

> Agreed, but this list is outside the scope of what I understand the WG was 

Focus only upon offering validated email-addresses and how policy can
extend this capability of DKIM.  DKIM already can associate a valid
email-address with that of the signature through the i= syntax and the
d= domain.  Policy can extend associations to broaden the coverage being
offered.

Ignore details related to email-address retention and annotation.  One
only needs to assume that such annotation is possible at this point.

> Agreed, but that requires additional mechanism beyond what we are
> chartered to do.  I'd be interested to know if someone was working on
> an open solution to this part of the problem.

There is ongoing work. Is there interest in a different WG to cover this
effort?  I suspect most will see this as being too soon.

-Doug

---

From: "Thomas A. Fine" <[email-masked]>
Date: Mon, 11 Sep 2006 11:04:22 -0400 (EDT)

>If this is how SSP stops phishing mail, we have achieved nothing.

I can NOT stop burglaries, but I still have locks on my doors.  But
SSP is BETTER than a lock:

Currently, I can receive mail that looks exactly like it is from
an organization that I do business with, and only through careful
inspection can I determine that something might be amiss.

With SSP, I can only receive mail that looks ALMOST like it is from one
of my orgs.  This is huge.  This gives the user layer the ability to
quickly, accurately, and precisely differentiate between fake and
real messages.  That's what SSP accomplishes.

As far as what happens in the user layer, no specification can control
that.  We can certainly predict that a significant number of people
will still fall for look-alike domains.  But this is vastly different
than people falling for the exact valid email address they were
expecting.  What are we here for if we aren't here to fix that?

	 tom

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Sep 2006 10:22:28 -0700

On Sep 11, 2006, at 8:04 AM, Thomas A. Fine wrote:

> With SSP, I can only receive mail that looks ALMOST like it is from  
> one of my orgs.  This is huge.  This gives the user layer the  
> ability to quickly, accurately, and precisely differentiate between  
> fake and real messages.  That's what SSP accomplishes.

When a strong email-address policy assertion that disrupts the use of  
common services might block exact spoofs.  SSP does not differentiate  
"real" messages.

> As far as what happens in the user layer, no specification can  
> control that.  We can certainly predict that a significant number  
> of people will still fall for look-alike domains.

An association with a retrained email-address will curtail look-alike  
attacks and clarify which messages are "real."  For this, the signing  
domain must offer an assurance that the email-address is valid as well.

> But this is vastly different than people falling for the exact  
> valid email address they were expecting.

Deploying just this mechanism will likely provide a minor impact upon  
the spoofing success rate.  It may however have a major impact upon  
the delivery rate of valid messages.

> What are we here for if we aren't here to fix that?

To offer a comprehensive solution that offers genuine protection  
without impairing email delivery.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Mon, 11 Sep 2006 14:12:56 -0400 (EDT)

> SSP is BETTER than a lock:

I you knew my work then you would know better than to picture me
as an "it's not perfect therefore it's worthless" zealot.

DKIM-base can help to give good sites an edge over look-alike
domains (with a trusted signing domain list, possibly maintained
like an ssh trusted fingerprint list).

I see no such advantage with SSP.

	Wietse

---

From: Damon <[email-masked]>
Date: Mon, 11 Sep 2006 14:13:34 -0400

> without impairing email delivery.

My father used to tell me that locks were to keep honest people honest
and give those that wish to get through a dickens of a time doing it.
A lock will not ever stop someone who is determined to get through it.
In this case, I believe that it will give those that want to get
through SSP a whole new set of locks to bypass. There are only so many
look-alike domains compared to as it is now, being able to come from
anywhere. If we were able to just focus on look-alike's (as an admin)
it would make things a lot simpler. I believe that we ARE trying to
offer a comprehensive solution and outlined in exacting detail on just
how we are going to do it... which is a lot better than someone
suggesting Nirvana and no clear idea as to what someone means when
they suggest another comprehensive solution that offers genuine
protection without impairing email delivery.

Regards,
Damon Sauer

---

From: "Thomas A. Fine" <[email-masked]>
Date: Mon, 11 Sep 2006 14:26:57 -0400 (EDT)

>I see no such advantage with SSP.

With only DKIM-base, and MDA will present unsigned, forged mail from
bigbank.com to the end user, and it will hope that the user notices
BOTH that the message is not signed, AND that bigbank.com has in the
past signed things.  Users, being inherently unreliable, will sometimes
get fooled.

With DKIM/SSP, the MDA will prevent the mail from being delivered to
the user.  Users will never get fooled.

See the advantage now?

        tom

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 11 Sep 2006 14:35:13 -0400

Thomas,

The draft specifications, the official SSP-02, and the additional WG
document, DSAP-00,  look at this as a way to verify consistency in the
signing process.  It is more like a "permit" or signature authorization
concept than anything else.

I have been researching all this from an product implementation design
feasibility standpoint.

Original Signing:

 - Why should add DKIM signing support to our product?
 - What is it going to offer customers?
 - How do we sell (document) it to them so that they use it?
 - Which groups of customers need it? How so?
 - Where do we add it to our framework?
 - How does it work with our add-on products, i.e, List Server?

Verification:

 - Where do we do the verification? Transport or post reception?
 - How does it integrate with existing email protection technology?
 - How does it tie in to existing authorization submissions?
 - What is the payoff?  Success vs. Failures?
 - What are the loopholes?

Resigning or 3rd party signing:

 - What are the reasons for resigning?
 - How does resigning effect the traditional "Do not alter" passthrus?
 - How does resigning effect the original signing?
 - How does resigning effect verification process?
 - What are the loopholes?

Etc, etc.

As much as I like DKIM with its promising proof of concept, I am not
convince its promotion has been handled correctly and it risk being damaged
and not widely adopted by incorrectly selling the idea its a transparent
Digital Message Signature (DMS) protocol "passthru" concept with vague ideas
about assigning responsibility and accountability but short on who IS
suppose to interpret these responsibility and accountability ideas, from
signer, to verifier to middle ware processes as well.

SSP to me is very simple:

At a minimum it is about confirming the physical attributes of a domain
message with or without a DMS.  It is about the detecting the MOST obvious
of failures.

To me, that is the BEST we can do today.

Neither SSP and DKIM-BASE can address

  - near-domain phishing
  - Compliant Bad Actors

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Sep 2006 11:47:41 -0700

On Sep 11, 2006, at 11:13 AM, Damon wrote:

> There are only so many look-alike domains compared to as it is now,  
> being able to come from anywhere. If we were able to just focus on  
> look-alike's (as an admin) it would make things a lot simpler.

John Levine offered a fairly representative sample of what a phish  
domain looks like.

http://mipassoc.org/pipermail/ietf-dkim/2006q3/005884.html

These attempts are slippery where a recipient is truly unable to know  
what is real by careful examination of the domain name.  This also  
enters into the era where the browsers and clients default with  
translated punycode found in ACE labels.

If you are using Firefox, check the setting at about:config URL for  
network.IDN_show_punycode.  When this is set to the default false,  
the browser displays a translation rather than punycode.  Showing  
either offers limited protection from all forms of look-alike  
attack.  Internet naming is not limited to just ASCII.

There aren't only so many look-alikes.  The list of look-alikes is  
virtually unlimited.  Protection requires a list of trusted domains  
be retained for comparison.  There is no need for SSP to indicate  
that all messages are signed for this comprehensive protection  
through comparison to be available to the recipient.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Sep 2006 20:04:51 +0100

Hector Santos wrote:
> Thomas,
> 
> The draft specifications, the official SSP-02, 

Just a quick clarification: Jim's ssp-02 is not now an official
anything. We are still working ssp requirements and having been
through this extended discussion, I expect us to be in a position
to work through those very quickly. Having done that, the WG will
presumably choose one of the current proposals to develop, or
choose to merge some aspects of some of them, or whatever, and at
that point (in a month or two) we will have an "official" WG ssp
draft.

That's not to disparage Jim's ssp-02 at all, its just stating
where we're at,

Cheers,
S.

---

From: [email-masked] (Wietse Venema)
Date: Tue, 12 Sep 2006 05:17:35 -0400 (EDT)

> the user.  Users will never get fooled.

What was the advantage of SSP with look-alike domains?

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 Sep 2006 06:58:05 -0700

>What was the advantage of SSP with look-alike domains?
To find large unproductive ratholes?  Neither DKIM or SSP claim to have
any direct effect on look-alike domain names, and there's nothing in our
charter that says that we'll be doing anything about that ever. DKIM/SSP
are two pieces for a much larger set of things that need to come together
to combat phishing including software layered on top of thse base 
authentication
mechanisms, user base training/human factors, and law enforcement -- most of
which will not have any IETF involvement at all. No amount of hand-wringing
here is likely to tell us how this will ultimately play out.

       Mike

---

From: Damon <[email-masked]>
Date: Tue, 12 Sep 2006 10:23:10 -0400

> here is likely to tell us how this will ultimately play out.

+1

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Sep 2006 07:48:56 -0700

On Tue, 2006-09-12 at 06:58 -0700, Michael Thomas wrote:
> To find large unproductive ratholes?

What is more important?  While DKIM base and any policy alone will not
successfully combat phishing (if at all), this does not mean the WG
should not consider what is required to combat this threat, if only to
support an effective layered approach.

> Neither DKIM or SSP claim to have any direct effect on look-alike
> domain names, and there's nothing in our charter that says that we'll
> be doing anything about that ever.

The charter does not rule out the WG from considering what elements
might be provided by DKIM to thwart this threat.  One simple assurance
is already provided in the i= semantics that the email-address is valid.
This is the first step along this road.  Hopefully this road does not
lead to a rathole.  It should not.  It must not.

> DKIM/SSP are two pieces for a much larger set of things that need to
> come together to combat phishing including software layered on top of
> thse base  authentication mechanisms, user base training/human
> factors, and law enforcement -- most of which will not have any IETF
> involvement at all. 

There are elements where the IETF can be most instrumental in providing
standardized strategies for dealing with this serious risk.  The last
Cisco sponsored Email Authentication Summit demonstrated effective
layered solutions.  There was even a discussion regarding what Cisco was
doing internally with DKIM. 

> No amount of hand-wringing here is likely to tell us how this will
> ultimately play out.

This does require hand-wringing in how this effort can be ultimately
administered effectively and what is needed for coordinated progress.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Tue, 12 Sep 2006 12:22:08 -0400 (EDT)

> any direct effect on look-alike domain names, and there's nothing in our

DKIM_BASE allows a recipient to distinguish mail from the bank from
look-alike mail that pretends to be from the bank.  That information
comes in the form of the signing domain.

SSP has an advantage when we assume that criminals are stupid enough
to keep sending forged mail. It has no advantage with look-alike
attacks. Guess what criminals will do.

	Wietse

---

From: "Thomas A. Fine" <[email-masked]>
Date: Tue, 12 Sep 2006 12:41:52 -0400 (EDT)

>attacks. Guess what criminals will do.

Without SSP, users have two opportunities for making mistakes in
verifying their mail.  They can fail to notice that it is unsigned,
or they can fail to notice that it is from a wrong domain.

With SSP, users only have to look for the wrong domain, because
they should never see the unsigned mail.

Maybe someone who's an expert in human factors can relate this to
statistical decrease in errors by the user.  My feeling is that
the less a user has to worry about, the more likely they are going
to successfully examine their message and determine it's origin.

       tom

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Sep 2006 09:51:03 -0700

On Sep 12, 2006, at 9:22 AM, Wietse Venema wrote:

>> To find large unproductive ratholes?  Neither DKIM or SSP claim to  
>> have any direct effect on look-alike domain names, and there's  
>> nothing in our
>
> look-alike mail that pretends to be from the bank.  That  
> information comes in the form of the signing domain.
>
> SSP has an advantage when we assume that criminals are stupid  
> enough to keep sending forged mail. It has no advantage with look- 
> alike attacks. Guess what criminals will do.

Agreed.

When distinguishing email from look-alikes and spoofs, it also helps  
to know whether the signing domain validated the email-address in  
some fashion, and whether the signing domain is associated with that  
email-address.  Both of these requisite answers for avoiding a spoof  
or look-alike can be assisted with policy.  This policy may reduce  
the administration needed to ensure the reliability in distinguishing  
valid email.  Attempts to use policy to block look-alikes is likely  
fruitless, and may cause a great amount of effort to be expended  
attempting to repair resulting damage.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 12 Sep 2006 12:54:56 -0400

----- Original Message -----
From: "Wietse Venema" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 12, 2006 12:22 PM
Subject: Re: [ietf-dkim] SSP = FAILURE DETECTION

>> To find large unproductive ratholes?  Neither DKIM or SSP claim
>> to have any direct effect on look-alike domain names, and
>> there's nothing in our
>

hmmmmmmmmm,  unless I didn't follow you right, I fail to see the distinction
or your point.

Scenario #1 - No Phishing in 2822.From,  Phishing in signing domain. NO SSP
defined.

  From: [email-masked]
  To: [email-masked]
  Subject: Your Account Info
  DKIM-Signature: d=paypa1.com; s=sept06;  <-- valid 3PS

Here, the 3PS is valid using a look-alike domain (character one is used
instead of el). The x822.From is really paypal.com and no SSP is defined.
The result in a NO SSP enviroment is a VALID message with the awful
possibility some stupid Presentatation software will say:

   * Good Signature from [email-masked] signed by
     paypa1.com

Scenario #2 - Phishing in 2822.From, Phishing in signing domain.

  From: [email-masked]
  To: [email-masked]
  Subject: Your Account Info
  DKIM-Signature: d=paypa1.com; s=sept06;  <-- valid 3PS

Here, the 3PS is valid using a look-alike domain (character one is used
instead of el).  The x822.From is also phished. The bad guy can have NO SSP
or a SSP with an designated allow list for paypa1.com

So I don't see the how it matters.

But I will say that if PAYPAL.COM (the real domain) used SSP in scenario #1,
then at the very least, the real domain is protected against a phished
signing domain when using SSP.  So to me, SSP still has the advantage over a
DKIM-BASE only environment.

SSP can protect against a PHISHED DKIM-BASE SIGNATURE.  A  slight
distinction over a phished 2822.From domain.  In short, the bad guy would
have to phish both domains  - the authors and the signing domain.

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 12 Sep 2006 13:15:45 -0400

Thomas,

I think what needs to be highlighted in that when it comes to phishing,  the
bad actor would have to phish both the policy domain (author) and signing
domain.

The bad guy can't use the real domain in either entity since both methods
will be able to detect an error.

However, in a DKIM-BASE only environment, since the mandate is to ignore all
signature failures as if the message was never signed, the bad guy doesn't
have to phish the signing domain. He can just target the apathetic "cry
wolf" systems that ignores errors.  This has a risk of getting thru to the
end user.

----- Original Message -----
From: "Thomas A. Fine" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 12, 2006 12:41 PM
Subject: Re: [ietf-dkim] SSP = FAILURE DETECTION

>> SSP has an advantage when we assume that criminals are
>> stupid enough to keep sending forged mail. It has no
>> advantage with look-alike attacks. Guess what criminals
>> will do.
>

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Sep 2006 10:21:17 -0700

> or they can fail to notice that it is from a wrong domain.

SSP that blocks unsigned messages still offers a large opportunity to  
get this wrong.  Phish commonly avoid using the exact domain to avoid  
being filtered.  You are assuming visual examination of a domain is a  
reliable, but it is not.  There are still too many being fooled to  
curtail this criminal activity.  The majority of users only see the  
Display name without additional clicks.  We are also entering an era  
where it is also likely that the character repertoire being used is  
unknown.

> they should never see the unsigned mail.

Unsigned email might be block unless the email-address domain wants  
access to common services, or wants reliable delivery, or the  
verifying domain does not block based upon this policy.  Will this  
blocking strategy lead to legal obligations of blocking these messages?

> statistical decrease in errors by the user.  My feeling is that the  
> less a user has to worry about, the more likely they are going to  
> successfully examine their message and determine it's origin.

Provide the user a strong trustworthy annotation that:
  a) the email-address within the message matches the one in their  
address-book,
  b) and that this email-address has been asserted valid with DKIM.

This strategy does not require providers to block any message,  
grandma to get out her magnifying glass, or junior to reconfigure  
grandma's the client to use 14 point font, not display translated ACE  
labels or display names and to post next to her display terminal the  
exact spelling of her important transactional email domains.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Tue, 12 Sep 2006 13:30:14 -0400 (EDT)

> hmmmmmmmmm,  unless I didn't follow you right, I fail to see the distinction

I get mail that pretends to be from my bank. The SSP says the mail
is 100% pure non-forged. However, the DKIM-BASE signing domain is
not in my list of trusted signing domains. I get a warning that
this mail could be sent by a party that I have no relationip with.

This may be a revolutionary concept to some, but a widely used
application called ssh has been using such tricks for 10 years.
Its approach to opportunistic authentication is not perfect for
purists, but it works for real people.

Having gone in circles twice, I think this is a good time to step
out of this thread. 

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Sep 2006 10:52:11 -0700

On Sep 12, 2006, at 10:30 AM, Wietse Venema wrote:

> application called ssh has been using such tricks for 10 years. Its  
> approach to opportunistic authentication is not perfect for  

I am in complete agreement with your statement.  Rather that offering  
a warning, not offering a positive annotation akin to the browser  
lock-icon should also work.

While the capturing of the DKIM signing-domain with that of the email- 
address would work, this could be made more reliable by adopting  
conventions for conveying when the signing domain has assured the  
email-address in some fashion.  In addition,  policy could also help  
reduce risks associated with the capturing efforts by confirming  
email-address/signing-domain associations.  With policy, it might  
also be possible to only capture the email-address itself, where  
policy makes the signing-domain association.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 12 Sep 2006 13:59:37 -0400

----- Original Message -----
From: "Wietse Venema" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 12, 2006 1:30 PM
Subject: Re: [ietf-dkim] SSP = FAILURE DETECTION

>> hmmmmmmmmm,  unless I didn't follow you right, I fail to
>> see the distinction or your point.
>

That's fine by me Wietse, but keep in mind that you mistaken by continuing
to use a magic wand to change an apple into an orange, by using reputation
is part of the total solution when in fact, it is suppose to be out of scope
in this WG.

We all have, or atleast most modern systems use white/black or reputation
concepts. That's a natural.  But that isn't part of the scope here.

In other words, the problem is when there is no white list environment or
more specifically an anonymous or unknown sender environment because that is
where most of the problem lies - how do deal with the unsolicited unknowns.

Anyway, I think we atleast in agreement that phishing will always remain to
be a problem outside of DKIM and/or SSP and even Trusted List ideas.  This
requires, imv, ever evolving prologue interpretation of the message.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Sep 2006 11:15:21 -0700

On Sep 12, 2006, at 10:59 AM, Hector Santos wrote:

>>> hmmmmmmmmm,  unless I didn't follow you right, I fail to see the  
>>> distinction or your point.
>>
> That's fine by me Wietse, but keep in mind that you mistaken by  
> continuing to use a magic wand to change an apple into an orange,  
> by using reputation is part of the total solution when in fact, it  
> is suppose to be out of scope in this WG.

Hector,

You have completely missed what was being said.  Where do you even  
see the word reputation?

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 12 Sep 2006 14:26:10 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>

>>> Wietse wrote:
>>>
>>> I get mail that pretends to be from my bank. The SSP
>>> says the mail is 100% pure non-forged. However, the
>>> DKIM-BASE signing domain is not in my list of trusted
>>> signing domains. I get a warning that this mail could be
>>> sent by a party that I have no relationip with.

>> Hector wrote:

> You have completely missed what was being said.  Where do you even

Semantics. Any predefined Trusted List, black or white, concept as Wietse
mentioned above, is a "reputation" concept.   It means you KNOW something
about them as oppose when you would not nearly 80% of the times which is
where most of the internet email problems lies with abusive malicious
anonymous (unknown) senders.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Sep 2006 12:23:25 -0700

On Sep 12, 2006, at 11:26 AM, Hector Santos wrote:

>>> by using reputation is part of the total solution when in fact,  
>>> it is suppose to be out of scope in this WG.
>
>> Hector,
>>
> Semantics. Any predefined Trusted List, black or white, concept as  
> Wietse mentioned above, is a "reputation" concept.

No they are not. I may verify the identity of foobar.com when I see  
them return a pass-phrase entered onto their web page, but that does  
not mean this provides any clue regarding their reputation.  If I  
decide to enter their name into my address-book for example, that  
will allow me to know when someone in my address-book has sent me a  
message.  Whether they are a spammer and should be blocked is a  
completely separate decision made elsewhere for a completely  
different purpose.

> It means you KNOW something about them as oppose when you would not  
> nearly 80% of the times which is where most of the internet email  
> problems lies with abusive malicious anonymous (unknown) senders.

Stop thinking DKIM + Policy allows spam to be blocked.  You really  
need to drop that concept.

The goal is to prevent spoofing (and not just exact name spoofing),  
which is clearly a component of the charter.  Spoofing is also nearly  
100% of the time dependent upon existing relationships.  Surely you  
have noticed this aspect of phishing?  Often a phish will warn of a  
need to update your account, or that your account has been blocked, etc.

Wietse's concept would permit detecting all these possible spoofs  
without reliance upon reputation.  Only those that might receive an  
annotation would require any additional processing.

A retain email-address found in the address-book is not reputation.   
Think of this as being a known identity.  And yes, this identity will  
not apply to 80% of the message being sent.  That is exactly why this  
approach works!  Only those identities that are known (reputations be  
damned) receive an annotation.

You on the other hand want to block only exact name spoofing if:
  - The From email-address domain wishes to endure the loss of common  
services.
  - The verifying domain decides to grope for policy.

This hunting or groping process is required for nearly every email as  
well, and not just those that not signed, and may even be required  
for those that are signed, such as those from mailing-lists.  Whether  
the email-address is known or not known, every From email-address  
domains must be searched and the signature verified. : (

The alternative provides complete protection using highly selective  
processing. : )

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 13 Sep 2006 01:55:20 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>

Doug,

That would easy to stop because I never made such a statement, nor was I
"thinking" it.

If you are interested in understand my engineering "thinking" about
DKIM-BASE and what DSAP/SSP is designed address, just read the DSAP and SSP
drafts.