Re: [ietf-dkim] Not exactly not a threat analysis

On Aug 16, 2005, at 8:03 AM, Arvel Hathcock wrote:

> > Verifying an accountable domain will not prevent a
> > mailbox-address from being forged (falsified).
> We can change the draft charter language to make this clearer.   
> Instead of
> "Forgery of headers that indicate message origin..." it could be (IMO)
> "Forgery of the domain found in an RFC2822.From header..."

The public will understand anti-forgery as protecting the identity of  
the author.  I have never received a message from just a domain.   
Providing an assertion that the From domain must be related to an  
accountable domain does not prevent forgery (the falsifying of the  
mailbox-address)  and calling this anti-forgery for the domain is  
misleading.  Perhaps one could call this a domain exclusivity assertion.
With this exclusivity or dominion asserted, the From header requires  
a related accountable domain to exchange these messages.  As this  
mechanism by itself does not prevent forgery, it is misleading to  
describe this as an anti-forgery mechanism.   The mechanism allows  
the From domain to assert a requirement for a related accountable  
domain, but assurances beyond this assertion of dominion is purely a  
function of the accountable domain.

> > Asserting that the From mailbox-domain must
> > be signed by the same domain, or even a sub-domain,
> > may reduce possible sources of forgery, but it does
> > _not_ prevent forgery, such as the falsification of the
> > local-part.
> Agreed.  So we'll shy away from grand claims concerning the total  
> elimination of domain forgery (no such claim is made anywhere  
> anyway that I've seen).  Now, since total elimination of forgery is  
> not a realistic goal, I'll happily take a *reduction* in forgery  
> any day and so will any responsible domain owner.  Can you agree  
> with that statement?

A reduction in the possible sources of forgery does not assure a  
reduction in forgery.  Keep it clear what this mechanism provides.    
This mechanism allows a From domain to assert a requirement for a  
related accountable domain.  What that assertion means with respect  
to any number of issues should not been seen as a function of DKIM or  
even this mechanism.  This mechanism has nothing to do with DKIM, and  
nothing to do with forgery.  What this mechanism provides depends  
fully upon the accountable domain.
What this From-domain dominion attempts to achieve is a means to make  
the accountable domain inherently visible. (This of course ignores  
several problems related to MUA presentation.)
Levels of assertions:
1 - No assertions.
2 - From-domains accompany an accountable domain.
3 - From-domains accompany an accountable domain within the domain of  
the From.
4 - From-domains accompany an accountable domain that is the same as  
the From.
Did I miss an obvious assertion?

You will also notice that I did not limit this assertion to just that  
of DKIM.  There is no reason to do so.

> > If the domain is large and depends upon the network
> > address to authenticate users, then claims that DKIM
> > prevents forgery would be irresponsible, even when the
> > From mailbox-domain is restricted to being signed by
> > the same domain.
> I totally do not understand that.  What do you mean "network  
> address to authenticate users"?  Is this the IP you're talking  
> about?  How does that bear on whether a domain's signing policy can  
> prevent unauthorized use in the RFC2822.From or not?

I was attempting to clarify that some domains will be unable to make  
an anti-forgery claim regardless of these assertions being  
described.   An assertion that a From-domain must accompany a related  
accountable domain does not assure there is any anti-forgery  
protection provided or that any message is sent by those using an  
authorized mailbox-address.  This assertion does not require DKIM  
either.

> > Considering anti-forgery or anti-phishing out of scope
> > for DKIM would increase a focus upon what DKIM
> > is actually providing.
> Anti-phishing, ok, because we'll all just rathole on that topic.  
> Anti-forgery, no, absolutely not.  If both these are out of scope,  
> what then is the real-world problem DKIM is trying to address?

The real-world makes a decision to accept messages based upon the  
reputation of the client attempting the offer.  Currently this  
decision is largely based upon the IP address, but this may create a  
great deal of collateral damage resulting from extensive sharing of  
IP address space.  Often this potential damage is mitigated by  
tolerating a higher level of abuse.  At one time not that long ago,  
just IP address reputation provided greater than 90% protection from  
abuse.
Abusers have since found ways into these larger domains to hide in  
the crowd, or use the Delivery Status Notifications as a type of back- 
door by taking advantage of those that don't use a reputation  
service, and process messages after acceptance.  They have also found  
ways to commander IP addresses.   There are new nastier techniques  
emerging.
Depending upon the nature of the IP address reputation list and the  
profile of the recipient, the success rates for IP address  
reputations vary greatly, but many see a reduction by more than half  
of the sources of abuse.  No one suggests this is good enough.  A  
reduction of this size still permits an inordinate number of abusive  
messages.
Moving to the name space has advantages in that many of today's  
chinks are related to the IP address weaknesses.  A signature has  
advantages related to enduring forwarding as well.  A name permits  
closer cooperation and demonstrates a level of accountability.  These  
two features combined should permit a much lower tolerance for  
abuse.  A name can safely carry the history of the owner, whereas an  
IP address can not.

>   Is it that we don't have enough inputs into our filtering engines  
> today and we just MUST have a signature based one?  Or is it that  
> email users are routinely seeing unauthorized domain use in the  
> RFC2822.From?

As a general rule, don't look at behavioral tactics designed to avoid  
today's protection schemes. I routinely see these From addresses only  
depend upon the pretty name to fool recipients.  These tailored  
protection schemes will be like chasing tails attempting to prevent  
every ploy.  What is needed is a better identifier for a stronger  
protection scheme based upon the reputations of these entities.  This  
type of approach can adapt, as reputation can address every trick.
Domain assertions are fine.  Just don't ascribe these assertions as  
being a solution to end forgery, or as married to just DKIM.  These  
assertions are independent of the DKIM mechanism.

>   Everything I've seen leads me to believe the problem is the  
> second thing.  For example, "Forgery of headers that indicate  
> message origin is a problem for users of Internet email." - this is  
> the *first sentence* of the proposed charter.  Also: "DomainKeys  
> Identified Mail (DKIM) defines a simple, low cost, and effective  
> mechanism by which cryptographic signatures can be applied to email  
> messages, to demonstrate that the sender of the message was  
> authorized to use a given email address."  This language definitely  
> needs tweaking but the thrust of the statement is clear -  
> unauthorized use (read: forgery) is what DKIM is trying to  
> address.  Are we not in agreement as a group on this point?

I find this language over-reaching and unrealistic.  The signature  
only verifies an accountable domain, anything beyond that is  
conjecture.  By sticking to this language, the group may find  
themselves chasing after some holy grail and end up with nothing.   
What is wrong with establishing an accountable domain?  This  
accountable domain may be bound to other headers within the message  
by independent mechanism that are beyond the scope of DKIM.
-Doug

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