Subject: DNSSEC-lite - thoughts

From: Mike StJohns <[email-masked]>
Date: Sun, 26 Nov 2006 20:18:12 -0500

This is the first of 5 messages on the general subject of the 
DNSSEC-lite ID and the presentation I gave at the IETF.  I decided to 
break down the various issues raised during the IETF into 4 separate 
threads to make tracking things a bit easier.

I was somewhat amused at the breadth of reactions to my 
proposal.  The pros were generally in the "nice idea, lets see where 
it goes" camp.  The cons were "why are you reopening this can of 
worms,"  (" we talked about this 3 years and 6 years ago and decided 
against it" | " you'll cause confusion and further delay the real 
DNSSEC - and we were almost done" | "it's a bad idea, of course we 
need provable non existence") - I'm sure I missed a few here.

I agree that PNE (provable non-existence or the current DNSSEC) can 
do things that SO (signature only) can't do - and I think completing 
and fielding it may be useful.

Unfortunately, I'm still having problems with the cost/benefit 
analysis both for the protocol design as well as for the cost of 
running a PNE zone (more specifically, a delegating PNE zone such as .COM).

Let me clarify a few things.  I'm NOT advocating replacing DNSSEC 
with DNSSEC-lite - I think there's a niche for both of these and I 
believe that we really need to complete whatever work that's 
currently in progress (e.g. NSEC3).    Specifically, PNE's emphasis 
or operational model has always been about providing intermediate 
validation (e.g. at the cachine resolver) where SO's emphasis has 
been to enable the end-applications.  The other 4 threads will 
address these and a few other topics.

Mike

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Nov 2006 12:27:22 -0800

> [mailto:[email-masked]] On Behalf Of Mike StJohns

> proposal.  The pros were generally in the "nice idea, lets 
> see where it goes" camp.  The cons were "why are you 
> reopening this can of worms,"  (" we talked about this 3 
> years and 6 years ago and decided against it" | " you'll 
> cause confusion and further delay the real DNSSEC - and we 
> were almost done" | "it's a bad idea, of course we need 
> provable non existence") - I'm sure I missed a few here.

While I very much agree that any deployment is better than none this is not the deployment issue I would concentrate on.

Empirically bugs in crypto protocols matter far less than most people imagine. SSL and WEP were both botched in their original form, they are today the two most widely deployed and used cryptographic security protocols.

In this case I don't think that removing NXT/NSEC3 processing reduces the complexity enough to persuade end entities to perform checking that otherwise do not. NSEC3 addresses the issues concerned with signing zones to the saisfaction of the deployment critical parties. So I don't think that DNSSEC-Lite is really giving the traction you want to solve what is clearly a real issue.

Instead I would suggest that you look at taking public key crypto out of the DNS transaction loop entirely at the end entity.

Do all the public key intensive work at the local DNS resolver, secure the link between the resolver and the end-entity using TSIG.

All you need to complete that set up is a lightweight means of establishing a shared secret between the end-entity and the local DNS resolver. Here is my point, do NOT use KEYPROV for this, I looked into this idea as it was suggested at the BOF. 

KEYPROV is about provisioning shared secrets for use as trust anchors. You _can_ use it to provision other shared secrets but its not optimized for that use case. In this case we can distribute the trust anchors through the DNS and provide a cleaner user interface.

Since I have already done the work trying to scope out KEYPROV my analysis follows, others can decide if an adjustment of course at this late stage would make sense:

Since you would need a custom resolver and client to perform the key agreement you might as well use custom RRs in this instance. You would need a key record for the server public key, some form of policy flag to say that TSIG was always on offer and to advertise the set of key agreement mechanisms supported.

When the client boots up for the very first time it reads the DNS, discovers the policy record, master public key and performs an ephemeral key exchange and caches the result. This is then used for subsequent TSIG transactions.

The policy would also tell the client what to do on a change to the master key (refuse to act, warn the user, silently ignore). You might want to have limited DNS path processing to verify the master public key.

The advantage of this architecture over DNSSEC to the end entity is that you have rather more slack in the system that can help you navigate ad-hoc patches than might be required during deployment. For example the network operator can manage dependence on 'look-aside' key servers at the network level.

As far as processing goes the DNSSEC architecture was the only one feasible with 1995 computation power. Today it may make more sense to do CPU intensive work at the DNS server than on edge devices. While PCs will continue to increase in power there will always be a large class of device served by 16 bit processors (and smaller!) running at modest clock rates. As processing costs are reduced the number of cpu enabled devices increases. Fortunately the complexity of TCP/IP itself puts a lower bound on the processing power available and for practical purposes we can at least expect a 50MHz 16 bit processor.

As I said I am not entirely convinced that the deployment issues raised are significant enough pain points to require addressing now. I am sure that over time there will be an urgent need to support DNS security on a class of processor that is not really up to DNSSEC. This is particularly the case in Domain Centric Administration where I propose performing every function traditionally performed in UPnP type schemes using Ethernet broadcast using the DNS (except for obvious reasons, DHCP).

I am sure that when we come to this class of device that DNSSEC-Lite will not reduce the burden significantly enough to be worth the increment over DNSSEC. If we are to do a low CPU power route I think we have to change the architecture radically, either using the TSIG plus key exchange mode suggested or something else that is also a radical departure from DNSSEC.