Re: DNSKEY flags field

[David Blacka <davidb@verisignlabs.com>]

On Monday 14 June 2004 6:36 am, Simon Josefsson wrote:
> "Olaf M. Kolkman" <olaf@ripe.net> writes:

> > If you follow a chain of trust that says "foo.example" is supposed to
> > be secure in "protocol 3" then, by not having a "protocol 3" key to
> > verify against you have to treat the zone as bogus.
>
> Again, what do you mean by "bogus" in this context?  I believe it
> should mean "insecure", i.e. downgrade to vanilla DNS.  But Scott Rose
> thought SERVFAIL should be returned here.  If there isn't agreement on
> the interpretation, perhaps this should be clarified.

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.

> > If you do not have a secure entry point (following a chain of trust of
> > via a configured trustanchor) into the zone than the keys really are
> > of no use and it does not matter if they are of proto 3 or 4. And your
> > data should pass through as not being validated.
>
> Right.  But I believe they should pass through.  There appear to be
> disagreement on that.

If there is no trust anchor, then the validator has no reason to expect a the 
answers should be signed, and no way to validate the answer if it is.  This 
is defined as the "Insecure" state.  There is no disagreement about this.

> > IMHO this exactly as specified by the language in "proto". Protocol 4
> > keys are not to be used for validation: If a DS RR[*] points to a
> > protocol 4 key than the DS RR tells us foo.example is secure, but
> > since we have a protocol 4 key we cannot validate. Not being able to
> > validate in a secure zone implies bogus results.
>
> "Bogus results" is not well defined.  Do you mean resolvers are
> permitted to return anything it want?

"Bogus" *is* well-defined.  Granted, this term wasn't defined before this 
latest round of documents.  And it hasn't displaced the term "BAD" everywhere 
in the docset.  Maybe -intro or -protocols (or both) should define "BAD" as a 
synonym of "Bogus".

> >> And do you have any thoughts on the actual proposed text change that
> >> started this thread?  I have no wish to change the Protocol Field.  I
> >> have used the Protocol Field, in this thread, as an example of an
> >> already specified extension mechanism, since people appeared to think
> >> that my proposed change wanted to introduce a new extension mechanism.
> >> I want to introduce a cleaner way to specify the extensions, compared
> >> to using the protocol field.
> >
> > IMHO, without degradation attack prevention you cannot use the field,
> > nor the flag bits.
>
> I believe you can.  Send two DNSKEYs:
>
> foo.example    IN DNSKEY proto=3 ...
> foo.example    IN DNSKEY proto=4 ...
>
> 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.

In this case, the validator would discard the proto=4 key for validation 
purposes, and thus effectively ignore RRSIGs generated by this key.  If an 
RRset *only* had RRSIGs by the proto=4 key, it would either generate a 
requery for the "missing" RRSIG or consider the response bogus (or BAD, if 
you prefer).

However, I don't know what use this case is for the purposes of DNSSEC 
versioning.

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