[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