Re: DNSKEY flags field

[David Blacka <davidb@verisignlabs.com>]

On Monday 14 June 2004 2:31 pm, Simon Josefsson wrote:
> David Blacka <davidb@verisignlabs.com> writes:

> > The term "bogus" is defined in draft-ietf-dnsext-dnssec-intro-10, section
> > 5, and again in -dnssec-protocol-06, section 4.3.  As specified, when a
> > validator determines that a responses is bogus, for whatever reason, it
> > returns SERVFAIL.
>
> Thanks for the pointers.  Where is the requirement to respond with
> SERVFAIL described?  Or more generally, where is resolver behaviour
> when resolvers receive bogus data discussed?

In -intro-10 this is discussed later in the same section (5):

   This specification only defines how security aware name servers can
   signal non-validating stub resolvers that data was found to be
   bogus (using RCODE=2, "Server Failure" -- see
   [I-D.ietf-dnsext-dnssec-protocol]).

In -protocol-06, this is stated (sort of) in section 5.5.  Although
that language is talking about what happens when RRSIGs do not
validate, specifically.  It is also mentioned briefly in section 3.2.2
in the context of the CD bit.

Note to the dnssec-editors: I think that we want to make clear that
SERVFAIL is returned not just when RRset fails to validate, but in all
situations where "bogus" applies.  This is clear (to me, anyway) from
the language in -intro-10, but it is not mirrored in -protocol (that I
could find).

> >> Are you saying that a conforming DNSSECbis resolver would reject this
> >> response and return SERVFAIL?  Or should it ignore the unrecognized
> >> second DNSKEY, validate the data using the proto=3 key and (assuming
> >> verification succeed) proceed as normal?
> >
> > The latter.
>
> Excellent!  Maybe I had simply not understood how "bogus" data was to
> be treated.  From the previous discussion I got the impression that
> resolvers would treat the above data as bogus.  If the above work, I
> believe using proto=4 as a extension mechanism is possible.  Just
> define what DNSKEY with proto=4 mean.  Resolvers that do not support
> it, will use proto=3 and continue work, whereas resolvers that support
> proto=4 might use that key instead.
>
> But this just reinforce my opinion to add the text I suggested
> initially.  If the text is adopted, we can use bit field signaling
> instead of protocol fields for extensions, which would be cleaner.

I do not see how the protocol field can be used for extensions.  Maybe
I just don't understand what you mean by "extensions"?

In my mind, what we are driving towards are mechanisms for
*non-backward-compatible* versions or extensions to DNSSEC.  If the
"extension" is backwards-compatible, then no signalling is needed,
AFAICT.

If the "extension" is not backwards compatible, then having the
proto=3 present will cause DNSSEC-bis compatible resolvers to choke on
the "extension", as it can't tell that this zone isn't DNSSEC-bis.
All it can see is that there are irrelevant DNSKEYs and irrelevant
RRSIGs.

However, lets think about what happens with all zone apex keys are
proto=4, and the zone is part of an island of security.  So, to
sorta-kinda reprise Ed's example:

 example.com has a secure delegation for newzone.example.com:

  newzone.example.com. NS ns1.newzone.example.com.
  newzone.example.com. NS ns2.newzone.example.com.
  newzone.example.com. DS <key 1>

and newzone.example.com has:

   newzone.example.com. SOA ...
                        RRSIG(SOA)
   newzone.example.com. NS ns1...
                        NS ns2...
                        RRSIG (NS)
   newzone.example.com. DNSKEY key1, proto=4
                        DNSKEY key2, proto=4
                        RRSIG(DNSKEY)

a DNSSEC-bis aware resolver (i.e., unware of what proto=4 means), will
have a very hard time with this, because it will a) expect
newzone.example.com to be secure, and then be unable to validate
anything in it.  It may be able to tell that the DS in example.com
corresponds to key1 in newzone, but it won't be able to validate the
DNSKEY RRset in newzone (or any other RRset, for that matter).  Thus
will have to conclude that every answer coming from this zone is
bogus.

We *could* go further and specify that proto > 3 means that the
DNSKEYs work the same as proto=3, thus allowing the validator to
validate the zone apex DNSKEY RRset, but that, if all DNSKEYs are
proto > 3, then the zone should be considered Insecure.  This might
work, but it requires more thought.

-- 
David Blacka    <davidb@verisignlabs.com> 
Sr. Engineer    VeriSign Applied Research

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