To:
"Stephan Jager" <stephan@nlnetlabs.nl>
Cc:
dnssec@cafax.se
From:
Edward Lewis <lewis@tislabs.com>
Date:
Tue, 7 Aug 2001 04:57:11 -0400
Delivery-Date:
Tue Aug 7 10:24:26 2001
In-Reply-To:
<200108070808.f7788DgT017814@catv8013.bij.ons>
Sender:
owner-dnssec@cafax.se
Subject:
Re: IETF: Goal & resolving discussion for this evening.
A hastily written response, suitably jet-lagged well into the morning...
Here's a break down on what DNSSEC covers.
One part of what DNSSEC does is "make sure" that data entered by one admin
is what the resolver delivers. If an application gives the DNS admin bad
data, the same bad data should arrive at the other side. (DNS can't
improve the data, with or without the security extensions.) E.g., what
happens if the IP address in DNS differs from that in ifconfig?
"Make sure" means - if the data is diddled in transit, the diddling should
be apparent.
The one feature of DNSSEC that hasn't been exercised much is the use of
immaterial signatures. These are signatures over data that are supplied by
an application and are not used by the DNS itself. The KEY may be one that
is not a zone key, or one that is absent from DNS altogether. (We've done
mental exercises with this in the pre-BIND days.)
+-------------+ +-------------+
| Application | >========= "Immaterial Signatures" =========> | Application |
+-------------+ +-------------+
| |
== Boundary of DNS Security (What goes in will come out) ==
\ /
+------------+ +---------------+ +----------------+
| DNS Server | >=KEY/SIG=> | DNS Recursive | | Stub Resolver |
+------------+ +---------------+ +----------------+
| | | |
\ / \ /
------------------------- -----TSIG/IPsec------
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis NAI Labs
Phone: +1 443-259-2352 Email: lewis@tislabs.com
You fly too often when ... the airport taxi is on speed-dial.
Opinions expressed are property of my evil twin, not my employer.