Re: [ietf-dkim] draft-fenton-dkim-threats-00

On Oct 6, 2005, at 12:50 AM, Eliot Lear wrote:

> Doug,
>
>
> > Only when the "address" and the signer are the same, would it be  
> > possible to safely make assertions of behavior, but then of course  
> > extending assertions of behavior to the "address" would not be  
> > required.  I see little within the threat analysis that clarifies  
> > this limitation.  I am not comfortable with promises that  
> > "address" protection is limited to just repudiation.
> I do not know what you mean by "address" and the signer being the  
> same.  If by that you mean that the domain of the signer and the  
> sender are the same, then at least I don't disagree.  I can't say I  
> agree because I don't really understand your concern.  It follows  
> that in order to determine responsibility for the sender one first  
> needs to determine responsibility for the domain, and the way that  
> is done with DKIM is via DNS.  The source of authority for the  
> sender can then from that point be delegated.  Are you questioning  
> the strength of that delegation?  If so, could you please explain  
> it in smaller words, step by step?

There are really only two forms of protection possible with DKIM,  
repudiation or reputation.  Neither of these mechanisms are clarified  
in the threat draft, although repudiation is used exclusively in the  
DKIM abstract and makes roughly the same claims.  Protections based  
upon repudiation is virtually nil when any number of possible  
exploits are considered.  When viewed from the reputation  
perspective, it becomes difficult to deduce how DKIM would offer  
protection beyond the signing domain.  To be fair, reputation must be  
constrained to _verifiable_ identifiers, which is the signing domain  
in the case of DKIM.  Clearly, claims are made that extend protection  
beyond the signing domain, but it is not clear which mechanism is  
being suggested.  Jim was advised to remain silent on this point  
concerning a rather basic premise.

> > The threat draft makes what I see as rather dangerously broad  
> > generalizations.  It becomes a perilous situation to consider  
> > establishing a matrix of authorizations with respect to signers.   
> > Such an assessment scheme would depend upon an unaccounted signer  
> > where repudiation _must_ be the sole objective.  Just as  
> > "Repudiation MailFrom" became "Sender Authentication", there is a  
> > real danger the limited benefits of repudiation will be extended  
> > by unfair reputation assessments.
> I'm sorry but I don't see how you got there.  Why must repudiation  
> be the sole objective?

The accrual of behavioral data for a reputation service must be  
attributed to _verified_ identifiers or costly disputes are likely  
when domains are unfairly blocked.  Verification does not mean  
authorization alone.  Authorization in isolation depends upon an  
unaccounted third-party to have verified the identifier.   
Unfortunately, some providers are inducing domain owners through  
various means to provide authorization without clarifying the risks  
when the unaccounted third-party neglects newly required  
verifications.  In the past, the initial premise for an authorization  
mechanism was for repudiation, but repudiation provides little  
benefit and is easily defeated.  Nevertheless, the domain owner is  
expected to provide authorization that _will_ be misapplied and used  
as a basis for accruing reputation, perhaps under duress.  It would  
be far safer to limit domain assertions so they can not extend beyond  
to the domain itself to prevent this type of egregious misapplication  
of reputation.

> > Inappropriate use of reputation can be prevented by simply  
> > limiting the purported protection to just the signing domain.   
> > Presume a fair reputation scheme on the basis of the signer offers  
> > a full spectrum of protections.  This protection can be slightly  
> > enhanced by safe assertions the domain signs all their own mail.   
> > Perhaps this type of assertion could even be extended to also  
> > disallow the resending of their mail.
> > On a related topic, adding an opaque-identifier greatly extends  
> > the protections made possible by DKIM that are discounted in this  
> > draft.  Importantly, these identifiers permit replay abatement.   
> > Alas, without prompt curtailment of abusive replays, reputation  
> > does not offer dependable protection, nor will DKIM.  Zombies are  
> > far too prevalent.
> Does the SMTP Message-ID play this role?
No.  Here is a draft that attempts to explain the use of the opaque- 
identifier.
http://www.ietf.org/internet-drafts/draft-otis-mass-reputation-03.txt


Just a few embarrassing weeks ago, I infected a CTO's computer.  I  
was suitably paranoid and first checked that all system patches, anti- 
virus, anti-spyware were up to date.  I then entered a link (that had  
been published in the WSJ) into Explorer and hit carriage return.  As  
I watched for a page to appear, in the next few seconds several  
Trojans were being detected out of the dozen different Trojans  
installed.  This was a site I had visited previously and now assume  
the website itself has been compromised.  I have disinfected many  
sales persons computers from various companies which seem to be  
spyware magnets.  Of course I have very few friends not computer  
savvy that also are not infected.  After my foible, I find it  
difficult to denigrate those with infected computers.
A replay problem will not be limited to just large domains, however  
these will likely experience the greatest problems.   Should DKIM  
become pervasive, rather than installing adware, Trojans could easily  
send spam to themselves intended for replay.  With DKIM not having a  
reasonable means to deal with the replay problem, I fear there will  
be an attempt to then misuse mailbox-domain authorization as a basis  
for reputation.  (Repudiation is hopeless.)  This then unfairly  
shifts the problem onto the hapless mailbox-domain owner.  Without  
the opaque-identifier, DKIM does not offer suitable consumer  
protections, who will become the ultimate victims, perhaps out of  
duress.  The present scheme even suggests local mailbox-addresses be  
exposed. : (
The use of the opaque-identifier would be a safe alternative that can  
be optional.  Checking the identifier can be mitigated in the vast  
majority of cases, perhaps using the technique suggested by Earl Hood  
without causing any forwarding issues.  This opaque-identifier would  
permit locating compromised systems without needing extensive  
correlation.   It would permit a timely response that can scale and  
be confirmed, as each domain would publish their own fairly simple  
revocations.  This publishing could even be provided as a service, by  
way of delegation.  This approach also allows detection of intra- 
domain spoofing when combining the opaque-identifier with the signing  
domain as a pseudo-certificate.
-Doug


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