Re: [ietf-dkim] NO DKIM "POLICY"


On Feb 20, 2009, at 11:43 AM, Hector Santos wrote:

Douglas Otis wrote:

On Feb 19, 2009, at 2:27 PM, John Levine wrote:

What is the current recommended method to establish or expose  
that  a DOMAIN should not be signed, is not expected to be signed  
and  that any DKIM supportive receiver seeing a message with a  
signature  from a purported domain should be rejected with full  
confidence?

That's easy: don't publish any key records.  If a verifier tries  
to  look up a key record for a signature that doesn't exist, it  
should  get the hint.

By design, a broken signature is equivalent to no signature.

Agreed.  However, treating a signing domain as just a reputation  
token  is likely to result in slack handling.
Rather than utilizing i= values, when sub-domains are used to  
isolate  reputation assessments, a strategy that employs a sub- 
domain  relationship to override anti-spoofing checks is taking a  
considerable  risk from a control standpoint.  There is nothing  
wrong with using i=  values to isolate reputation streams within a  
DKIM domain.  Those  checking reputations need to limit the number  
of unacceptable i=  values reported before declaring the entire  
domain unacceptable.  This  same limit is needed for sub-domains.
Currently, DKIM offers anti-spoofing protection for some 10  
billion  messages daily.   My brief use of an email-address on the  
IETF mailing  list quickly resulted in spam spoofing this address.   
If this email- address happened to have represented that of a  
financial institution,  anti-spoofing protections would have been  
nearly automatic.  While  some messages sent through a DKIM signing  
provider may receive just a  third-party signature assure their  
acceptance, they would not enjoy  the anti-spoofing benefits as  
defined in the charter.  Although for  many this will not matter,  
for some it is critically important.
In Hector's case, depending upon how prevalent sub-domain  
reputation  segregation becomes, a need to ensure no keys can be  
published within  some sub-domain might become crucial.  The use of  
ADSP does not  foreclose sub-domain spoofing, such as accounts.big- 
bank.com.   Not  treating the d= value as opaque helps ensure DKIM  
remains safer to use.


In this case, a national store chain was being asked to delegate a  
sub-domain for signing by their bulk mailer vendor.

The concern was the potential harm to their principle domain and  
wanted to make sure there was a mechanism in place to help avoid  
DKIM outside the request and usage by their professional spammer.


Socially engineered attacks are rising.  The chartered goal of DKIM  
was to allow the detection of spoofing of known domains to help  
counter these attacks.  When an email appears to be from  
@ads.example.com signed by ads.example.com, or example.com where  
i=ads.example.com might be used, the intended goal is met.  When an  
email is from @example.com signed by ads.example.com, this defeats  
DKIM's intended goal.

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