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

On Mon, 2011-11-21 at 16:28 -0500, Edward Lewis wrote:
> Answering only to DNSEXT...
> 
> > At 8:13 +1100 11/22/11, Mark Andrews wrote:
> >"insecure" and "indeterminate" zones are logically the same.  Dane
> >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
> ...
>    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.

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

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext