Subject: Re: [dnsext] Reminder: two WGLC closing in one week

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Sep 2008 17:56:17 +1000

In message <[email-masked]>, Michael StJohns writes:
> --=====================_638747484==.ALT
> Content-Type: text/plain; charset="us-ascii"
> 
> At 02:18 AM 9/23/2008, Mark Andrews wrote:
> >        No, it is NOT unkown.  It is insecure.  You are attempting to introd
> uce
> >        a state which does not exist.
> >
> >        secure -> passes validation
> >        insecure -> no TA or there is a insecure delegation from a secure zo
> ne.
> >        bogus -> fails validation
> 
>  From 4035...
> 
>    Secure: An RRset for which the resolver is able to build a chain of
>       signed DNSKEY and DS RRs from a trusted security anchor to the
>       RRset.  In this case, the RRset should be signed and is subject to
>       signature validation, as described above.
> 
>    Insecure: An RRset for which the resolver knows that it has no chain
>       of signed DNSKEY and DS RRs from any trusted starting point to the
>       RRset.  This can occur when the target RRset lies in an unsigned
>       zone or in a descendent of an unsigned zone.  In this case, the
>       RRset may or may not be signed, but the resolver will not be able
>       to verify the signature.

	If there is no trust anchor then the answer is insecure.

	"The resolver knows that it has no chain of signed DNSKEY
	 and DS RRs from any trusted starting point to the RRset."

>    Bogus: An RRset for which the resolver believes that it ought to be
>       able to establish a chain of trust but for which it is unable to
>       do so, either due to signatures that for some reason fail to
>       validate or due to missing data that the relevant DNSSEC RRs
>       indicate should be present.  This case may indicate an attack but
>       may also indicate a configuration error or some form of data
>       corruption.
> 
>    Indeterminate: An RRset for which the resolver is not able to
>       determine whether the RRset should be signed, as the resolver is
>       not able to obtain the necessary DNSSEC RRs.  This can occur when
>       the security-aware resolver is not able to contact security-aware
>       name servers for the relevant zones.

	Which is *not* what you were calling unknown.

	Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Andrew Sullivan <[email-masked]>
Date: Tue, 23 Sep 2008 09:31:33 -0400

Dear colleagues,

Given the discussion between Mike StJohns and Mark Andrews on how to
handle DNAME (or CNAME) chains in a DNSSEC context, it seems to me we
have three choices:

1.  Do nothing.  The documents are clear enough as they are.

2.  Clarify this behaviour in the 2672bis-dname document.

3.  Clarify the behaviour, but in the dnssec-bis-updates document.

Speaking only personally, it seems to me that, if we have a mailing
list thread that lasts through 4 or 5 exchanges to clarify a point, we
need to put together text to make that point clear in the resulting
RFCs.  Nobody is going to troll through old WG mailing list archives
to learn what the "right" interpretation is, and we'll see problems in
the field.

Speaking as the current shepherd for both the dname-bis and
dnssec-bis-updates drafts, I would therefore like some guidance from
the WG on what to do among 1-3.  In particular, if you think one of
those drafts is a better place for the clarification than the other,
I'd like to hear your opinion.  In terms of workflow, I will point out
that it'd be nice to be able to wrap up 2672bis-dname and punt this
problem to a later document if that's acceptable to everyone.  But if
the clarifications really need to go into 2672bis-dname, well, that's
why we have last calls.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 23 Sep 2008 21:09:14 -0700

>>>>> On Tue, 23 Sep 2008 09:31:33 -0400, Andrew Sullivan <[email-masked]> said:

AS> Given the discussion between Mike StJohns and Mark Andrews on how to
AS> handle DNAME (or CNAME) chains in a DNSSEC context, it seems to me we
AS> have three choices:

AS> 1.  Do nothing.  The documents are clear enough as they are.

I think given the discussion alone, along with my notes written on the
margins of the DNAME document I have in front of me (which I'll write up
tomorrow) that leaving it as is doesn't really help matters.

AS> 2.  Clarify this behaviour in the 2672bis-dname document.

AS> 3.  Clarify the behaviour, but in the dnssec-bis-updates document.

Nothing is more frustrating that reading a document that isn't fully
descriptive of the current environment it has to be deployed in.
Leaving it underspecified in either document is inappropriate, in my
opinion.  Leaving, for example, the DNAME document as is without
supporting text describing the interactions of DNSSEC and DNAME is not
good service to future readers who don't know where to turn for the
information.

So, IMHO, minimal narrative text is needed describing anything the WG
decides in the end is important to document.

That being said, I have no issues with cross referencing one from the
other to get things right.  However!, a pointer is likely sufficient from
the lesser-complete documentation to the other saying something like
"For a complete discussion of DNAME usage within DNSSEC, please see
[RFCXXX]".  The problem is that silly XXX that has slipped in there.  We
(obviously) can't publish the DNAME document with a referral to a
document that doesn't exist yet.

So, IMHO, you might as well solve it in the DNAME document since it's
likely to go out first.  Unless (ha ha) it's this discussion that holds
it up to the point where the other one will pull out in front.  I don't
think the document should be left in a vague state, however, that brings
about a bunch of arguments from the technical experts.  There is no way
such a document will end up helping new readers get things right.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: Edward Lewis <[email-masked]>
Date: Wed, 24 Sep 2008 12:05:23 +0200

Option 1 or 2.  I'd have to reread the sections again to know if I 
think there is an issue.  But this topic belongs to the dname-bis 
document.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 24 Sep 2008 12:14:55 +0200

(ref. http://tools.ietf.org/id/draft-ietf-dnsext-rfc2672bis-dname-14.txt)

As there are others with notes, I' avoiding sending text but at least 
some guidelines for what should be in the section.

DNAME and DNSSEC

For implementations that understand both DNSSEC and DNAME (synthesis).

In any response, a signed DNAME RR indicates a non-terminal 
redirection of the query.  There might or might not be a server 
synthesized CNAME in the answer section, if there is, the CNAME will 
never be signed.  For a DNSSEC validator, verification of the DNAME 
RR and then checking that the CNAME was properly synthesized is 
sufficient proof.

In any negative response, an NSEC or NSEC3 record type bit map must 
be checked to see that there was no DNAME that could have been 
applied.  Yadda, yadda, yadda.

...What I find is that the currect text only or overly discusses 
negative answers.

I could provide more text later, but I have faith in the editors and 
know they will have to incorporate other input on this.  But if I am 
asked, I'll do something later.

---

From: Scott Rose <[email-masked]>
Date: Wed, 24 Sep 2008 09:03:44 -0400

On Sep 24, 2008, at 6:14 AM, Edward Lewis wrote:

> As there are others with notes, I' avoiding sending text but at  
> least some guidelines for what should be in the section.
>
> DNAME and DNSSEC
>

We'll take anyone's input - for those out there that want to steal  
Ed's thunder :)

Scott

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 24 Sep 2008 06:26:07 -0700

[reposting from my proper subscribed address which I need to change;
sorry if you get 2 copies]