Re: [dane] Behavior in the face of no answer?

[Andrew Sullivan <[e-mail]>]

On Fri, May 04, 2012 at 05:12:54AM -0700, Nicholas Weaver wrote:
> 
> DNSSEC at all requires client validation

No it does not.  You keep insisting that because you have in mind the
model of any DNS client in any network, but not every situation is
like that.  I personally think that end-point validation is the best
way to do things, but the protocol is written in such a way that it is
not required, and we can't make it so by wishing.

> , and client validation
> REQUIRES that the client be able to bypass the
> significant-probability-broken recursive resolver already.

Yes.

> DANE
> doesn't really add to that: If the client can fetch DNSSEC signed
> records, TLSA won't be a problem.

But I note that in my DNSSEC Trigger application, I have the ability
to turn it off -- and sometimes it disables itself.  This tells me
that the most-robust end-point validation tool we have already
concedes that it isn't perfect.  The proposal appears, AFAICT, to make
that known-bad path a critical dependency not just for TLSA, but for
doing TLS _at all_.  The way I read the proposal, if you can't get a
TLSA then you fail the TLS connection.  In some number of networks,
what you're arguing for is "no TLS, ever" for any TLSA-enabled
application.  Is that really the direction we want to go?  Because I
predict the result is going to be that everyone turns off TLSA in
their systems on the first day of failure, and then the protocol is dead.

A

-- 
Andrew Sullivan
[e-mail]