Re: [ietf-dkim] linkage between "originator" and "handling agent"

On Aug 17, 2005, at 7:18 AM, Scott Kitterman wrote:

> Douglas Otis wrote:
> > There are two ways to look at DKIM goals-
> > 1- A mechanism that provides an accountable domain for the message.
> > A number of features are available as a product of the  
> > accountable  domain.
> >  a) reputation accrual
> >  b) directed abuse reporting
> >  c) IP address independent basis for message acceptance
> None of which relate to preventing forgery.

DKIM alone or in combination with domain-wide assertions do not  
assure prevention of forgery (the falsification of a sending mailbox- 
address).  This assumption trusts the signing domain, but without  
assurances.  The 'i=' parameter appears related to the use of user- 
keys.  The 'i=' parameter may also declare just the domain, or not be  
used at all.  I would also argue that user-keys are not appropriate  
for DNS.  Unless you are suggesting every user has their own key,  
then claims of preventing forgery by implementing DKIM is very  
misleading.  The term 'forgery' is misleading and may lead to a  
dangerous reliance on this half measure.  I am simply asking for  
better descriptive language when describing the intended goal of a  
domain-wide assertion.
> > 2- A mechanism that is able to optionally constrain the use the  
> > From- domain.
> >  a) debunk spoofed messages
> I don't think debunk really captures it.  I think we are after a  
> mechanism to allow receivers to determine if the sending domain  
> (yes, I know that's an amorphous term) is willing to state the the  
> message is authorized.
Anti-phishing and anti-forgery clearly overstate the results of a  
domain-wide assertion in conjunction with DKIM.  While DKIM in  
combination with domain-wide assertions, or the visibility of the  
accountable domain, will limit sources of possible abuse, it is  
important to be realistic about what DKIM and DKIM in combination  
with a domain-wide assertion provides.
There are many problems that will need to be addressed with a domain- 
wide assertion mechanism.  I would even argue that simply exposing  
the accountable domain, verified by a valid DKIM signature, would be  
a better means to achieve greater safety.  There are many ploys where  
pretty names are used, or where reliance upon the MUA offering  
greater emphasis on unchecked headers may actually pose greater risks  
to recipients.  This is made worse when these recipients have been  
assured by some "icon" that indicates this message is DKIM verified,  
believe DKIM prevents 'forgery' and that the sender mailbox address  
can be fully trusted.  Would the recipient understand that only the  
domain of the From is being checked?
There are very good reasons not to rely upon the browser 'lock'  
icon.  The domain being trusted should always be visible.  Not doing  
so leaves the system extremely vulnerable.  While it could be assumed  
that blatant criminals would not be able to retain services of a  
Certificate Authority, this still leaves a large window of risk.  In  
the case of DKIM, there is not even a CA.  In the end, the trust is  
based upon the signing domain.  There is tremendous value being able  
to verify (and see) who is being trusted.
Once the accountable domain is visible, much of the justifications  
for implementing the automation of detecting spoofed messages  
vanish.  A list of institutions plagued by phishing which also fully  
implement DKIM with deterministic header conventions would enable  
effective filters without any domain-wide assertions as well.  Domain- 
wide email assertions could be considered a method to indicate  
implementations of various present and future protocols.  The binding  
of headers seems rather perilous from a standardization perspective  
for the reasons mentioned.

> > To clarify basic elements involved in DKIM, versus expressing  
> > domain- wide assertions, these two efforts should be independent.   
> > This would  ensure a flexible language is used to express these  
> > two highly  independent functions.
> One might, I suppose, make the arguement that the policy linkage  
> between the sending domain and the DKIM signing domain is really a  
> form of a very narrow reputation service.  So, on that note, you  
> might be right, but then where's the value in DKIM signatures  
> alone?  Is it sufficient to merit a working group?  Is it  
> sufficient to garner deployment?

There is great value in knowing who allowed abusive email.  There is  
great value knowing who should receive complaints when abuse  
appears.  There is great value, when those accountable for abuse are  
blocked by a reputation service, the innocent domains are not  
inadvertently impaired.  There is great value knowing where to go  
when there is criminal activity.  I believe just a few of these and  
many more reasons would be sufficient.

> Perhaps if we proceed down this path, what we really ought to be  
> doing is including reputation protocol that will leverage off of  
> DKIM signature within the scope of the planned working group.  Not  
> that I'm suggesting we should proceed down this path.
I am not suggest that either.

> I do think that DKIM needs to decide if it's just some random  
> signed identifier or if it has a relationship to reducing forgery.   
> Some have indicated they see sufficient value in the signed  
> identifier.  I don't.
I see many advantages avoiding the 'forgery' or 'phishing' issue.  I  
suspect this will be the preverbal rat-hole deluxe.  I also see  
tremendous value in having the administrative domain sign the  
message.  This is not just some random signature, as you describe it.
-Doug







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