Subject: revised proposal for defining the NXT

From: Edward Lewis <[email-masked]>
Date: Thu, 8 May 2003 09:44:50 -0400

This proposal is intended to fit into the appropriate DNSSEC document 
as part of the definition of the NXT record.  The motivation for this 
proposal is buried in the opt-in discussion, but the proposal is not 
centered around the promotion or dismissal of the opt-in proposal.

The philosophical underpinning of this proposal is based on the 
observation that the NXT RR, which needs the SIG RR to have any 
meaning, could claim that it itself and or the accompanying SIG RR 
(set) does not exist.  This would qualify as a "silly state." 
Furthermore, there is a sound reason to define the reaction to the 
resolver or verifier to the possibility of such a "silly state" and 
this proposal chooses one.

(Silly = saying that I don't exist, or that the one who is needed to 
vouch for my existence doesn't exist.)

This proposal is informal, it is not cast into RFC 2119 language to 
reinforce the need for discussion on this.

First rule.  (Speaker-side)

A compliant signing application will always set the values of the NXT 
and SIG positions of the NXT RR type code bit map to 1.  This silly 
state is not to be seen in normal protocol operations.  (Nor are any 
others, but that's not my concern right now.)

Second rule.  (Listener-side)

When a verifier sees 1's in BOTH the NXT and SIG positions, 
processing of the NXT follows the stated rules as we have already 
documented them.

When a verifier sees a 0 in EITHER the NXT OR the SIG positions, the 
verifier will take corrective action.  This proposal recommends the 
following action be specified as a MUST:  the verifier will first 
validate the NXT according to local policy, with the intent that the 
presence of the DS RR at the parent points eventually to a zone key 
that verifies the SIG (NXT).  Once the NXT is proven valid, the 
verifier then treats the remainder of the query as if the DS RR did 
not exist - essentially treating the query as traversing through or 
being answered from an unsigned zone.

Into the Future.

If the type codes for NXT and SIG are changed, the rules for the bits 
move with the type codes.  I.e., if, say, an NXTbis RR is used to 
prove non-existence, then the NXTbis position has this special 
meaning AND NOT the NXT position.  I.e., we are only protecting 
against silly states, not creating flags in the NXT bit map.

Discussion.

There are four options I have considered for a reaction to a silly 
state NXT.  One is to "fall back" to unsecured DNS, which is what I 
have chosen to propose.  The rationale is that this permits 
enhancements to happen, if they prove to be beneficial.  I did not 
pick this because it resembles opt-in, as some have noted.  Although 
it resembles opt-in, it is not opt-in as that has more rules and 
considerations to follow.  I.e., this proposal does not cover the 
rules of generating silly state NXT's - they are forbidden in the 
First Rule.

The other three options are:

2) (1 is the above) Instruct the verifier to ignore the bit positions 
NXT and SIG.  This is viable, two less bit tests, but obviates any 
chance of making use of these bits as a means to experiment.

3) Instruct the resolver to treat the silly state as a resource 
record format error.  This kind of response will cut off the network 
anyone trying to experiment.

4) Not issue any statement on the silly state reaction.  Because of 
the First Rule, there really isn't an immediate interoperability 
rule, but by allowing implementers to not respond in a harmonious 
way, interoperability into the future is endangered.

Aside.

Case 4 is already used in 2535 - the 0th bit position is used to 
define an unspecified new format for the NXT bitmap.  A 1 there is a 
declared silly state (the opposite value of the 0's for the NXT and 
SIG silly states).  Perhaps we should also specify some standard melt 
down for the time being.  Perhaps not the same - but we should make 
sure that implementers don't vary in undesirable ways.

PS - thanks to the bunch of folks that have replied to me privately 
on this.  But, please, let's keep the discussion on namedroppers - my 
finger hurt from replying to so many contributors...;)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Note to pilots: a three-point landing SHOULD NOT include a wing.

--
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: Derek Atkins <[email-masked]>
Date: 08 May 2003 11:04:51 -0400

> being answered from an unsigned zone.

This is problematic.  Unless I misunderstand you, this would imply
that a silly-state NXT could potentially invalidate a DS handoff to a
secure zone.  I don't think that's what you want to happen.  If you
have an NXT with the DS and NS bits set, why should you ignore the DS?

The issue here is more than just the bits in the NXT bitmap, but also
the name of the NXT record.  If the name of the DS and NXT matches,
then you should NOT ignore the DS.  Indeed, if the QNAME matches, you
should probably treat the silly-state NXT as a normal NXT.  The only
time you should treat a silly-state NXT differently is if the name of
the NXT != name of the query (or other responses).

To give a concrete example, suppose I make a query for a.example.com
and I get back:

        a.example.com   ns ...
                        ds ...
                        sig(ds)
                        nxt b.example.com ...
                        sig(nxt)

Clearly you should NOT ignore the DS in this case, regardless of
the silly-state of the NXT.  However, if I make the same query and
I get back:

        a.example.com   ns ...
                        ds ...
        example.com     nxt b.example.com ...
                        sig(nxt)

now we've got a condition where a silly-state NXT matters.  In this
case, a silly-state NXT should fall back to client policy in terms of
whether to ignore the NS, ignore the DS, or ignore the whole response.

But I think you need to be clear about silly-state and the node names.

-derek

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 May 2003 11:53:24 -0400

At 11:04 -0400 5/8/03, Derek Atkins wrote:
>secure zone.

That's exactly what I am proposing, within some conditions.

1) The NXT has to be valid, so no one is slipping in an invalid NXT 
to downgrade the security.

2) The NXT has to be pertinent to the query.  That is part of the 
following local policy.

>               I don't think that's what you want to happen.  If you

Remember that by the first rule, if the silly state appears, we are 
essentially in an error condition.  When you are in an error 
condition, you do what you need to handle it.  My proposal is to 
assume pre-DNSSEC DNS semantics, as they are already understood.

>the NXT != name of the query (or other responses).

I assume that a valid NXT is an NXT that is pertinent to the query 
triplet, along with all the other checks.

>To give a concrete example, suppose I make a query for a.example.com

When you give an example for a query, please include the QTYPE along 
with the QNAME.  (We can assume QCLASS for the most part, but we need 
the QTYPE to know what you seek.)

>the silly-state of the NXT.  However, if I make the same query and

Your point is not obvious from the example.  You don't show the 
values of the bits involved.  With out the QTYPE, I can't tell if 
this is a proper response.

>whether to ignore the NS, ignore the DS, or ignore the whole response.

Again, without the QTYPE, I can't tell why you would see this under 
normal protocol operations.

>But I think you need to be clear about silly-state and the node names.

The NXT has to be pertinent.  It will be if the server is following 
the protocol rules.  If the NXT is not pertinent, well, we need to 
define those semantics anyway.  (Where?)

---

From: Derek Atkins <[email-masked]>
Date: 08 May 2003 13:22:01 -0400

> That's exactly what I am proposing, within some conditions.

Then I think this is a bad idea.  See below...

> 1) The NXT has to be valid, so no one is slipping in an invalid NXT to
> downgrade the security.
> 

And I disagree with this, specifically because it disallows opt-in.
Note that I'm not an opt-in proponent either, but following this
strategy means that you can't experiment with opt-in...  Let me
restate my examples.

> triplet, along with all the other checks.

Can you define what you mean by "pertinent to the query triplet"?

> the QTYPE to know what you seek.)

*grumble* I think it's unimportant (I don't see why it matters if I'm
asking for A, AAAA, AFSDB, IPSECKEY, or whatever...) but fine, I'll
humor you.  Can we at least assume class IN?

Query:  a.example.com. A

Answer:
        a.example.com.  ns ...
                        ds ...
                        sig(ds)
                        nxt b.example.com ...
                        sig(nxt)

> 
> Your point is not obvious from the example.  You don't show the values
> of the bits involved.  With out the QTYPE, I can't tell if this is a
> proper response.

It doesn't matter what the QTYPE is; if I get this response back it is
clearly a referral to another zone.  Similarly, it shouldn't matter what
the bits are in the NXT (within reason).

Assume the NXT _does_ have the DS bit set.  If the signature validates
on the DS and the signature validates on the NXT then you should
ignore the NXT, accept the DS, and traverse into the secure zone.  It
shouldn't matter what the NXT or SIG bits say.

One could argue that this is a bogus response -- a real server would
never respond with a ds/sig(ds) and an nxt/sig(nxt).  While true, an
attacker could give you this response, and IMHO the resolver should
deal "properly" (which is, IMHO, to ignore the NXT and use the DS).

Your proposal means any attacker could insert the nxt/sig(nxt) into
a response and potentially cause a resolver to ignore the real data.

Now, my other example:

Query:  a.example.com. A

Answer:
        a.example.com   ns ...
                        ds ...

> normal protocol operations.

Well, this is obviously a broken response -- DS is authoritative
data, so it should be signed.  OTOH, you have an nxt in the answer
which might imply an opt-in (if the nxt bit isn't set) or it could imply
a 'no data here' (nxt bit is set).

> define those semantics anyway.  (Where?)

Please define pertinent.  If we assume opt-in, then my second example
*IS* pertinent; but without opt-in it implies an attacker added the ns
and ds.  I'm not so worried about this particular case -- I'm worried
about my first example.

-derek

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 May 2003 13:47:42 -0400

>strategy means that you can't experiment with opt-in...  Let me

It says nothing about opt-in.

The proposal defines the correct behavior to be 1's in the places 
where there should be 1's.  If there's a deviation, then we run back 
to old semantics.

Why this isn't a barrier to experimenting with, e.g., opt-in, is 
hidden this logic:

    Assuming a pre-DNSSEC configured zone:
      An old resolver has no problem understanding the responses
      A DNSSEC-pure resolver has no problem
      A DNSSECw/Opt-In experimental resolver has no problem

   Assuming a DNSSEC-pure configured zone:
      An old resolver is oblivious (no DNSSEC OK bit) to the new records
      A DNSSEC-pure resolver has no problem
      A DNSSECw/Opt-In experimental resolver follows -pure rules

   Assuming a DNSSECw/Opt-In experimental configured zone:
      An old resolver is oblivious (no DNSSEC OK bit) to the new records
      A DNSSEC-pure resolver treats the zone as if it were unsigned
      A DNSSECw/Opt-In expt. resolver is able to grok the exp'm'tal extension

The experiment can lay transparently over the -pure without cutting 
off service to the zones participating in the experiment.

>Can you define what you mean by "pertinent to the query triplet"?

Pertinent means - helps in answering the question.  (CNAME, referral, 
answer, negative answer, all are pertinent.)

 From www.m-w.com: "having a clear decisive relevance to the matter in hand"

It's like this.  You ask me what is my telephone number.  I respond 
with "blue."  My answer is not pertinent.  Or I could say "its at the 
bottom of my mail."  Pertinent - a referral.

>humor you.  Can we at least assume class IN?

DNS is founded on the concept of asking for QNAME, QTYPE, QCLASS.  It 
matters.  A protocol is all about the specifying the response to a 
message.

>One could argue that this is a bogus response

Before we wind up rat holing, let's stick to messages that actually 
exist in the protocol.  And stick to examples that are pertinent to 
the proposal I am laying on the table.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 21 May 2003 15:12:54 -0400

Below is a proposal I put on the list about 2 weeks ago.  Should this 
be handed to the DNSSEC editors for preparation as a 
question/text/etc.?  I'm curious what the chairs want to do with this.

At 9:44 -0400 5/8/03, Edward Lewis wrote:
>This proposal is intended to fit into the appropriate DNSSEC 
>document as part of the definition of the NXT record.  The 
>motivation for this proposal is buried in the opt-in discussion, but 
>the proposal is not centered around the promotion or dismissal of 
>the opt-in proposal.
>
>A compliant signing application will always set the values of the 
>NXT and SIG positions of the NXT RR type code bit map to 1.  This 
>silly state is not to be seen in normal protocol operations.  (Nor 
>are any others, but that's not my concern right now.)
>
>If the type codes for NXT and SIG are changed, the rules for the 
>bits move with the type codes.  I.e., if, say, an NXTbis RR is used 
>to prove non-existence, then the NXTbis position has this special 
>2) (1 is the above) Instruct the verifier to ignore the bit 
>positions NXT and SIG.  This is viable, two less bit tests, but 
>obviates any chance of making use of these bits as a means to 
>experiment.
>
>SIG silly states).  Perhaps we should also specify some standard 
>melt down for the time being.  Perhaps not the same - but we should 
>make sure that implementers don't vary in undesirable ways.
>
>on this.  But, please, let's keep the discussion on namedroppers - 
>my finger hurt from replying to so many contributors...;)
>
>--

Your office is *not* a reality-based sit-com TV show.