To:
Simon Josefsson <jas@extundo.com>
Cc:
Edward Lewis <lewis@tislabs.com>, dnssec@cafax.se
From:
Edward Lewis <lewis@tislabs.com>
Date:
Tue, 14 Aug 2001 15:09:03 -0400
Delivery-Date:
Sun Aug 19 07:32:03 2001
In-Reply-To:
<iluvgk0ds37.fsf@barbar.josefsson.org>
Sender:
owner-dnssec@cafax.se
Subject:
Re: Alpha draft of SEC RR
At 7:31 AM -0400 8/7/01, Simon Josefsson wrote: >One must be extremely careful when designing a protocol that is able >to negotiate its security parameters, just look at the complexity of >TLS. The SEC RR is not intended to negotiate, just inform. >...but maybe the recursive situation isn't necessary. I don't see why >the SEC RR is needed by the resolver to determine if NXT or NO is >used. I didn't see anything in the draft that explains that either. The thought behind the SEC RR is that in order to be secure, you must first know what to expect. Your description of using NO/NXT/some other is workable if and only if there is some form of authenticated denial. If there is an option to not use NO or NXT or anyother auth-denial, subverting this service is easy. (Whether a zone without auth-denial is attacked by some one inserting auth-denials, or vice versa, some one attacking by stripping auth-denials - which can be done without the private key.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.