Subject: Re: DNSSECbis Q-16: Security-aware recursive name server behavior when CD=1 and DO=0

From: "Scott Rose" <[email-masked]>
Date: Thu, 21 Aug 2003 10:23:52 -0400

I'm for this text (big surprise, I know...) simply because it doesn't harm
anything from the resolver point of view.

If the resolver knows about EDNS, it probably knows some dnssec as well, and
knows when it doesn't want to deal with it (DO=0).  If the bits have been
diddled in the process (attacker), the resolver/verifier will know something
is amiss when the DNSSEC RRs are not returned, then it is up to local policy
on how a suspected attack is handled.

Scott

----- Original Message ----- 
From: "Matt Larson" <[email-masked]>
To: "Namedroppers Mailing List" <[email-masked]>
Sent: Thursday, August 21, 2003 9:30 AM
Subject: DNSSECbis Q-16: Security-aware recursive name server behavior when
CD=1 and DO=0

> This question corresponds to editors' note #14 from
> draft-ietf-dnsext-dnssec-protocol-01.  (Note: DNSSECbis Q-15
> incorrectly claimed to correspond to editors' note #14.  Q-15 actually
> corresponds to editors' note #15.)
>
> Q-16: What should a security-aware recursive name server do if it
> receives a query with CD=1 and DO=0?
>
> Background: Here is the text in question from Section 4.1 (page 23) of
> draft-ietf-dnsext-dnssec-protocol-01:
>
>    The name server side of a security-aware recursive name server MUST
>    pass the sense of the CD bit to the resolver side along with the rest
>    of an initiating query, so that the resolver side will know whether
>    whether or not it is required to verify the response data it returns
>    to the name server side.
>
> Suggested additional text:
>
>    The sense of the CD bit is only considered when a query also has
>    the DO bit set.  A security-aware recursive name server MUST ignore
>    the sense of the CD bit if the DO bit is not set.
>
> Please comment on the suggested text.
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>

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

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 21 Aug 2003 18:19:04 -0700 (PDT)

> Please comment on the suggested text.

What is the rationale for this change?
-- 
Andreas Gustafsson, [email-masked]

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 25 Aug 2003 09:36:40 +0200

We keep this Q16 open for 2 more weeks, and close this topic at Sep 7. 
The default action will be to keep the suggested text.

-- Olaf Kolkman
   DNSEXT Co-Chair

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 25 Aug 2003 08:06:08 -0400

The rationale is basically to reduce ambiguity.  Both bits have a DNSSEC
meaning, so the editors though it would be a good idea to hammer down the
order for bit flags in a query.  Since it was never mentioned in previous
docs, we have to get WG consensus for this issue.

----- Original Message ----- 
From: "Andreas Gustafsson" <[email-masked]>
To: "Matt Larson" <[email-masked]>
Cc: "Namedroppers Mailing List" <[email-masked]>
Sent: Thursday, August 21, 2003 9:19 PM
Subject: Re: DNSSECbis Q-16: Security-aware recursive name server behavior
when CD=1 and DO=0

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 25 Aug 2003 15:36:43 -0700 (PDT)

> docs, we have to get WG consensus for this issue.

I see no ambiguity.  Both bits have a DNSSEC meaning, but they are
fully orthogonal and do not conflict; all four combinations are
well-defined.

To recap the definitions of the bits:

  [RFC2535]
     The CD (checking disabled)
     bit indicates in a query that Pending (non-authenticated) data is
     acceptable to the resolver sending the query.

  [RFC3225]
     Setting the DO bit to one in a query indicates to the server that the
     resolver is able to accept DNSSEC security RRs. [...]
     More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
     or NXT RRs to authenticate a response as specified in [RFC2535]
     unless the DO bit was set on the request.  Security records that
     match an explicit SIG, KEY, NXT, or ANY query, or are part of the
     zone data for an AXFR or IXFR query, are included whether or not the
     DO bit was set.

Specifically, having DO=0 and CD=1 means that the resolver cannot
receive DNSSEC records (or maybe just doesn't want to), and wishes to
disable DNSSEC checking by the server.  The correct server behavior in
this case is clearly and unambiguously to not verify and not send
signatures.

Of course, a resolver that sends DO=0 and CD=1 will receive unverified
answers that it cannot itself verify due to the lack of signatures.
Therefore, if security is desired, the resolver will not send DO=0 and
CD=1.  That does not mean there is any reason to make this combination
of flags a special case on the server side, or that this combination
of flags could not be useful in other situations such as diagnostic
tools or other special applications that may want to receive pending
data without signatures.
-- 
Andreas Gustafsson, [email-masked]

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 26 Aug 2003 09:07:14 -0400

I think we're in agreement here.  There is some concern that there is
ambiguity over what the combo of the AD, CD and DO bits mean.  The text that
Matt gave was an attempt to clarify it for implementation guidelines.

Scott

----- Original Message ----- 
From: "Andreas Gustafsson" <[email-masked]>
To: "Scott Rose" <[email-masked]>
Cc: "Namedroppers Mailing List" <[email-masked]>
Sent: Monday, August 25, 2003 6:36 PM
Subject: Re: DNSSECbis Q-16: Security-aware recursive name server behavior
when CD=1 and DO=0

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 26 Aug 2003 11:54:29 -0700 (PDT)

Scott Rose writes:
> I think we're in agreement here.

Just in case it wasn't clear from my previous mail, I am opposed to
adding the text suggested in Q-16.  Are you saying you have changed
your mind and are now also opposing it?

> There is some concern that there is

Q-16 does not mention the AD bit.

Adding the text suggested in Q-16 is not a clarification of the
existing protocol - it is a protocol change.  Currently servers are
allowed to send non-authenticated data when CD=1 and DO=0 (just as
they are when DO=1, because DO currently does not figure into the
definition of CD).  The proposed text changes this.
-- 
Andreas Gustafsson, [email-masked]