Subject: RE: [ietf-dkim] Re: Last Call: 'DomainKeys Identified Mail (DKIM)Signatures' to Proposed Standard (draft-ietf-dkim-base)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 20 Nov 2006 10:09:44 -0800

> From: John Levine [mailto:[email-masked]] 
> Sent: Sunday, November 19, 2006 11:48 AM
> To: [email-masked]
> Cc: Hallam-Baker, Phillip
> Subject: Re: [ietf-dkim] Re: Last Call: 'DomainKeys 
> Identified Mail (DKIM)Signatures' to Proposed Standard 
> (draft-ietf-dkim-base)
> 
> >In terms of consensus I don't think anyone would challenge the claim 
> >'DKIM key records do not require prefixes'.
> 
> I hope you meant to say wildcards there.

Yes good catch!

> It is possible and perhaps useful for testing to wildcard the 
> selector part of a prefixed DKIM key record, but in general I 
> concur with your analysis of the DNS aspects of DKIM.

There may be operational reasons to make use of the existing wildcard features of the DNS. But there is no requirement that would require a default key record to be returned.

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 20 Nov 2006 17:08:11 -0800

> From: Robert Elz [mailto:[email-masked]] 

> However, if this ...
> 
>   | It is somewhat unfortunate that the choices draft does 
> not take a more
>   | realistic approach to deployment constraints. This has 
> been raised on
>   | numerous occasions but the fact is that the best 
> information we have
>   | available is the information presented during the MARID 
> working group
>   | which indicated that at the time only 50% of the deployed DNS
>   | infrastructure does in fact support new RRs in a production mode
>   | (i.e. you can add the RR using the standard admin tool and the
>   | configuration will survive a reboot).
> 
> is an example of the quality of argument that is swaying the 
> consensus of the group, then the IESG (and IETF as a whole) 
> should be taking a very very close look at what is being 
> produced, and most probably, simply abandoning the WG in question.

In my book deployability trumps pretty much everything else. Deployability is what I want from a standards process in the first place.

Deployability is not the only criteria of course. It is also a good idea if the proposal will fill its intended function and it is certainly a good idea to avoid deploying something we might regret later.

But I make no appologies for insisting that deployment in the real world is one of the most important considerations that a Working Group must consider. We have had enough of projects that remain unused after a decade or more because insufficient thought was put into deployment.

Deployment is a much harder problem than meeting the technical goals.

In this case we have two approaches that are equally effective in meeting the functional goals. One has considerably better deployability. Therefore it is an entirely justifiable engineering decision.

> Whether it is possible to add a new RR type to an existing 
> DNS server (without upgrading it) - whether due to design 
> limitations, or bugs, is 100% irrelevant to the question of 
> which is the best way to add data to the DNS.

The limitations in the DNS servers is due to the need for deployment of new RRs being insufficiently considered in the original DNS design. 

Product cycles in our industry are long.

> If someone wants to add a new RR type to their DNS server, 
> and their server cannot handle it, then they can simply 
> replace/upgrade their server.

You can't do that if it is integrated into your O/S.

It is not the case that the whole world runs on BIND or wants to.

> This is no different than anyone else who wants new 
> functionality in a system that doesn't support the new stuff, 
> and nothing at all remarkable.
> 
> The same is true at the other end - if the system that wants 
> to perform a lookup of a DNS RR type cannot, because either 
> its resolver, or local DNS cache (or API, or anything else) 
> doesn't support the new RR type, then they need to upgrade 
> whatever is imposing the restriction to something newer, that 
> can handle the new lookup.

You have just aritrarily locked into a double ended deployment trap. Neither side can have value until the other completes deployment.

> If this were not true, then you may as well abandon DKIM now 
> - after all, my mailer, and most other site's mailers (I'd 
> hazard a guess, way more than 50% of the deployed mailers) 
> don't support DKIM, and, by the argument above, that's enough 
> to render the technique unrealistic.

We have carefully considered the depolyment issue there. If you don't support DKIM you get no benefit from it. But equally importantly you do not suffer a penalty which is unfortunately the case for the MIME based security encodings.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 21 Nov 2006 11:41:47 -0800

> I don't want to continue this, especially as I don't care 
> about this protocol, but ...

>   | In my book deployability trumps pretty much everything else.
> 
> It certainly is important, but being correct (ie: working) is probably
> a little more important...   Avoiding breaking other things is also
> more important.

Which is why the working group has had extensive discussions with the DNS Directorate on this topic. You will be glad to know that you need not worry about it.