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

From: The IESG <[email-masked]>
Date: Thu, 17 May 2012 14:01:22 -0700

The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'Clarifications and Implementation Notes for DNSSECbis'
  <draft-ietf-dnsext-dnssec-bis-updates-18.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2012-05-31. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document is a collection of technical clarifications to the
   DNSSECbis document set.  It is meant to serve as a resource to
   implementors as well as a repository of DNSSECbis errata.

   This document updates the core DNSSECbis documents (RFC4033, RFC4034,
   and RFC4035) as well as the NSEC3 specification (RFC5155).  It also
   defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-bis-updates/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-bis-updates/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 May 2012 09:00:07 +1000

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: +61 2 9871 4742                 INTERNET: [email-masked]