Re: DNSKEY flags field

[Simon Josefsson <jas@extundo.com>]

David Blacka <davidb@verisignlabs.com> writes:

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

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?

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

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.

Thanks,
Simon


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