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

From: Edward Lewis <[email-masked]>
Date: Tue, 27 May 2003 10:17:03 -0400

I was told that I could label this question Q-10...;)

Any comments on this proposal?  (It's been posted a few times.) 
Sooner or later this will be cast into MUST/SHOULD language and 
submitted to the dnssec-editors, based on feedback.

------------------------

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

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

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