Subject: Re: Q-10: Reaction to "Silly" NXT's

From: Edward Lewis <[email-masked]>
Date: Mon, 2 Jun 2003 15:26:34 -0600

At 13:28 -0400 6/2/03, David Blacka wrote:
>Yes, a zone that uses NXT records with these "silly states" is pretty much
>making the choice to essentially be insecure for those not aware of the
>experiment.

I think the "damage" is more localized than Derek describes.  If just 
one opt-in span exists in a zone, then the "security damage" is 
restricted to just the name holding the silly NXT and all names up to 
the next signed name.

Unless I am misinterpreting something in the opt-in draft.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Digital cameras are to film cameras as Etch-A-Sketches are to canvases.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Mon, 2 Jun 2003 15:47:55 -0600

At 17:42 -0400 6/2/03, Derek Atkins wrote:
>No, that is correct...  However I think most people who are interested
>in opt-in would want to use it over the whole zone, not just one name.
>And by using a silly-state you've not only confused the issue between
>the "signed" nodes, but you've just made yourself even less secure
>than with opt-in because you now ignore the security of the "signed"
>nodes, too!

If I as for www.example.com and example.com has a DS RR, what's in 
the response from the com. server?

When would I see the example.com.'s upper NXT appear in a response?

---

From: Derek Atkins <[email-masked]>
Date: 02 Jun 2003 17:42:14 -0400

-derek
-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Derek Atkins <[email-masked]>
Date: 02 Jun 2003 18:04:50 -0400

Edward Lewis <[email-masked]> writes:

> If I as for www.example.com and example.com has a DS RR, what's in the
> response from the com. server?

Do you want to know the legitimate response or what you might actually
see?  Well, the .com zone would probably have the following records:

        example.com. ns ..
        example.com. nxt foo.com. ns ds sig <other-bits>
        example.com. sig (nxt)
        example.com. ds
        example.com. sig (ds)

A legitimate response would give you:

        NOERROR
        example.com. ns ..
        example.com. ds
        example.com. sig (ds)
        <glue>

> When would I see the example.com.'s upper NXT appear in a response?

An attack?  An attacker could aquire the nxt/sig(nxt) from some other
query and respond with it to your query:

        NOERROR
        com. soa ...
        example.com. nxt foo.com. ...
        example.com. sig (nxt)

TSIG only helps if it's a protection between you and your trusted
recursive server, but it doesn't help if the attacker feeds this
response to that recursive server.  So if you assume a silly-state NXT
do you accept this empty answer or do you consider it bogus?

IMHO, this should be considered a bogus response and
dropped/flagged/logged.  However it's unclear what to do in the case
of your silly-state text.  When does silly-state take precedence and
when does it not?

-derek

---

From: Edward Lewis <[email-masked]>
Date: Mon, 2 Jun 2003 16:19:11 -0600

>A legitimate response would give you:

Modulo breaking this into sections, there is no NXT there to show the 
"silliness".  So I don't see a problem.

>of your silly-state text.  When does silly-state take precedence and

If the only time in which I would see the NXT is when the message is 
part of an attack, then, well, the resolver should react to the 
message as evidence of an active attack.  Processing/evaluation 
stops, there's no examination of the silly stateness.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Derek Atkins <[email-masked]>
Date: 02 Jun 2003 18:32:37 -0400

Ed,

> "silliness".  So I don't see a problem.

Well, sure.  The problem I have isn't in the handling of legitimate
data, the problem is the handling of error cases.  Of course
legitimate responses are fine.  But if all responses were always
legitimate we wouldn't need DNSSec, would we? ;)

> message as evidence of an active attack.  Processing/evaluation stops,
> there's no examination of the silly stateness.

But this is exactly my point.  If you're going to act as if it's an
attack, then you need to ignore the silly stateness..  That means that
it should ignore the silly-stateness, which is what I've been saying.

The problem is that the packet doesn't have the Evil bit set.  The
resolver doesn't know it's under attack.  It just receives an answer
that looks like this and has to interpret it.  So, what does it do?
First it tries to cryptographically verify the NXT/SIG.  Assume it
verifies (the crypto is ok).  Then what?  Could you please fill in the
rest of the verification process (and include whatever silly-state
tests you'd include).  Please be explicit with the tests?

IMHO, whatever the process is, it MUST determine to drop the packet as
bogus.  IMHO this "response is bogus" result should happen regardless
of the silly-stateness of the NXT.

-derek

---

From: Edward Lewis <[email-masked]>
Date: Mon, 2 Jun 2003 16:43:34 -0600

At 18:32 -0400 6/2/03, Derek Atkins wrote:
>But if all responses were always

Depends on what you mean my "legitimate."  Legitimate with respect to 
the protocol?  Legitimate with respect to the data?

Don't confuse protocol correctness with data integrity.

DNSSEC only says that the covered RR set was "as is" when the signer 
spit out the signature.  DNSSEC does not say whether the RR set is 
credible in a given response.  DNSSEC does not say whether the RR set 
is germane to the query issued.

---

From: Derek Atkins <[email-masked]>
Date: 02 Jun 2003 20:25:05 -0400

> the protocol?  Legitimate with respect to the data?

Yes.  They are linked and are not separable.

Ok, yea, they are separable... But looking at the protocol without
looking at the data is like asking whether wires can carry electricity
without asking whether it's 110 or 220 volts and 50 or 60 hertz.

>From the resolver's end how do you tell the difference?
Isn't that what DNSSec was all about?

> is germane to the query issued.

Sure it does..  The whole 2535 processing system is about how to
validate whether a response you got is valid based on the question
you asked.  Integrity and validity are inextricably linked in the
process.

-derek