Re: [dnsext] Last Call: <draft-ietf-dnsext-dnssec-bis-updates-18.txt> (Clarifications and Implementation Notes for DNSSECbis) to Proposed Standard

[Mark Andrews <[e-mail]>]

I am repeating what I have said earlier during WGLS that Section
5.9., Always set the CD bit on Queries, contains bad advice on how
to set the CD bit.

The setting of CD make little difference if all the machines involved
are being correctly managed.  In that case all responses will
successfully validate.   However if there is a off path attacker
or one or more of the authorititive sources is returning stale
records the setting of CD is critical to ensuring that the ultimate
client can get the necessary records to ensure that the responses
it gets validate.

When there is a non-validating stub resolver all queries from that
client come in with CD=0 and a validating recursive server try
multiple authoritative servers until it gets a answer which validates
as secure or insecure, in other words it rejects answers from
attackers or from authoritative servers that return stale data.

Now take a validating validating stub resolver, if all queries from
that client come in the CD=1, them the recursive server returns the
answer from upstream immediately without filtering out bad responses.
If there is a off path attacker or if there is a stale authoritative
server then there is no way to ensure that the stub client will
ever get a answer that will validate.  It can continue to re-query
forever but there is no requirement for the recursive server to try
a different authoritative source or to wait for a valid response
from a authoritive source.

A similar problem arises when a recursive server is talking through
a second recursive server.  The server is no longer talking to the
authoritative servers directly and can't recover from getting answers
that do not validate.

Now sending CD=0 has its own set of problems caused by stale trust
anchors and clocks being out of sync so I am not suggesting that
we always send CD=0 queries either when incoming queries are sent
with CD=0.

Stub resolvers and recursive servers talking through other recursive
servers need to be prepared to ask queries with both CD=0 and CD=1.
CD=1 when talking to authoritative servers,  CD=0 when talking to
recursive servers falling back to CD=1 on SERVFAIL to handle stale
trust anchors and out of sync clocks unless the incoming query was
received with CD=1 in which case you MUST make CD=1 upstream queries.

Now if the recursive server is not validating, validating down
stream clients are vulnerable to all the failure modes caused by
sending CD=1 queries.  Fixing this will require protocol extensions
to pass trust anchors, and maybe current time, along with the query
and having on demand validation performed using those values in the
recursive server for this client.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]