[ietf-dkim] Reputation can not be established without ready means to aba

On Oct 7, 2005, at 9:47 AM, Dave Crocker wrote:

> Douglas Otis wrote:
>
> > > The only thing DKIM "prevents" is detecting invalid uses of a  
> > > domain name for a signature.
> > DKIM, as described, does not prevent or detect invalid uses.
> Oh.  You mean that your sending a message using my domain, without  
> my permission, won't be possible to detect?

Absolutely.  Based upon the verification of the DKIM signature, a  
reputation service will not be able to detect whether the recipient  
of the message had been "permitted" along with perhaps thousands of  
messages to other recipients.  Normal safeguards, such as rate  
limiting, will no longer be effective.  Some third party could obtain  
one of your signed messages where the intent could be misconstrued,  
and then go on a rampage.  A primary consideration regarding whether  
an email source is abusive is determined by who received their  
messages, and not the content of the message.

> > Not in the case of a replay, for example.  The domain may consider  
> > abusive replay to be an invalid use when such use impacts future  
> > abilities.
> The term "replay" has at least two different uses.  One refers to a  
> third party, using some of an otherwise valid message, while adding  
> their own content. DKIM will permit detecting this.

DKIM _may_ detect added information, but that was not the concern.   
Start with the premise that compromised systems have become  
pandemic.  An inability to cope within that environment will be  
fatal, largely because reputation/accreditation have become vital  
protective mechanisms.  Once a system becomes compromised, the  
perpetrators will have little difficulty sending themselves messages  
that can be replicated a billion fold.  Of course problems may result  
from a plethora of causes.  Perhaps cracked passwords due to key- 
loggers, cracked wire-less access points, compromised systems,  
clueless individuals duped into sending a shill a "desirable"  
message, or even cracked remote SMTP services.
For reputation services, current expectations are that once the  
domain is provided notice of a problem, the problem is to be resolved  
in short order.  Normally this would mean terminating the offending  
account, or perhaps placing the compromised system into a "walled  
garden".  With DKIM, as it is currently described, resolving such a  
problem may take days.  There is no reputation service willing to  
wait such a period for what could be a significant problem.  After  
all, reputation services must respond to the needs of their clients.   
This would mean listing the offending domain and then expecting the  
domain to go through a rehabilitation process.  In the meantime, it  
may mean a large percentage of the domain's email becomes undeliverable.

> > > Since DKIM does not "do" reputation, talking about the  
> > limitations of using DKIM for reputation strikes me > entirely out  
> > of scope.
> > The concern was _not_ about whether DKIM "does" reputation, but  
> > whether DKIM "supports the use of" reputation.
> Doug,  you are adding to DKIM's scope and then criticizing it for  
> not satisfying the extension.
> Before you start trying to specify solutions and before you claim  
> that DKIM has anything that might be called a "weakness" you need  
> to recruit support for this expansion in DKIM's goals.  So far, I  
> have not seen that support emerging.
I don't think it is as effective to critique a design and proclaim a  
major flaw without offering a reasonable solution.  I always hope  
someone offers a better solution, and I think Earl Hood made several  
good suggestions. It is not just myself that holds the view that DKIM  
is seriously flawed.   I could add dozens of other examples of when  
the lack of replay abatement would be a problem.  I thought this was  
the goal of the threat draft?  I could not agree more with the mass- 
sec-review.  Ignoring the application of reputation or declaring it  
"out of scope" does not make the problem go away. : (
excerpt: draft-housley-mass-sec-review-00.txt
.---
|4.1. Replay Attacks
|
| One of the MASS goals is to prevent ISPs from having from their
| addresses forged by spammers.  This service would support the
| construction of a reputation system.  Neither DomainKeys nor IIM
| prevent source address masquerade.  It is fairly easy to send Spam
| with a valid isp.example.com signature by simply getting an account
| from that ISP and use it to send a Spam message to another account
| served by another ISP.  The received message contains a valid
| signature for the Spam message.  The message can be duplicated and
| resent to any recipients, and the ISPs signature will be valid.
|
| According to the IIM authors, they discuss this attack and some
| solutions.  The solutions all had undesirable properties.
|
| In security terms, this is a replay attack.  Without replay
| protection DomainKeys and IIM fail to provide the authentication that
| being advertised.
'---

Upon resurfacing from the IIM DK merger process, muck in the form of  
mailbox-domain authorization was added without addressing the  
fundamental problem crippling the DK and IIM schemes.  Mailbox-domain  
authorization shifts this problem onto the mailbox-domain owner silly  
enough to authorize a signing domain.  While individuals may be  
coerced into providing authorization by various means, this does not  
resolve the basic flaw. Solve the inability to revoke messages, and  
then there is no need for burden shifting, nor is there a need to  
publish complex associations, as these can be deduced from prior  
correspondence where only a minimal level of signaling could be  
passed directly within the message.
In other words, SSP is not needed and represents additional sources  
for new exploits.  The end result of the SSP ploy will limit freedom  
in the use of mailbox-addresses for otherwise responsible  
individuals, while also inflicting them with unfair reputation  
assessments based upon a now doubly flawed scheme.  DKIM, as it is  
currently described, should not go forward.  It will create far more  
harm than good.  Repair DKIM, and DKIM should be able to resolve many  
of the security problems haunting email today.

> > This concern is distinctly different and does not deal with any  
> > details related to a specific implementation of reputation.
> You have been suggesting specific changes to the DKIM specification.

I have suggested a means to abate abusive replays.  Without replay  
abatement, DKIM fails to provide the authentication advertised.   
Without being able to apply reputation as a result, _no_ protection  
is possible.

> > Strange how only repudiation is supported, but then only  
> > reputation is mentioned in the threat analysis.
> Strange?  DKIM is a complete technical specification that performs  
> specific functions.  The threat analysis describes what problems  
> that specification attempts to deal with.  What would be strange --  
> and entirely inappropriate -- is to have the threat analysis cover  
> threats to which DKIM does not respond.

In that case, remove mention of reputation or accreditation from the  
threat analysis.  DKIM is unable to use reputation or accreditation  
to respond to threats.  Remember, I am in favor of DKIM, but simply  
not as currently defined.  DKIM is seriously broken, but can be  
repaired.

> > You have again suggested DKIM only supports repudiation.
> What language of mine do you believe says this?
"The only thing DKIM "prevents" is detecting invalid uses of a domain  
name for a signature."
,---
| Repudiation:
|  Refuse to accept or be associated with,
|  or deny the truth or validity of.
'---

I would describe your language as limiting the purpose of DKIM to  
repudiation.  This perception is reenforced within the abstract for  
DKIM. : (
I think we both understand that repudiation with respect to DKIM  
offers little in the way of protection.
> > Would it be okay to review an elevator pitch for repudiation?
> The threat analysis deals with the existing DKIM -- unless there is  
> rough consensus to expand DKIM's scope. I haven't seen that  
> consensus emerging.  Discussing repudiation is an attempt to expand  
> DKIM's scope.  Repudiation prevention is a nice goal.  There are  
> lots of nice goals.  Would it be reasonable to have an open-ended  
> pursuit of all the nice goals that DKIM *might* be modified to  
> assist in achieving?
> I don't think so, unless the goal here is to have endless abstract  
> discussion, rather than to expedite standardization of DKIM.

If not reputation, and not repudiation, what protection is afford by  
DKIM?
-Doug




_______________________________________________
ietf-dkim mailing list
http://dkim.org