IETF: Goal & resolving discussion for this evening.

["Stephan Jager" <stephan@nlnetlabs.nl>]

Hi,

I've written the below text about the goal and resolving within DNSSEC.
We could use this text to get a discussion about both topics at the DNSSEC
meeting at 18.30 today.

Stephan Jager
NLnet Labs

----

In the dnssec intro draft of Scott and Massey, there is one goal defined for
DNSSEC:

"The goal of the DNS security extensions is to protect the integrity of DNS
data and provide a means of source and data authentication."

Furthermore, there are three different services described, data origin
authentication and integrity, key distribution and transaction and request
authentication.

Those three services are defined to support the goal of DNSSEC, but seem to
be frequently confused with the goal itself. A PKI is a good example. In the
services, key distribution sounds like it. Since DNS is such a crucial point
of the Internet, it should not be bloated with things which are not needed
to provide basic DNS services.

Other then goals, there are limitations for DNSSEC. The first one is how far
one can use this integrity. If you know for sure what a certain RR is, can
you trust it well enough to do secure transactions? The only thing you know
for sure is that a certain item from a database is not corrupt.

Therefore if you want security at the application level, you need to
have security at the application level, and not at the name lookup level.

Integrity is about finding out if data might be wrong. False data must be
detected. There are two different views for integrity at this moment:

- Secured zones are common case, bad zones can be detected
- Unsecured zones are the common case, some are secured.

The first one is as DNSSEC is right now, and conforms to the goal as
mentioned by Massey and Scott.

It seems that with opt-in and nosig we are drifting towards the second view.

--

Looking at it from the resolver point of view.

Right now the common way to resolv is a stub resolver together with a
forwarding nameserver. When DNSSEC is deployed this is likely to be changed
with paranoia stub resolvers. They will tend more towards to full-service
resolvers.

When a current stub resolver would point to a secure forwarder which does
all the validating, integrity will be maintained. Since the forwarder
doesn't have bad data, the resolver never gets bad data, so it keeps in
check with the main goal. The means of source authentication can still be
done, but an application must not rely on this.