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: Sun, 19 Nov 2006 07:11:18 -0800

> [mailto:[email-masked]] On Behalf Of Cullen Jennings
 
> On Nov 14, 2006, at 11:03 AM, Paul Hoffman wrote:
> 
> > At 4:17 PM +0100 11/14/06, Joe Abley wrote:
> >> For the benefit of those who do not follow dnsext closely, what 
> >> friction do you expect?
> >
> > As Eric stated in his message, we should not rehash old arguments.  
> > This has been beaten to death on the DKIM WG mailing list. As 
> > expected, different people had different (and, in this case,
> > strongly-held) views, but consensus was reached and agreed 
> to by the 
> > AD and with the DNS folks.
> 
> To avoid repeating this debate, can someone post some summary 
> information on this particularly including which exact people 
> came to consensus about this. I'm particularly interested in 
> if the consensus included the contributors to 
> draft-iab-dns-choices since that has been raised in LC comments.

Choices sets out four possibilities for extending the use of the DNS and sets out pros and cons for each. 

The DKIM group has taken account of this information and has noted that since key records do not require wildcard capability the third option of prefix records is most appropriate since they provide all the functionality required and are compatible with the DNS infrastructure as deployed.

The use of a new DNS RR is being considered for policy records which do require wildcard capability.

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). Things may have changed since but the onus should be on those who claim the situation has changed to prove it.

In terms of consensus I don't think anyone would challenge the claim 'DKIM key records do not require prefixes'.

I believe that there is also universal consensus amongst those who have read choices and DKIM that the limitations of prefix records set out in the draft do not apply.

The only points on which there is disagreement are the question of the extent to which the deployed DNS infrastructure really supports new RRs and whether this would be a significant handicap in the case of DKIM deployment.

The first point is an empirical one, the second is subjective. We agree to disagree.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Robert Elz <[email-masked]>
Date: Tue, 21 Nov 2006 04:11:12 +0700

Date:        Sun, 19 Nov 2006 07:11:18 -0800
    From:        "Hallam-Baker, Phillip" <[email-masked]>
    Message-ID:  <[email-masked]>

I don't care about this draft one way or the other, I have long since
abandoned any hope of any kind of technical solution to spam being possible
(many things help as long as they're not widely used - as soon as they
become widely used, the spammers find a "workaround" - this is after
all their income that is being affected...)

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.

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.

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

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.

Of course, that's absurd.

The issue that one needs to consider, is whether some third party's
system is either going to interfere with my use of the new functionality
(examples of firewalls in ISPs and similar are places where this kind
of consideration might apply), or whether the new functionality is going
to cause problems for third party systems.   If those kinds of problems
are identified with a proposed solution then that's a good argument to
look elsewhere.  But "the users who want to use it would have to upgrade"
is not an argument against anything - at most, between two otherwise
essentially identical approaches, it may sway the choice slightly in one
direction or the other, but in the face of any other reason to prefer one
solution to the other, this one (requiring upgrade) would (or should) be
discounted.

kre

---

From: Dave Crocker <[email-masked]>
Date: Mon, 20 Nov 2006 13:49:52 -0800

Robert,

Howdy.

> However, if this ...
...
> close look at what is being produced, and most probably, simply abandoning

What this sub-thread is mostly an example of is why it is generally unproductive 
for a Last Call to try to review the details of a working group's decision 
process.

For any interesting working group effort there are many interesting decisions. 
("Interesting" is intended as a compressed form of saying "complex, difficult, 
controversial and requiring protracted consideration.")

IMO, interesting decisions are where working groups do their real work. They are 
what distinguishes a working group effort from a brief discussion on the open 
IETF list. That makes it problematic to try to later re-create the wg discussion 
on the ietf list.

Choice of DNS records definitely falls in the category of interesting, and 
qualified for it long before DKIM.

Let me suggest that what ought to be relevant to the Last Call is whether the 
working group considered the question carefully?

It did.

It might further be relevant to ask whether that decision was made in 
consultation with -- or reviewed by -- content specialists?

It was.

Any one effort to summarize that protracted consideration is primarily going to 
serve exactly the unintended purpose that your response reflects, namely to 
invite more debate about process than content.

The very last thing that we ought to try is to place the DKIM effort into the 
middle of a protracted, and continuing, debate about DNS enhancement.

There are at least two other venues already established for that in the IETF.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Nov 2006 22:03:37 +0000

Dave Crocker wrote:
> The very last thing that we ought to try is to place the DKIM effort 
> into the middle of a protracted, and continuing, debate about DNS 
> enhancement.

I agree.

In fact the DKIM WG asked for help from the DNS directorate and
got that help. Their advice is documented in the meeting minutes
from IETF-66. [1]

So I suggest that folks with remaining concerns on this might
take it up in some DNS forum (or at least change the subject
line:-)

Stephen.

[1] http://tools.ietf.org/wg/dkim/minutes?item=minutes66.html

---

From: [email-masked]
Date: Tue, 21 Nov 2006 09:59:10 +0000

> server cannot handle it, then they can simply replace/upgrade their 
server.

And if someone wants to leverage the DNS protocol and
DNS server software in order to operate a global 
distributed database, then there are no barriers to
doing this on ports other than port 53. The IETF barely
needs to be involved at all other than defining the
new RR.

But when someone suggests that port 53 servers should 
all support some new RR or anything else that is new, 
now we are talking about a major upgrade to the Internet's
mission critical infrastructure impacting millions of 
people worldwide. Here the IETF has a major role to play
and the IETF should tread very carefully.

In fact, the issue of port 53 services being such an 
important infrastructure leads me to think that the IETF
should freeze the DNS protocol definition for anything
that is not directly related to the job that port 53
servers MUST do. Things like DNSSEC are OK, but leveraging
DNS for a global distributed database are not.

Since there is great interest in using the DNS protocol
for a distributed database, it would help to fork the DNS
protocol and deal with this work in a separate WG and
using a separate port number. Such a WG might also consider
issuing a document comparing DNS and LDAP so that it
is clear to all, when and why you might choose DNS for a
distributed database over LDAP.

> a system that doesn't support the new stuff, and nothing at all 
remarkable.

Really, if they want new stuff in this system that 
doesn't support new stuff, they might as well stuff it
all in the TXT RR.

> to cause problems for third party systems. 

Defining a general-use DNS database protocol separately
from Domain Naming Services allows one to address all these
issues directly.

--Michael Dillon

---

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Nov 2006 10:51:37 -0800

On Nov 21, 2006, at 1:59 AM, [email-masked] wrote:

>> 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.
>
> And if someone wants to leverage the DNS protocol and DNS server  
> software in order to operate a global distributed database, then  
> there are no barriers to doing this on ports other than port 53.  
> The IETF barely needs to be involved at all other than defining the  
> new RR.

Any opinions on port 3450?  A DNSified name space of a peer to peer  
matrix offering data structures to navigate NATs.  Is this a perfect  
bot-net tool?  DNS on different ports might still involve the IETF,  
while offering little information for assessing risks.

> But when someone suggests that port 53 servers should all support  
> some new RR or anything else that is new, now we are talking about  
> a major upgrade to the Internet's mission critical infrastructure  
> impacting millions of people worldwide. Here the IETF has a major  
> role to play and the IETF should tread very carefully.

Design compromises for DKIM's TXT RR increases DNS cache allocations  
by 34%.  A label prefix for key rotation permits any number of keys  
per domain, even one per customer.  Per customer deployment of keys  
may have a dramatic impact upon DNS resources, where the scale of  
such deployment would exacerbate the TXT RR choice.  Signature roles  
are not identified and there are no limits on the number of  
signatures per message either.  The follow-on effort for DKIM expects  
matching From/signing-domains and DNS authorization records that are  
hunted when not found.

Being careful should mean making the most of a single signature/key  
without added searches.  An association scheme with a signing domain  
eliminates a need for a key per customer (or different originating  
domains), while also providing customers greater freedom of choice.   
Associations also ensure abuse-reporting goes to the transmitting  
entity.  An association/annotation scheme provides greater protection  
against phishing (even look-alikes), while also eliminating a need  
for DNS authorization scans.

Making poor follow-on choices are not really a fault of the DKIM  
concept.  However, caution is is often a distant concern in (futile)  
efforts to close a door that must remain open by design.  Even when  
DKIM signing is limited to the transmitting domains, verification of  
a signature should occur only when an associated and desirable domain  
affects message annotation or DSNs.  Unfortunately, building DKIM  
related obstacles for email might place DNS at risk.  This does not  
need to be the fate for DNS and DKIM, but it might be.

-Doug