Subject: RE: [ietf-dkim] Considerations for Development of DKIM Policy Language

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 15 Jun 2006 18:20:54 -0700

> A few comments below.  Hope I'm not too late if you're 
> submitting this as an individual I-D this week.

That depends on whether it bounces again.

> Use of the word "policy".  There are so many things that are 
> called "policy", and I'm not sure which ones you mean here.  
> You might want to introduce what's included in that 
> definition, and importantly what's not.  An example of what's 
> not might be a security policy saying that all computers 
> connected to your LAN must be running current anti-virus 
> software.  There's also the concern about how imperative (vs.
> declarative) such policies may be, given the recipient's 
> freedom to do as they choose and possible local legal 
> considerations.  That's why I expect we'll end up with the 
> word "practices".

We were invited to comment on the policy component as criteria for speaking on the issue at the BOF. I am quite happy to call it anything else.

Lets call it the Splunge.

> Section 3.1, paragraph 2: What do you mean by "constant recourse"? 

The requirement to have a policy record for each protocol approved by the DNSEXT working group. Given the behavior of the co-chair at our last IETF meeting I for one do not want to have as little exchange with that group as possible.

> Later in the section, what constitutes a change to DNS 
> infrastructure? 

Any change that requires changes to the configuration of existing servers.

> Is creation of a new RR included?

Yes, unless the DNS infrastructure as deployed is able to handle it without any changes to either software or configuration.

> Section 3.3 example: Why can't this sort of information be 
> included in key records published by the domain?

Because the key record only describes the key, not the domain in which the key is used.

If SHA-1 is broken and a zone moves to dual signing its mails with RSA-SHA1 and RSA-SHA512 an attacker can perform a downgrade attack on the message by only creating the fake RSA-SHA1 signature header.

The signature policy has to describe the minimum characteristics of the signature.

Obviously a key record cannot say anything about the unsigned message which is the most important case where we need a policy record.

> Section 3.4, paragraph 1:  "principle" -> "principal"  As you 
> later mention, even if a new RR is defined, that doesn't 
> remove the need for heuristics or search strategies (although 
> they may be simpler).

That depends.

If you do it my way you have an algorithm guaranteed to terminate in three steps in all circumstances without exception. That is not a heuristic or a search strategy that creats a DoS issue.

> Paragraph 2, what you mean by the "dynamic DNS component"?

The Microsoft DNS server accepts Dynamic DNS updates and updates via the registry APIs.

Some folk intent on demonstrating that Windows DNS server does too support new RRs demonstrated that it was possible to inject the bit patterns for new RRs via DNS dynamic update. The problem being that the changes are not saved out to the static DNS configuration file.

So what we end up with is a network administration nightmare, a server that will change the network configuration unexpectedly when it reboots. Try administering that in a production environment.

When Microsoft say that their DNS server does not support new RRs they mean that they have performed regression tests and identified specific failures that are incompatible with production use.

> Policy discovery strategy example: As SSP is currently 
> written (subject to change, of course!) the lookup would be 
> to _policy._domainkey.alice.example.com.  Alice is a 
> subdomain, right, and not that person at example who so often 
> tries to communicate securely with Bob?  The example doesn't 
> describe what happens if the result is NXDOMAIN vs. if it's 
> NOERROR with no answer (or is this the same?)

I think we are all OK with defining policy for alice.domain.com.

The problem is defining a policy for *.domain.com so that we can discover the policy for:

A.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.domain.com

Which may not exist of course.

> I'm really confused as to why the use of a PTR would help 
> here.  If example.com wants to publish a policy, and some 
> host named alice.example.com exists,  and a message is sent 
> from [email-masked], it still won't find 
> example.com's policy.  We don't want to require that an extra 
> record be published with every A record in the domain!

*.domain.com PTR _default.domain.com
_policy._default.domain.com TXT "Never sends mail"

1) Lookup (_policy.A....z.domain.com, TXT) = NULL
2) Lookup (a....z.domain.com, PTR) = "_default.domain.com"
3) Lookup (_policy._default.domain.com)

The issue about the A record is irrelevant, the DNS wildcards don't work the way you want them to regardless of whether or not you use a new RR. A DNS wildcard only matches a DNS node that has absolutely no records.

So regardless of the approach you have to use synthetic wildcard expansion when you do DNSSEC or attempt a zone transfer.

This is why you want infrastructure so every protocol can use the same PTR:

@.domain.com PTR _default.domain.com
_dkim._default.com TXT "no mail"
_smpp._default.com TXT "always offer TLS"
_http_default.com TXT "always offer TLS"

Where @ stands for synthetic wildcard is much better than:

@.domain.com DKIM "no mail"
@.domain.com SMTPP "always offer TLS"
@.domain.com HTTP "always offer TLS"
....

In the future I expect upwards of 100 routinely used policies

The PTR indirection mechanism adds only one record per node which is not an excessive overhead.

The define a RR for every protocol policy approach does not scale for new protocols it is utterly broken.

> In step 3 of your example, is this the point at which the 
> policy for DKIM is differentiated with that of other 
> services?  Does _dkim become _emailtls to retrieve the policy 
> having to do with use of TLS by MTAs?

The same prefix is used to refer to the protocol in both places. So first we look for _prefix at the domain node itself, if it is not found we attempt to follow the politer and then look for the node.

The prefix can be _policy._domainkey. Or _dkim or whatever people want to do. 
 
> Section 4.1, DKIKM -> DKIM
> 
> Hope this helps; this was a quick and not-so-thorough review.

It was very useful, it has helped me discover that my approach provides an advantage besides not having to wait for deployment of new DNS infrastructure or wait for the agreement of a working group that has taken ten years to deliver on its promise of DNSSEC. 

		Phill

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Jun 2006 20:59:25 -0700

At 6:20 PM -0700 6/15/06, Hallam-Baker, Phillip wrote:
>The requirement to have a policy record for each protocol approved 
>by the DNSEXT working group.

Is that documented anywhere? I ask because we have a strong argument 
against the need for it, namely that we have created our own 
unambiguous namespace with the _domainkey label for the base protocol 
and the _policy for the now-expired SSP protocol. If "_policy" is too 
loaded, the label could be changed to "_dkim_policy".

Unless there is a good technical reason why we can't use our own 
definition of structured TXT records in our own protected namespace 
(and none have been offered), we shouldn't even start thinking about 
using new RRtypes.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html