ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] I-D.kucherawy-dkim-reporting (was: Discussion of Consensus check: Domain Existence Check)

2008-06-12 02:23:11

On Jun 11, 2008, at 6:07 PM, Frank Ellermann wrote:

Douglas Otis wrote:

[skipping the parts we have now repeated often enough]
After all, the goal is to finish the ADSP, ASAP.  : )

Sometimes I wonder what the goal here is.  Looking into 
http://tools.ietf.org/html/draft-kucherawy-dkim-reporting 
 it reinvents RFC 3834 without referencing it, it has a reference to  
RFC 1894 obsoleted by RFC 3464 *five* years ago, and still talks  
about ASP instead of ADSP.

Using [FWS] in DNS records is also broken by design, unless the goal  
is "experimental" havoc.

Adding to this, Murray Kucherawy's draft captures the i= (identity)  
parameter and a worthless s= (selector) parameter.  The s= parameter  
offers little value since the d= (key domain) parameter is missing.   
Only the d= parameter (upon which the s= parameter rests) represents a  
domain validated by a verified signature.  An identity parameter can  
include any number of virtual or wildcard domains below a key domain.   
The d= (key domain) ensures reputations consolidate upon a controlling  
entity.  Basing reputation upon either the i= or the s= parameters  
would permit senders an easy ability to fabricate an infinite number  
of such tokens.  Such diversity will thwart efforts at establishing  
reputations.  Basing reputation upon the key domain essentially means  
a sales department can not spam with impunity while using the same key  
domain.  This has been clarified in the otis-dkim-adsp draft.

Restricting the i= in the ADSP draft is also a mistake.  When a domain  
attempts to accurately indicate on whose behalf the signature was  
added, the identity might not be that of the Author.  In which case,  
even signing all messages would not satisfy a CLOSED ADSP practice.   
It should be possible for the identity included within the signature  
to be opaque and perhaps derived from an account granted access, and  
not necessarily be either ambiguous or affirm the identity of the  
Author.  Otherwise, the only work around for remaining compliant  
involves adding multiple signatures.  Necessitating ambiguous (on  
behalf of) signatures will also thwart dealing effectively with intra- 
domain abuse.  When unrestricted signatures are added to a message,  
receiving hosts should expect the message conforms to the key domain's  
governance.

Excluding the i= parameter as a component of ADSP compliance ensures  
greater interoperability when DKIM signing is by MTAs.  However,  
messages signed with g= restricted keys should not be accepted when  
the identity within the signature is not that of the Author.  Refusals  
of local-part restricted messages should not be conditioned upon  
receiving hosts first obtaining an ADSP records.  Local-part  
restricted keys permit signing on behalf of a specific identity, where  
this identity should always represent that of the Author.  Otherwise,  
not imposing this limitation as a general rule allows circumvention of  
the anti-spoofing protections being sought.  This is an issue  
independent of ADSP as well.

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>