Date: Mon, 20 Nov 2006 17:08:11 -0800
From: "Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>
Message-ID: <198A730C2044DE4A96749D13E167AD37E7E66B@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf