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

Douglas Otis wrote:
> On Aug 15, 2005, at 6:09 PM, Dave Crocker wrote:
>
> > Equally I am wondering whether it is not distracting from the core  DKIM
> > authentication work to emphasize this particular requirement prior to
> > deployment of a signing/validating mechanism.
> >
> > In other words, it is starting to look as if the mechanism for  enforcing
> > originator/handling linkages needs separate focus from techniques for
> > performing authentication.
> >
> > Thoughts?
>
> 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.

> 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.
> A natural outcome of any method that provides a strong message  
> identifier would be related to reputation.  Whether this feature is  
> expressed in terms of abuse prevention or not, this will be a  principle 
> use.  As a result, there should be considerations given how  this may be 
> abused by miscreants.  This being a goal or not, when  DKIM is expressed 
> independently from the optional domain-assertions,  it becomes difficult 
> to distance the DKIM mechanism from this aspect  of email handling.
> Once there is an accountable domain established for a message, as an  
> option, some want to bind the accountable domain with the From- domain.  
> This is not directly a product of DKIM, but rather that of a  
> domain-wide assertion.  There are several who embrace a concept of  
> constraining the use of their domain name through domain-wide  
> assertions.  This has been a common theme.  There is more than one  
> email related application where such assertions could be applied,  which 
> suggests this should be kept separate, as it also tends to be  
> expensive, at least initially.
Certainly it _could_ be kept separate.  I expect that doing so would 
sharply constrain the value of DKIM as a complete product.
> 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.
I'm sure it isn't affecting the views anyone is promoting here, since we 
are all acting as individuals and not as representatives of any 
particular corporate interest, but it does occur to me that perhaps such 
an approach might make DKIM dependent on reputation products to have 
value to receivers.
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?
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.
> Alas, I suspect a major reason for resisting the splitting of these  
> efforts is that some domain owners have had bad experiences with  
> reputation services.  Without including the domain-wide assertion,  DKIM 
> really only supports an aspect of this dark side.
I can't speak for anyone else, but that's not the case for me.  I would 
say that I'm in favor of DKIM defining a protocol that has substantial 
marginal utility on it's own merits.  There may be added benifits 
associated with combining it with other approaches, but that should be 
addressed later.
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.
Scott K
_______________________________________________
ietf-dkim mailing list
http://dkim.org