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

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

---

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

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

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.

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

I don't agree with that, but that's neither here nor there right now.
It might not have been much considered in some of the early implementations,
but that's not "DNS design".

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

Of course you can - you can upgrade the OS, or you can move the DNS
server to somewhere else - if the benefit from upgrading is significant
enough to you that it is worth it, then you do it.   One of the problems
I see on occasion, is advocates of protocols attempting to pretend that
deploying something new is just so cost free that everyone should do it,
even if they don't really see much benefit to themselves in it.

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

Trap?   This is networking, almost everything requires both ends to
deploy to get any benefit (there are a few exceptions, but not many).

DKIM is certainly not an exception (regardless of the DNS RR type).  The
sender of the message (and owner of the DNS server) has to send the
message signature, and the receiver of the message (and owner of the DNS
client) has to verify it.   If either don't participate, no-one gets
any benefit.   How much effort that deployment takes can be debated, but
compared with the requirement to get an MTA that computes the signatures,
including correctly verifying the original sender of the message (probably
meaning requiring authenticated submission, or similar), and deals with
managing the security of its private key in a rational way, while
simultaneously keeping it available for signing,  would seem to totally
swamp what's required to install a DNS server that can handle one new
RR type - note: the server doesn't (necessarily) need the ability to
handle arbitrary new RR's, just the one that DKIM would use.  That's one
(or two) DNS servers, as compared to every MUA client in the organisation
potentially...   Similarly, at the receiver, you just might need a new
DNS cache, but you certainly need an MTA that can verify the signature,
and MUAs that make use of the authentication information to convey the
authentication information to the user in a meaningful way.

The DNS part of this is the trivial part (and in some cases, is nothing.)
Certainly adding a new RR type would increase the cost of deployment,
but my estimate would be for most people, by a comparatively small amount
(compared to the total deployment cost).

If there's a real benefit from this, that cost is easily justified.
It's only if you're worried that most people won't actually believe in
the benefit that you start to worry about small extra costs, as there any
cost can be a killer.

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

No comment on MIME, but the rest of that is not corrrect (ignoring the
first sentence).   If you're sending me DKIM signed mail, you're inflating
the volume of the message, regardless of whether or not I take any notice
of the extra data.   That's a cost (a penalty).  It probably isn't significant,
but it is clearly not nothing.   Then there's the user confusion, in DKIM
unaware receivers, of having that extra header (potentially) thrust
at them.   Another cost.   Don't underestimate.

kre

ps: this is enough from me on this topic.