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

From: Roy Arends <[email-masked]>
Date: Mon, 2 Jun 2003 11:47:32 +0200 (CEST)

On Tue, 27 May 2003, Edward Lewis wrote:

<snap>

> 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.

Okay:

So we have

a.example. IN A
a.example. IN SIG (A)
a.example. IN NXT  d.example. A SIG !NXT     ; aka silly state
a.example. IN SIG (NXT)
b.example. IN A
d.example. IN A
d.example. IN SIG (A)
d.example. IN NXT  example. A SIG NXT
d.example. IN SIG (NXT)

One queries for (b.example.,A,IN,dnssec-ok)
Response:

   NOERROR
   b.example. IN A
   a.example. IN NXT d.example. A !nxt !sig
   a.example. IN SIG (NXT).

corrective action:
   verify NXT record by verifying SIG(NXT). NXT record is okay: remainder
   is unsigned, i.e. b.example. IN A is treated as unsigned.

> 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.

Okay,

Essentially you propose to have corrective action ('treat as unsecured')
in case of silly state (NXT or SIG bit = 0).

I support this proposal !

Roy

Déjà vu encore une fois

--
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: 02 Jun 2003 11:32:10 -0400

Comments near the end...

>    is unsigned, i.e. b.example. IN A is treated as unsigned.
[snip]
> I support this proposal !

but wait... Let's take a different situation...  Same source, different
query.  One queries for:

        a.example..,A,IN,dnssec-ok

and gets the following response (from an attacker):

        NXDOMAIN
        a.example. IN NXT d.example. A sig !nxt
        a.example. IN SIG (NXT)

The NXT will "verify" correctly (the SIG(NXT) is still valid, and the
NXT record was not changed).  However, we still have the silly-state,
so the answer will still be considered unsigned and so the NXDOMAIN
will be considered a valid response (even though the NXT record claims
there should be an A record).  What about the signed A record?  It's
now lost and hidden by the attacker.  Oops!

In other words, someone who decides to experiment with opt-in will
completely destroy ALL security in their zone for anyone who uses a
silly-state-compliant resolver.  I don't think this is a good idea.
You have effectively outlawed even experimenting with opt-int on a
public network with real data.  Perhaps that's your goal?  If so, you
should be extremely explicit about the ramifications.  If it wasn't
your goal then you've left a big gaping hole in the security of the
protocol (or your text was too vague -- either way ;)

Keep in mind that not only do you have to properly handle correct
responses, but you need to correctly handle bogus/attacker responses
as well.  An attacker can EASILY return only partial information in an
answer, and any DNSSec add-on MUST handle that properly.
Unfortunately the current silly-state proposal does not handle attacks
effectively.

IMHO, even in a silly-state if the qname of the answer matches the
qname of the request then I believe the silly-stateness should be
ignored.  In particular, if the SIG(NXT) verifies properly then you
should ignore any silly-state (i.e. if the qnames match your
corrective action should be treat it as a non-silly-state NXT).  See
my above attack example for my reasoning.

> Roy

-derek

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

---

From: David Blacka <[email-masked]>
Date: Mon, 2 Jun 2003 13:28:19 -0400

> protocol (or your text was too vague -- either way ;)

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.

Resolvers that do this "silly-state" processing are not Opt-In aware, 
and would be pretty confused with actual Opt-In responses.  This 
proposal actually allows Opt-In to be used by those resolvers that 
understand it and be safely ignored by those that don't.

It is true that a zone can't both be fully secure and in a silly-state 
flagged experiment at the same time.

> Unfortunately the current silly-state proposal does not handle attacks

I think that was by design, but I could be wrong.

> my above attack example for my reasoning.

This might actually be a good idea as well.  However, the more behavior 
like this that we specify for the silly-states, the less freedom future 
experiments that would use them will have.  They already don't have a 
whole lot, since a NXT must be returned to trigger the silly-state 
processing.

--
David Blacka    <[email-masked]>
Sr. Engineer    Verisign Applied Research

---

From: Edward Lewis <[email-masked]>
Date: Mon, 2 Jun 2003 14:36:18 -0600

At 11:32 -0400 6/2/03, Derek Atkins wrote:
>         a.example.,A,IN,dnssec-ok
>

If an authoritative name error is returned along with records owned 
by the name, the resolver ought to conclude that the response is 
coming from a malformed server.  This isn't just a security concern, 
it's a violation of the basic protocol.  The rightful response is to 
ignore this packet and wait up until the time-out period for a 
possible correctly-formed answer.  The best approach to defend this 
kind of attack is to employ message based security (TSIG or SIG(0)).

BTW, there's no way the NXT will validate.  Yes, cryptographically it 
will be verified.  But the NXT states that, besides the name being in 
existence (contrary to the authoritative name error return code), 
there is a missing piece of data from the answer and that the entry 
is using an experimental approach.  Don't key on the third 
possibility until you also consider the first two.

>protocol (or your text was too vague -- either way ;)

The goal is pretty explicit - to crisply define the behavior of the 
protocol.  The proposal makes no allowance for opt-in, in fact there 
is a MUST on the signer/sender to set the NXT and SIG bits to one. 
On the other hand, if there is a non-compliant signer/server, the 
resolver is protected.

Some would say that anyone deploying a zone compliant with the opt-in 
proposal are playing with security fire anyway.  Due to a lack of 
closure on this the opt-in proposal is not on the standards track.

To address your "In other words" - look at the situations in which 
the NXT would be returned.  Would you get back an NXT if the answer 
is signed?

>Unfortunately the current silly-state proposal does not handle attacks

Cryptographic verification is only part of the validation process. 
See RFC 2181's discussion on credibility.  (Why has cache poisoning 
become less of a problem well before the deployment of DNSSEC?)

>my above attack example for my reasoning.

Cryptographic verification is only part of the validation process. 
Of course, if the silly-stated NXT doesn't make since given the query 
and the answer, you throw it out, even if it verifies.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

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

---

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

Edward Lewis <[email-masked]> writes:

> If an authoritative name error is returned along with records owned by
> the name, the resolver ought to conclude that the response is coming
> from a malformed server.  This isn't just a security concern, it's a
> violation of the basic protocol.  The rightful response is to ignore
> this packet and wait up until the time-out period for a possible
> correctly-formed answer.  The best approach to defend this kind of
> attack is to employ message based security (TSIG or SIG(0)).

I beg your pardon, but the response:

        NXDOMAIN
        a.example. IN NXT d.example <bits>
        a.example. IN SIG (NXT)

Is a perfectly valid response.  Indeed, go read 2535 section 5.4 for
this very example.  I certainly hope your resolver doesn't throw this
out!  The question is really what happens based on the <bits> in the
NXT record.

> there is a missing piece of data from the answer and that the entry is
> using an experimental approach.  Don't key on the third possibility
> until you also consider the first two.

I don't understand your logic here.  Returning a NXT + SIG(NXT) is
exactly what you're supposed to do to authenticate an NXDOMAIN.  So
why do you say that the "there's no way the NXT will validate"?

Assuming the cryptographic checks pass, I think validation depends on
the QNAME and the <bits> of the NXT.  If the <bits> do not contain the
QTYPE then it's a perfectly valid response!  If the <bits> do contain
the QTYPE then again it's possibly a valid NXT that was spoofed by an
attacker.

Let me provide another example:

Query:        a.example.,A,IN,dnssec-ok
Answer:
        NXDOMAIN
        a.example. IN NXT d.example. !nxt sig mx
        a.example. IN SIG (NXT)

What should you do in this case?

IMHO, this should be treated as an authoritivie denial of existance
for the question, but I'm not convinced your text does that due to
the silly-stateness of the response.

> is a MUST on the signer/sender to set the NXT and SIG bits to one. On
> the other hand, if there is a non-compliant signer/server, the
> resolver is protected.

Protected in what way?  I still maintain that it is NOT protected
from a misconfigured/broken signer/sender.  See my previous example.

> To address your "In other words" - look at the situations in which the
> NXT would be returned.  Would you get back an NXT if the answer is
> signed?

Yes, you would.  See my examples.  That's why I think this is
problematic.

> Cryptographic verification is only part of the validation process. See
> RFC 2181's discussion on credibility.  (Why has cache poisoning become
> less of a problem well before the deployment of DNSSEC?)

I agree, it's only part of the validation, but I think you are missing
part of the validation and removing other parts.  Certainly your text
is not clear enough on the validation process.  If *I* am getting this
confused about what you are proposing, what about someone who isn't as
familiar with what's going on going to handle it?

> Cryptographic verification is only part of the validation process. Of
> course, if the silly-stated NXT doesn't make since given the query and
> the answer, you throw it out, even if it verifies.

But that's my point -- there are NXTs are _DO_ make sense given the
query and the answer (see both my examples).  You can't just throw them
out!

-derek

---

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

Sorry, s/NXDOMAIN/NOERROR/ 

-derek

Edward Lewis <[email-masked]> writes:

> At 17:13 -0400 6/2/03, Derek Atkins wrote:
> It's a valid response, but what was the question?
> 
> In your previous mail, you had "a.example., A, IN, dnssec-ok" as the
> query string.  The response has two contradictions - authoritative
> name error and records owned by the name, and an A record listed in
> the NXT with no A record in the answer section.
> 
> If I ask for "a.example.com,IN, A, dnssec-ok" and I get back
> "a.example.org NXT b.example.org" and the latter is cryptographically
> okay, the answer is not valid.  (It's not germane to the query.)
> 
> Discard the message as being an improperly constructed response.
> 
> The NXTs do not make sense.  According to the NXDOMAIN, the qname is
> being declared as not existing, hence, having no data.  Then you show
> that it has data.  Proof by contradiction?
> 
> Your example                                My commentary
> =================                           ===================
> Query:a.example.,A,IN,dnssec-ok
> Answer:
>    NXDOMAIN                                | ....a.example. doesn't exist
>    a.example. IN NXT d.example. !nxt sig mx| ....a.example. exists with ...
>    a.example. IN SIG (NXT)
> =================                           ====================
> 
>                                              contradiction
> 
> 
> -- 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

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

contradiction

---

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

Okay, then let's see that your points are...

What is the query that has generated the following response?

At 17:51 -0400 6/2/03, Derek Atkins wrote:
              NOERROR
>>  >         a.example. IN NXT d.example <bits>

...and what are the bits?

              NOERROR
>>  >         a.example. IN NXT d.example. !nxt sig mx

In this case, the resolver will conclude that there is no A record 
and that the source authority is using a newer-than-the-resolver 
semantics.  E.g., it's the same as seeing no error and an answer 
count of 0.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

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

> ...and what are the bits?

Well, that depends, obviously, and is the heart of my issue.

> In this case, the resolver will conclude that there is no A record and
> that the source authority is using a newer-than-the-resolver
> semantics.  E.g., it's the same as seeing no error and an answer count
> of 0.

Ok, then my reading it correct, and this is a major security problem.
You have now effectively destroyed all security for a site that plans
to experiment with silly-state data.  Even signed data is now
considered unsigned, and authenticated denial has been wiped out, even
for signed nodes.

I still maintain that if the QNAME of the query matches the QNAME of
the answer then silly-state should be ignored.  Either that or the
whole response should be ignored.  In NO CASE should this response be
treated the same as a NOERROR with no answers!  That's just bad juju
and a clear reduction in security, because you are throwing away data
that is 99% (I'll leave room for future silly-state changes ;) telling
you that the response is bogus and accepting the response.  Bad juju.

-derek

---

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

At 18:15 -0400 6/2/03, Derek Atkins wrote:
>the answer then silly-state should be ignored.

In what cases might I see an NXT owned by the QNAME in a response?

In the answer section for QTYPE=any.

     This is a debugging situation.  I'm not sure that the output of the
     verifier is all that important here.

In the authority section as in RFC 2308, 2.2.

     Maybe this needs looking at.

     What if:

         www.example.com, A, IN is the Q-trinity.

         response #1 might be:
         <> no answer
         example.com IN NXT example.com SOA SIG NXT NS
         example.com IN SIG (NXT)

         response #2 might be:
         <> no answer
         example.com IN NXT example.com SOA !SIG !NXT NS
         example.com IN SIG (NXT)

         response #3 might be:
         www.example.com IN A 1111.1111.1111
         example.com IN NXT example.com SOA !SIG !NXT NS
         example.com IN SIG (NXT)

     Response #1 is a non-issue.

     Response #2 is a non-issue, as it appears to my unknowing eye that the
     sender is using funky semantics, but still seems to be saying the data
     isn't there.  But I melt back to the old days - which is an unsigned
     version of #1

     Response #3 is quirky, I would be willing to take the 1111.1111.1111.1111
     address based on this, but who knows that the funky semantics are here?
     Undecidable problem.

     I'd say that any other permutation (save !SIG NXT or SIG !NXT) is 
a protocol
     error in any scenario.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 3 Jun 2003 12:14:29 +0200

On 02 Jun 2003 11:32:10 -0400

>  my above attack example for my reasoning.

This  made me puzzle a bit. 

Let me try to document how I would implement NXT verification in a
verifier.

I'd follow the following algorithm:

1. You only process NXT RRs if the zone from which the NXT RR is
  returned is supposed to be secured. This is determined either by the
  DS (or relevant NXT) from the parent zone or by configuration of the
  zone as an island of trust.

2. Given that the zone is secure you only process NXT RRs to proof
  non-existence of names or non-existence of RRtypes.

3. If either a NXDOMAIN or NOERROR empty answer section is received one
  first verifies the SIG over the NXT RR to check if that has not been
  tampered with. If it has been tampered with mark the answer as
  BAD. (Bad luck, either the zone served incorrect data or your answer
  has been tampered with)

  The SIG(NXT) is correct so we have to verify if the NXT RR is relevant
  to the answer.

  (If the answer is NOERROR and a non-empty answer section we have a
   direct match and the NXT RR is IMHO irrelevant; all the proof
   for the data in the answer section is enclosed in the answer)

4a. If the answer was a NXDOMAIN answer then one has to check if the
  original qname is enclosed in the NXT RR's owner name and the NXT
  RR's nxt_domain_name.  

4b. If the answer was NOERROR no data one verifies that the ownername
  of the NXT RR is the same as the QNAME and verifies that the QNAME
  is not in the nxt_bitmap. 

In both 4a and 4b one does never check if the NXT or the SIG bit are
actually set. So if Ed's proposal should state that the "listener"
would have to do an additional check before step 4 i.e. Verify if the
NXT and/or the SIG bits are set and continue with step 4 if the bits
are set and go into silly state if the bits are not set. (MUST
language)

Independent of going "Ed's check" I also think that the protocol ID
should state  that one should (or maybe even must):

 - when verifying the NXDOMAIN response not use the NXT bitmap.

 - when verifying the NOERROR emtpy answer one should only perform the
   qname==ownername check and one should ignore the nxt_domain_name
   ignored.

To rehash: in my interpretation of the specs the NXT and SIG bits are
not looked at at all; one MUST only look at what is relevant to the
answer given. Ed's proposal introduces an additional check before actually
using the content of the SIG RR to validate answers.

--Olaf

PS ad 4a:I am aware I ignore the multiple NXTs needed for proving
  no-wildcard-matches but that does not change the argument that for
  proving an NXDOMAIN one does not use the bitmap.

PPS: Somewhat relevant, because an assumption about validator behaviour
  was made doing this.

  Last night I was toying with a server that dynamically synthesizes
  signed responses for variable QNAMES and QTYPE=TXT. While for every
  QNAME and QTYPE=TXT the server will magically cooks up an answer
  there will always be a NOERROR empty answer section if the qtype is
  not TXT.
  
  The NOERROR-empty answer NXT RRs are automatically generated and
  signed. The problem with that is that there is no structured zone
  file. So what I did is just use the zones origin for the
  nxt_domain_name.
  
  So for all queries for wich qname is in the zone and for which the
  qtype does not equal TXT the following NXT is synthesized:
 
     QNAME=qname QTYPE=A QCLASS=IN +dnssec

    qname  10 IN NXT $ORIGIN NXT SIG TXT
    qname  10 IN SIG NXT ....generated sig ....

  This should not break validators because I assume, based on the step
  4b, that for validation of a NOERROR-empty answer response the
  nxt_domain_name is irrelevant. Since caches are supposed to cache on
  the QNAME,QCLASS,QTYPE tripled there should not be any problem
  putting bogus name intervals in the NXT RRs that proof non-existence
  of QTYPE for caches either...

  For an example
     dig <reverse-polish expression>.rp.secret-wg.org TXT +dnssec
  eg
     dig 1.1.+.1,3./.rp.secret-wg.org TXT +dnssec

  (yeah yeah.. this is a sick waste of time)

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Edward Lewis <[email-masked]>
Date: Tue, 3 Jun 2003 22:12:31 -0700

First I'll assume the context of this is that the NXT is in the 
authority section and appears in one of the messages as described in 
RFC 2308, including the referral.

>   zone as an island of trust.

The right way to do this step is to take the NXT and it's SIG and try 
to build a chain of trust back to a configured key.  It's not 
important to establish the configuration of the zone when you are 
starting from an NXT and SIG (NXT) - and can positively verify them.

On the other hand, making a determination that a NXT and/or SIG is 
needed if they are absent from a response.  In this case, determining 
that a zone is signed, ergo, expect NXT and SIG is done.

If you do have an NXT and SIG but are unable to establish a chain of 
trust, you need to determine if the zone is supposed to be signed. 
It could be that they are stuffed, are replayed, or are just from a 
cranky old cache with a too-high TTL for the data.  Depending on what 
the reason is (which cannot be decided from the in-band information), 
you response may vary.  But, we have a decidability issue here, so 
we're stuck.

>   non-existence of names or non-existence of RRtypes.

I disagree with this...as before.  If I can validate the NXT, the 
zone must be secured.  If I can't I need to either get the NXT 
(absent but expected) or I discard the NXT (present but unexpected).

>    for the data in the answer section is enclosed in the answer)

This is the step where I realized that there's something missing from 
the discussion.  Once you have cryptographically determined that the 
NXT is valid (let's assume this is the processing path), then you 
need to understand the context to see if it is relevant.

In a referral message, with a negative indication for the DS, you 
need to see that the NXT claims that there is no DS but there is a 
SIG and NXT for the name, as well as NS's.  If that's not the case, 
the NXT is inappropriate - or falls under the silly state proposal.

If you are worried that a delegation from a secured zone using an 
experimental version of NXT to another secured zone will now mean 
that no secure delegation will work, consider that in such a 
referral, you do not see the NXT, just the DS.

If the answer is an NXDOMAIN, then the NXT is only appropriate if the 
QNAME is between the owner name and the RDATA's next name.

If the answer has NOERROR and an empty answer section, then the QNAME 
has to equal the ONAME and the QTYPE flag must be absent from the 
RDATA.

If the answer has NOERROR but has 1 or more CNAMEs in the answer, the 
QNAME has to own a CNAME whose RDATA name (owns another CNAME whose 
RDATA name) is the same as the NXT.

(Can a CNAME chain end in an NXDOMAIN?)

If the answer has NOERROR and has data in the answer that is revealed 
to be a wild card synthesized answer, then the owner of the NXT has 
to be the closest encloser.

So - the context of the NXT determines if it is appropriate.  The 
determination of appropriateness is orthogonal to cryptographic 
verification.

>   is not in the nxt_bitmap.

Yeah, but there are a lot more cases (c,d,e,...) as I mention above. 
(I don't guarantee completeness of my list.)

>are set and go into silly state if the bits are not set. (MUST

Maybe - you need to make the check go hand-in-hand.  Yes, the 
experimental semantics that make the NXT appear to be in a silly 
state might redefine appropriateness, but to the simple resolver, it 
only follows the traditional rules of appropriateness.

>    qname==ownername check and one should ignore the nxt_domain_name

Well, you need to also handle the CNAME and wild card "redirects".

>   Last night I was toying with a server that dynamically synthesizes

"I" == Bert? ;)

>   of QTYPE for caches either...

'Zackly.

>   (yeah yeah.. this is a sick waste of time)

I expect to see a link and man page on Bert's site in short order.

---

From: [email-masked]
Date: Thu, 05 Jun 2003 09:04:55 +1000

> (Can a CNAME chain end in an NXDOMAIN?)

	Yes.  RFC 2317 is the classic example.
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 5 Jun 2003 10:03:31 +0200

> > (Can a CNAME chain end in an NXDOMAIN?)

But every CNAME RR in the chain has its independed proof. Doesn't it.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 5 Jun 2003 11:30:15 +0200

On Tue, 3 Jun 2003 22:12:31 -0700

> RFC 2308, including the referral.

ACK.... If the NXT appears in the answer it is irrelevant to any
proof. That is I think that is in the "spirit" of 5.3 of the protocol
doc.  (It appears in the answer section because of a direct query for
QTYPE=NXT or QTYPE=ANY).

> to build a chain of trust back to a configured key.  
(... skipped ...) 

I agree. The assumption below is that you can follow the chain of
trust all the way to the key that made the signature.

> (absent but expected) or I discard the NXT (present but unexpected).

Let me rephrase:

You will only get a NXT RR to proof the non-existence of a name or
the non-existence of an RRtype with a name. We assume the validator has
validated the  NXT RR i.e. it is present and expected, and the crypto
workes out.

> need to understand the context to see if it is relevant.

Agreed.

> the NXT is inappropriate - or falls under the silly state proposal.

More precise based on the current protcol docs:

 in a referral message:

 The owner name must be the same as the owner name of the delegation
 RR besides the NXT bitmap needs to bits set to 1 for the NS, 0 for
 the DS and 0 for the SOA. This is all what is relevant to the
 validator for validating the answer

 A verifier does not _need_ to check any of the other bits. If it
 chooses to check the bits the NXT and SIG are supposed to be set to 1
 and all the other bits are supposed to be set to 0. Anything other is
 silly state (not only SIG or NXT being set to 0 is silly state but
 e.g. an AAAA bit set to 1 is also silly state)

 in a NOERROR empty answer message:

 The owner name must be the same as the owner name of the returned NXT
 record. The bit in the NXT RR corresponding to the QTYPE needs to be
 set to 0. For this query all the other bits are irrelevant so again a
 verifier does not need to check any of the other bits. If it chooses
 to check other bits then the NXT and SIG bit are supposed to be set to
 1, otherwise it is a silly state (there is another silly state, if
 the NXT bitmap contains a SOA and an NS there is not supposed to be a
 DS)

The point I was trying to make is essentially that one never uses the
bitmap except for checking if a bit has actually been set to "0" (for
a NOERROR empty answer reply) or if the SOA bit is set to "1" or "0"
at a zone-cut.

The protocol does require a check to see if any of the other bits are
actually set to 1; without your proposal the NXT and the SIG bit may
be completely ignored.

In other words your proposal should include a "MUST verify the state
of the bits not relevant to proving the answer" otherwise things will
become very messy. Alternatively the protocol docs could say that
"verifiers MUST only verify the bits that are relevant to the answer",
that excludes sily states alltogether; you just do not care about the
settings of the other bits.

Another worry, the ownername; Do I read correctly that a silly state
does not allow for an owner name different than being expected(#) in
other words are ownername checks performed before or after the silly
state has been determined. (The argumentation above is based on the
ownername being as expected.)

If in a silly state the owner name is allowed to be different from
you should specify that the silly state first needs to be determined
and that one then needs to do the ownernameckeck. (A detail is that if
you allow for different owner names the silly state indicators reduce
to NXT ans SIG only).

--Olaf

(#) The NXT ownername that is expected is:

NXT ownername < QNAME if RCODE=NXDOMAIN
NXT ownername == NS ownername in case of delegation
NXT ownername == QNAME in case of NOANSWER

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Jun 2003 21:46:29 -0400

-----BEGIN PGP SIGNED MESSAGE-----

I have read the entire thread to date. I don't have knowledge about
the proposed "experimental" states that !nxt or !sig might indicate,
and this concerns me. 

So we have Ed's situation #2 - where we decide it is unsigned because we
found "silly state". Derek suggests that this causes anyone "playing" to
become completely insecure - I find that conclusion to be overfast.

I think that I agree with Olaf's analysis.  We would only care about
checking the NXT when we got a NXDOMAIN for a QNAME/QTYPE we were
looking for. Only at that point would we check the NXT bits at all,
so it would only be at that point that we might notice a "silly state".

As such, "silly state" can only be used in experiments that change
our notion about non-existance.  

I think that we should be adding the step 4.0 in Olaf's list - we already
have the NXT-DS problem where we screwed up in 2535. Let's not paint
ourselves into a corner again.

I think it a fair conclusion that if a resolver finds a "silly state"
while trying to prove the non-existence of a QNAME/QTYPE, that it SHOULD
fail to unsigned - that it is should claim the QNAME does not exist,
but it should not set the AD bit. 

yes, Derek is right - anyone playing with "silly state"s for some experiment
may be loosing deniability where they are using it. That sounds fair to
me.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [