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

[Ben Laurie <[e-mail]>]

Alex Bligh wrote:
> 
> 
> --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.

No.

If I am delivering mail, and the domain does not exist, I bounce it. If
I get SERVFAIL, I hold on to it and try again later.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

--
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/>