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

From: Hector Santos <[email-masked]>
Date: Thu, 19 Feb 2009 14:20:25 -0500

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?

Will a NULL public key do the trick?

Thanks

-- 
Sincerely

Hector Santos
http://www.santronics.com

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

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Thu, 19 Feb 2009 11:41:27 -0800

On the lines of "v=spf1 -all"  or example.com.  IN MX 0 .  (mark
delany's old mxzerodot proposal)?

Yes a null signature could probably do it but something more explicit
perhaps to signal that this is not simply breakage?

-- 
Suresh Ramasubramanian ([email-masked])
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Feb 2009 12:55:19 -0800

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

> 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?
>

"Do Not Use DKIM" assertions are not possible.  Key locations can be  
published within any sub-domain, however spoofing is unlikely to  
reference a valid public key, unless your domain permits customers to  
publish TXT records within one of your sub-domains. : ^(

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Feb 2009 14:01:08 -0800 (PST)

> Will a NULL public key do the trick?

At the moment ADSP doesn't have such a mechanism.  It could (and used to) 
but then one issue is that you always have to query for such a record 
instead of only querying when there's no valid author domain signature.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 19 Feb 2009 22:27:45 -0000

>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.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Feb 2009 18:03:41 -0500

> look up a key record for a signature that doesn't exist, it should get

So this is obvious fraud.

    NO KEY means its not possible to sign. Therefore any signature
    in the message, means its a fraud, a fake.

Ok, makes sense.

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

Yeah, that RFC 4871 anomaly "Failure Promotion to no signature" always 
did baffled me.  Its like getting away with murder because police 
procedure was not followed.

-- 
Sincerely

Hector Santos

---

From: Barry Leiba <[email-masked]>
Date: Thu, 19 Feb 2009 18:35:50 -0500

> did baffled me.

If either one were "better", attackers would just shift to the better
one.  It's simple enough to use no signature at all, if no signature
is better than a broken one.  Similarly, it's easy to fake a signature
if that way be better.

Making the cases equivalent means we don't have to try to deal with
convoluted heuristics that will only be attacked anyway.

But that's really a digression; please, let's not clutter the
discussion with that issue again.

Barry

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Feb 2009 15:49:23 -0800

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?
>
> look up a key record for a signature that doesn't exist, it should  
> get the hint.
>

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.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Feb 2009 15:52:29 -0800 (PST)

On Fri, 20 Feb 2009, Franck Martin wrote:
> Should we not query every time the DNS, to check that this domain will 
> sign every message as policy and that a non signed message is therefore 
> invalid?

You would then only query for a non-signed message, not every message.

> In the case of the ebay announcement that all messages will have a DKIM 
> signature, how do you implement at the receiving MTA level this 
> verification?

Why is there a need if the message is signed and the signature validates?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Franck Martin <[email-masked]>
Date: Fri, 20 Feb 2009 11:49:57 +1200 (ANAT)

I'm a bit confused here (sorry I'm new on the list and I have not read ADSP in full) 

Should we not query every time the DNS, to check that this domain will sign every message as policy and that a non signed message is therefore invalid? 

In the case of the ebay announcement that all messages will have a DKIM signature, how do you implement at the receiving MTA level this verification?

---

From: Hector Santos <[email-masked]>
Date: Fri, 20 Feb 2009 00:04:25 -0500

Barry Leiba wrote:

 >>> Levine wrote:

Levine brought it up.   The question was if a NULL Key will help 
expose an inherent NO DKIM policy (sans ADSP).  He said the lack of 
one will be better.

We got multiple answers to this, including thats its not possible.

So the question is still up in the air as to how a DOMAIN can protect 
itself against obvious spoofed, fraud in the form of unauthorized 
signed messages.

Its one thing to say or indicate, maybe as a matter of corporate 
public policy, "we will always sign our mail", it is equally important 
to say "we don't or never sign our mail for XYZ domains"

-- 
Sincerely

Hector Santos

---

From: Hector Santos <[email-masked]>
Date: Fri, 20 Feb 2009 00:07:34 -0500

Murray S. Kucherawy wrote:
>> sign every message as policy and that a non signed message is 
>> therefore invalid?
> 
>> In the case of the ebay announcement that all messages will have a 
>> DKIM signature, how do you implement at the receiving MTA level this 
>> verification?
> 

I believe he is referring to the new fact "Ebay ALWAYS sign messages" 
can be used as a RULE when they isn't one present:

     Mail purported from Ebay
        -> Has No Signature
           -> My internal MUST-SIGN-DOMAINS.TXT file say it MUST
               -> REJECT!

-- 
Sincerely

Hector Santos

---

From: Hector Santos <[email-masked]>
Date: Fri, 20 Feb 2009 14:43:53 -0500

> 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.

-- 
Sincerely

Hector Santos

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Feb 2009 12:10:00 -0800

On Feb 20, 2009, at 11:43 AM, Hector Santos 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.
>>>
>> 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.
>
> 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

---

From: Franck Martin <[email-masked]>
Date: Sat, 21 Feb 2009 09:58:02 +1200 (ANAT)

but it can come from @example.com signed by @test.com 

----- Original Message ----- 
From: "Douglas Otis" <[email-masked]> 
To: "Hector Santos" <[email-masked]> 
Cc: [email-masked] 
Sent: Saturday, 21 February, 2009 8:10:00 AM (GMT+1200) Auto-Detected 
Subject: Re: [ietf-dkim] NO DKIM "POLICY" 

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Feb 2009 14:20:39 -0800

> but it can come from @example.com signed by @test.com

This could be described a third-party signature, where test.com should  
not be considered authoritative for example.com, just as  
ads.example.com should not be.  While test.com may allow acceptance of  
example.com's email, its signature should not directly assure  
recipients that use of the example.com domain is not being spoofed.   
Socially engineered attacks can easily acquire a signature from an  
otherwise reputable domain.

-Doug