Subject: Re: [dnsext] [dane] Aiming towards some specific wording

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Nov 2011 08:13:12 +1100

The only difference between "insecure" and "indeterminate" is that
there was a TA configured somewhere above the name and there is a
insecure delegation between that TA and data.   We don't actually
prove that something is insecure.  We prove that there is not a
secure path to the data. 

If you don't have a TA you do not have a secure path to the data.
If you have a TA but a insecure delegation you do not have a secure
path to the data.  In both case the data could be signed or unsigned.

"insecure" and "indeterminate" zones are logically the same.  Dane
should just treat them as !secure.

Dnsext should fix the DNSSEC RFC's to get rid of one or other of them
as having two terms for the same thing is pointless.

Reply-to set to [email-masked]

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Nov 2011 16:28:52 -0500

Answering only to DNSEXT...

>should just treat them as !secure.

No, they are not the same.

Insecure means I get records indicating there's no possible trust 
chain that can be constructed from the data to anything I have.

Indeterminate means when I try to get records for part of the chain I 
"time-out".  ("No servers could be reached.")

There's a significant semantic difference between the two.  Apart 
from the fact that you won't succeed in constructing a chain, 
"insecure" means it is definitively impossible and "indeterminate" 
means "not with the data at hand, at this time."  The former would be 
data that is not protected, the latter could be declared a service 
failure.

Here's the definition in RFC 4035 I'm pointing to:

4.3.  Determining Security Status of Data
...
    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.
...
    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.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Vote for the word of the day:
"Papa"razzi - father that constantly takes photos of the baby
Corpureaucracy - The institution of corporate "red tape"

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Nov 2011 10:20:55 +1100

>        name servers for the relevant zones.

And the difference between that and bogus is?   It got data and no
signature so it is bogus.  If got data and bad signatures it is
bogus.  It didn't get a response then it has no data.

There are are only 3 states the data can be in.  Secure, insecure and bogus.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Nov 2011 15:36:29 -0800

If this WG intends to update RFC 403[3-5] with different definitions of the states, it would be good if someone started an Internet Draft *real soon* so the DANE WG can refer to it. Otherwise, maybe it is better to not run this course. Statements of "I don't like it" without action of an actual draft makes it hard for the rest of the IETF to move forwards.

--Paul Hoffman

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 21 Nov 2011 16:59:14 -0800

> bogus.  It didn't get a response then it has no data.

Bogus is defined like this:

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.

So, the resolver knows a priori  that there *is* a chain of trust but
it can't establish that  for the reasons that you mentioned above. .
It is different from Insecure/Indeterminate where the resolver does
not know beforehand. Within Indeterminate/Insecure, you still need
something to say that "I can't reach the servers or I am behind a
crappy CPE device" Vs. "I received an NSEC". I have been having
problems understanding what this really means and this is just my
interpretation..

-regards
mohan

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 21 Nov 2011 20:10:16 -0800

On Mon, 2011-11-21 at 16:28 -0500, Edward Lewis wrote:
> There's a significant semantic difference between the two.  Apart from
> the fact that you won't succeed in constructing a chain, "insecure"
> means it is definitively impossible and "indeterminate" means "not
> with the data at hand, at this time."  The former would be data that
> is not protected, the latter could be declared a service failure.
> 

That's great, RFC 4035 has a totally different definition of
"indeterminate" than RFC 4033.

RFC 4033 "indeterminate" is equivalent to "insecure" for DANE's purpose
and likely other purposes as well.  RFC 4035 "indeterminate" is not a
separate group of cases; those cases are better described as "SERVFAIL",
or possibly "bogus" if the resolver successfully retrieves the target
RRset (but not the DNSSEC RRs).

Ultimately, DANE needs three cases:

1. Secure: Process the RRset.
2. Insecure or RFC 4033 indeterminate: Fall back to pre-DANE behavior,
or (maybe -- under discussion) process the restrictive part of the
assertion without the additive part.
3. Bogus or query failed (RCODE other than NOERROR or NXDOMAIN, no
response from DNS servers, etc.): Fail closed.

-- 
Matt

---

From: Edward Lewis <[email-masked]>
Date: Tue, 22 Nov 2011 08:55:14 -0500

Added Matt McCutchen because his post was on DANE and I'm not on that list.

>There are are only 3 states the data can be in.  Secure, insecure and bogus.

You left out "I don't know yet."

But this doesn't matter, as a follow up post points out, 4033 and 
4035 define indeterminate differently.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Edward Lewis <[email-masked]>
Date: Tue, 22 Nov 2011 08:55:36 -0500

(Took DANE off because I'm not on the list.)

>"indeterminate" than RFC 4033.

You're right.  When I answered I went to 4035 because it is the 
"protocol mod" and not 4034 because it was "records".  I usually 
ignore 4033 because it's "intro" and has no requirements language in 
it.  That's just to explain why I quoted 4035 (because these kind of 
terminology things run rampant in RFCs) and why I didn't quote 4033.

Not that 4033 is any less wrong than 4035.  I just ordinarily look at 
4034/4035 more.

Here's what '33 says:

#   Indeterminate: There is no trust anchor that would indicate that a
#   specific portion of the tree is secure.  This is the default
#   operation mode.

Certainly different from 4035 and what I would assume was the right 
way to define indeterminate.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468