Subject: Re: DNSSECbis Q-15: Security-aware stub resolver setting the CD bit: SHOULD NOT or MUST NOT?

From: Sam Weiler <[email-masked]>
Date: Fri, 1 Aug 2003 17:50:03 -0400 (EDT)

> Q-15: Should a security-aware stub resolver be allowed to set the CD
> bit on queries or should this behavior be prohibited?

It hinges on the "security-aware" definition, but, generally, it
should be allowed.  In particular, a user may wish to bypass DNSSEC
checking (by active decision or policy), and clients should be written
to allow for that.

> Editors' note: Should this SHOULD NOT be a MUST NOT?

No.

-- Sam

--
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: Rob Austein <[email-masked]>
Date: Fri, 01 Aug 2003 18:42:30 -0400

At Fri, 1 Aug 2003 15:35:28 -0400, Matt Larson wrote:
> 
> This question corresponds to editor's note #14 from
> draft-ietf-dnsext-dnssec-protocol-01.
>  
> Background: Here is the text in question from Section 4.2 (page 24) of
> draft-ietf-dnsext-dnssec-protocol-01:
> 
>    A security-aware stub resolver SHOULD NOT set the CD bit when sending
>    queries, since, by definition, a security-aware stub resolver does
>    not validate signatures and thus depends on the security-aware
>    recursive name server to perform validation on its behalf.
> 

Note: "security-aware stub resolver" has a precise definition, see
draft-ietf-dnsext-dnssec-intro.  One could reasonably challenge that
definition, but leave that until the next paragraph: the point here is
that this Editors' note was phrased in the context of that definition.

As far as the definition itself goes: this is by far the biggest
stretch away from classical DNS terminology in the terminology we're
using in the current DNSSECbis docs.  The problem that this was trying
to express is that some people see a big difference between two
different kinds of recursive-mode-only resolvers, and see phrases like
"a stub resolver that validates signatures" or "a stub resolver that
includes a cache" as oxymorons.  The basic model that these folks have
seems to be that a stub resolver, by definition, is dumber than a
turnip.  Personally, I don't really care whether "stub" implies
"dumber than a turnip" or not, "dumber than a turnip" does seem to
imply "too dumb to verify signatures".  So, since the existance of
mechanisms like the AD bit suggested that we needed a term for
recursive-mode-only resolvers that don't validate signatures, I hit
upon the phrase "security-aware stub resolver" as a least-bad fit.

Whether this definition is useful is for the WG to decide, but, if
it's not useful, please suggest an unambiguous alternative.

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 4 Aug 2003 09:37:43 -0400

I support the spec stating that a stub resolver must be allowed to set the
CD bit in a query if it so chooses.  There is no "rule" saying a security
aware stub resolver (secstub resolver?) can't have a full validator as well.
It seems a matter of local policy for the client.

Scott