To:
miekg@atoom.net (Miek Gieben)
Cc:
Mike.StJohns@nominum.com (Mike StJohns), dnssec@cafax.se
From:
Bill Manning <bmanning@isi.edu>
Date:
Mon, 10 May 2004 16:04:12 -0700 (PDT)
In-Reply-To:
<20040510190503.GA1978@atoom.net> from "Miek Gieben" at May 10, 2004 09:05:03 PM
Sender:
owner-dnssec@cafax.se
Subject:
Re: dnssec: resolver - application communication
% well, for one, it was the "problem" of applications going directly to % the authoritative servers that lead to some rethinking. Secondly I % believe that DNSSEC is here to give us detecting of attacks. So % consider the following ssh example (as also used somewhere else in % this thread): % % a user connects for the first time to a remote machine. Thanks to % DNSSEC an attack is detected and a SERVFAIL is generated. Thanks to % this the user will be unable to use ssh (for this host). Mission % accomplished... Er... why am I uncomfortable w/ this example? (trust is not transitive, trust is not transitive, trust is not..) DNSSEC allows one to validate the chain of delegations. The use of application specific keys, tied to the end of a custody chain is distinctly different. % o SERVFAIL is too overloaded, % o We need something like the CD-bit, that will return an entire chain % of trust, which consists of the RR's you specified above: ALL keys, % ALL DSs, ALL RRSIGs, and the RRset, % o A library/daemon that can handle this, % o Standarization of the errors in DNSSEC. % o .... Oh yeah.. % % grtz, % --Miek % % -- % today's fortune: % People with narrow minds usually have broad tongues. % -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).