Subject: [ietf-dkim] DKIM - Is policy record required?

From: deiva shanmugam <[email-masked]>
Date: Tue, 18 Aug 2009 10:30:29 +0530

Hi,

Could someone let me know, is querying the policy record essential for DKIM
at verification side as DKIM is derived from Domainkeys?

In RFC 4871, usage of policy record was not clearly mentioned. But in
section 6.3, the RFC says "when communicating with a peer who, by prior
agreement, agrees to only *send signed messages*" and in section 8.4, RFC
says "A second security issue related to the DNS revolves around the
increased DNS traffic as a consequence of fetching selector-based data as
well as *fetching signing domain policy*." So, i'm not sure whether the
policy record in DNS TXT record in _domainkey.<domain_name> need to be
queried for DKIM?

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

---

From: Doug Otis <[email-masked]>
Date: Mon, 17 Aug 2009 23:44:21 -0700

On 8/17/09 10:00 PM, deiva shanmugam wrote:
> Hi,
>
> Could someone let me know, is querying the policy record essential for
> DKIM at verification side as DKIM is derived from Domainkeys?
>
> agreement, agrees to only /send signed messages/" and in section 8.4,
> RFC says "A second security issue related to the DNS revolves around the
> increased DNS traffic as a consequence of fetching selector-based data
> as well as /fetching signing domain policy/." So, i'm not sure whether
> the policy record in DNS TXT record in _domainkey.<domain_name> need to
> be queried for DKIM?

Some might view policy records as a means to offer advice in creating 
phished lists.  These lists identify domains suffering from being 
spoofed, where such policy records grant permission to reject 
non-compliant messages.  Some receivers might discard non-compliant 
messages, which of course could place messages forwarded through a 
mailing list at risk.

These records are unlikely queried on a per message basis at some 
negative caching rate, as this would be needed for every email domain, 
and not just for those with a DKIM signature.  Instead, a periodic 
sampling of DKIM domains or a third-party service could consolidate into 
a list the domains in need of stringent handling from those that have 
been seen using DKIM.

-Doug

---

From: deiva shanmugam <[email-masked]>
Date: Tue, 18 Aug 2009 13:02:53 +0530

Hi,

Thanks Doug for the clarification.

So, eventhough the DKIM RFC explicitly doesn't mention the use of policy
record in the verification side, still we should query for the policy
record.

Thanks,
Deiva Shanmugam

On Tue, Aug 18, 2009 at 12:14 PM, Doug Otis <[email-masked]> wrote:

> phished lists.  These lists identify domains suffering from being spoofed,
> where such policy records grant permission to reject non-compliant messages.
>  Some receivers might discard non-compliant messages, which of course could
> place messages forwarded through a mailing list at risk.
>
> These records are unlikely queried on a per message basis at some negative
> caching rate, as this would be needed for every email domain, and not just
> for those with a DKIM signature.  Instead, a periodic sampling of DKIM
> domains or a third-party service could consolidate into a list the domains
> in need of stringent handling from those that have been seen using DKIM.
>
> -Doug
>
>
>

---

From: hector <[email-masked]>
Date: Tue, 18 Aug 2009 07:19:13 -0400

> record in the verification side, still we should query for the policy

I believe that is an implementation question who may be policy centric 
and wishes to supports DKIM related policy concepts to help protect 
domains, and today, with protection as defined in the recently IETF 
published RFC 5617 (ADSP) standard.

I'm sure you will follow up on the new ADSP RFC, I wish to comment on 
a few highlights:

The ADSP lookup key:

    _adsp._domainkey.domain.example

where domain.example is the domain in the 5322.From: field.

ADSP has three policies:

    dkim=unknown      ---> equivalent to Domainkey policy o=~
    dkim=all          ---> equivalent to Domainkey policys o=-
    dkim=discardable

discardable is the same as all but with an explicit author domain 
authorization for receivers to discard/reject an invalid author domain 
signature, including no signatures found.  No 5321 Bounce Requirement 
is required for failure to deliver after accepting a message - the 
message is "discarded!"

Regarding DNS lookup overhead, as you noted in section 8.4, I believe 
many of the DNS people here do believe and stated that there is little 
concern with policy lookups as most systems already do many DNS 
queries for many mail related, anti-spam reasons for anonymous 
incoming domains. Today DNS clients and Server caching resolves many 
of theses issues however it was recognized initial adoptions phases 
could yield a higher degree of policy lookup failure. I personally 
like to use SPF as an example, I don't think the system broke down 
when SPF was first introduced and was growing, and I believe SPF does 
have a higher processing overhead than a primitive DKIM policy record 
lookup where there is no recursion overhead unless SPF.

Nonetheless, RFC 5016 (Policy Requirements), attempts to assist here 
by providing a requirement for policy lookup in section 5.3 item 9:

   9.  SSP MUST NOT be required to be invoked if a valid
       first party signature is found.

It probably helps a little in reducing 1st party signature policy 
lookups. But IMV, it won't play a significant role in a world where 
there is a high degree of fraudulent legacy messages with no 
signatures, and as the roll out expands, a world with increased failed 
1st and 3rd party fraudulent valid signatures. In such a case, it 
could be that wasteful DKIM rehash processing (which does include 1 
DNS lookup anyway) could out pace any concerns over DNS Policy lookups
which in a good bit of the transactions there would be no need for a 
DKIM KEY lookup, just a DKIM policy lookup.

Anyway, ultimately, of course, we need to see how ADSP is adopted. I 
am more optimistic than most here. IMV, ADSP will it limited offerings 
is still useful to many, especially the millions of small to large 
private domains who IMV want exclusivity in there transactions and 
would like a first level of defense at a wider range of receivers 
using discardable domain fraud protection.

---

---

From: John Levine <[email-masked]>
Date: 18 Aug 2009 20:23:12 -0000

>at verification side as DKIM is derived from Domainkeys?

No.  ADSP is entirely optional, and I don't expect most DKIM implementations
either to publish or to query it.

R's,
John