Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME

[Alex Bligh <[e-mail]>]

--On 13 October 2008 14:16:52 +0200 Wouter Wijngaards <[e-mail]> 
wrote:

> I think it is much simpler than that. The application is interested in
> what is known with certainty.
> 1. It is certain the data is valid (secure)
> 2. It is certain that security checks failed (bogus)
> 3. whatever (insecure).

One of the merits of Ben's list was it attempted to list the states "as
a user might see them" without associating them in the first instance
to the workings and terminology of the protocol.

>From the user's point of view, I think you (and, I think Ben) have missed
at least one. Using your numbering above here is what a DNSSEC aware
application might find when looking up the name:

1. We have data, which we know is correct & secure (DNSSEC signatures
   verify)
2. We have data, which we know is invalid (DNSSEC shows insecure)
3. We have data, but we are uncertain as to the correctness of the
   data (e.g. no DNSSEC information for that zone, or missing DLV
   or whatever).
4. We have no data, e.g. we got a SERVFAIL. As I understand, we can't
   tell this is secure or not (willing to be corrected here).

Non-DNSSEC-aware resolver stacks return (3) or (4).

As far as I can tell, treating (2) like (4) at the application layer
seems sensible (i.e. I can't see any/many applications distinguishing) (*).
However, an application might handle (1), (3) and [(2)/(4)] at least
as different states (even if only colouring a browser address bar
yet another shade of the rainbow). Compatibility reasons suggest
that legacy applications (non-DNSSEC aware) get to treat (1) and (3)
the same, or every such application will fail when a DNSSEC compliant
library is installed. Given evidence to date suggests adoption of
DNSSEC will be non-instantaneous, this seems mandatory.

(*) interesting nit: state 2 includes secure denial of existence. I am
arguing here secure denial of existence gets treated at the application
layer just like an insecure failure in every circumstance I can think
of. IE, you can spoof a SERVFAIL, DoS the resolver so it times out,
or whatever and it will be treated the same way as a guaranteed denial
of existence through NSEC/NSEC3 at the application layer. I know there
are people who think that maintaining the difference between an
authenticated denial and a failure is useful for more than debugging
purposes, or we wouldn't have spent so long ensuring NSEC's successor
maintained authenticated denial of existence. This implies that they
must see a need for (2) and (4) to be different.

Alex

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