[ietf-dkim] on the scope and necessity of threat analysis

[Dave Crocker]

Arvel,

I think your note is helpful in describing a set of desires.  I am not sure that 
they fully match what DKIM can reasonably do, or least reasonably in its current 
form.  To explore this, I'll ask some directed questions.  I'm am hoping that 
others will also respond and will ask more questions:


>  Here's the real problem I would like to solve:  (Domain owner speaking
>  here):  Recipients of messages from my domain currently have no method of
>  verifying whether the message conforms to my sending policy or not; nor can

"Conforms to my sending policy" is powerful language, but also very abstract. It 
could easily imply many things that you probably do not mean.

You could have sending policies that no message may be more than 17033 
characters long or that none may contain the word "fooey" or that none may 
express unhappiness with the company lunch menu.  I suspect you do not mean 
anything that broad or random.  

So, please try to list the (kinds of) "policies" you have in mind.  If we work 
with a list of more specific policies, it will be vastly easier to evaluate 
DKIM's ability to satisfy your requirements.


>  (Email admin speaking here):  I'd like to know whether a message I allow
>  into my network
>  is authorized by the domain owner in the FROM header and I'd like to know
>  whether the message contains the same content that the signing domain
>  intended.  

Why do you say RFC2822.From header field, specifically?  Why do you care what, 
specific field contains the identity?  

I assume it is because you have some assumptions about how the validated 
identity will get used, so I'll ask you to consider those assumptions carefully. 


(Since you were part of the DKIM development effort, and since the issue has 
been discussed a couple of times on the mailsig list, you probably know where I 
am going with this question, but I'd like the discussion to unfold on its own, 
here.)


>    (Domain owner speaking here) DKIM provides the ability to distinguish
>  messages that conform with my local policy from those which do not. 

What you have stated, here, requires all of the DKIM SSP capabilities, in all 
their functional glory, including checking for policies that apply to unsigned 
messages.

Is there any value in only dealing with (validating) signed messages?  I ask 
because it seems likely that it would be good not to *require* checking unsigned 
messages.  So, is there benefit in being able to do "nothing more" than 
validating some identity associated with the message?

By way of seeking some efficiency, let me prime the pump:  One study has shown 
that roughly 90% of the SPF-registered email is spam.  That's really not a 
surprising statistic, absent any common assessment services. However, assuming 
that domain name-oriented assessment services become common, it seems reasonable 
to expect most signed mail to be from good actors rather than bad actors, since 
the bad actors will not see any benefit from doing signing.  


> It also
>  provides the ability to spotlight messages which have been altered.  (Email
>  user speaking here):  DKIM provides the ability to distinguish messages
>  which conform with the policy of the domain in the FROM header from those
>  which do not and it spotlights content change.

Keeping the focus strictly on the additional point you raise here:  DKIM ensures 
that that changes to the content that was present when the message was signed 
will be detected.


>  Here's how I think the "degree to which DKIM does not" solve the problem
>  plays out:  DKIM does not prevent unauthorized use of any domain.  DKIM does
>  not mandate or gaurantee how messages failing to conform to signing policy
>  will be handled.  DKIM does not specify how (or even if) an indication of
>  forgery will be displayed to end users.  DKIM is an input into local policy
>  decisions.  But it is an important and solid input.

good list.



  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net