[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Transition from 2535 to opt-in
On Wed, Dec 05, 2001 at 11:50:53AM +0100, Ted Lindgreen wrote:
> My personal conclusion from this line of thinking is:
> If ("IF") we go for Opt-In, then go for it all the way, and
> just forget authenticated denial. This will really make
> implementation and deployment much simpler, and thus speed
> it up.
Without NXT records and authenticated denial, there is no security. Imagine
the following subset of the COM zone, in an Opt-In world:
; foo1.com is secure
foo1.com NXT foo3.com NS SIG KEY
foo1.com NS ns.foo.net
foo1.com KEY ...
foo1.com SIG KEY ...
foo1.com SIG NXT ...
; foo2.com is not secure
foo2.com NS ns.xyz.net
; foo3.com is secure
foo3.com NXT foo4.com NS SIG KEY
foo3.com NS ns.abc.net
foo3.com KEY ...
foo3.com SIG KEY ...
foo3.com SIG NXT ...
Let's say you do a query for www.foo3.com, and your ISP wants to hijack the
query and make it appear that foo3.com is not secure and has a nameserver of
ns.yourisp.nl.
Without NXT records, it can formulate a response like
FOO3.COM. NS NS.YOURISP.NL
NS.YOURISP.NL A 1.2.3.4
But with NXT records, that doesn't work. As shown in the example section of
the Opt-In draft, a response for an insecure domain would have to include a
NXT record showing it was not secure. In other words, it would have to look
something like:
FOO3.COM. NS NS.YOURISP.NL
NS.YOURISP.NL A 1.2.3.4
FOO1.COM. NXT FOO4.COM. NS SIG KEY ; this record proves that there is
; no secure domain between foo1
; and foo4; in other words, it
; shows that foo3 is not secure
FOO1.COM. SIG NXT ...
; [some other RRs omitted for simplicity]
And your ISP can't do this, because it can't create the SIG record.
--
Mike Schiraldi
VeriSign Applied Research
smime.p7s