Re: IETF: Goal & resolving discussion for this evening.

[Russ Mundy <mundy@tislabs.com>]

Stephan,

I may be misunderstanding the intent of your mail but it certainly appears
to me that it is more appropriate to discuss the items you list in an IETF
charted WG (such as dnsext or dnsop) rather than the informal group that is
meeting this evening.

Perhaps as deployers & users of DNS security, it might be worth determining
if we have some common views on some of the items in your list.  If we have
reached the same (or similar) conclusions, we can then describe these as
'common deployer/user conclusions' when the itms are discussed in the
thursday dnsext meeting.  Since we'll be meeting after dnsop WG mtg, things
related to that group should be posted on the dnsop mail list.

Russ Mundy
NAI Labs

At 10:08 AM +0200 8/7/01, Stephan Jager wrote:
>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.