[dnsext] stub validation

[Paul Vixie <[e-mail]>]

among many critical defects in DNSSEC as specified, there's no good model
for stub validation, and as time goes on there are fewer and fewer
trustworthy rdns servers.  as kaminsky said, "i'm not going to trust
starbucks rdns to tell me the TLS key hash for my bank's HTTPS server".

so...

> From: David Conrad <[e-mail]>
> Date: Sun, 24 Oct 2010 16:24:54 -0700
> 
> The problem with applications doing their own resolving is that the 'real
> control' implies there is someone at the other end of the application
> that has the understanding and knowledge to make use of that control.
> Haven't we seen the implications of this approach with browsers that ask
> the end user whether or not to accept an SSL cert?

...at the risk of being that guy who just won't shut up about something,
let me say that until DNSSEC is commonplace, DNSSEC is a failure.  when
every apple and microsoft and google and RIM platform including every
mobile phone can either validate end-to-end based on trust anchors (using
DNSSEC), or validate hop-by-hop based on transaction signatures (using
TSIG) from a trusted (and reachable!) rdns, then DNSSEC won't have been
worth its (considerable) engineering cost.

and it'll have to just work, out of the box, for nontechnical users, with
no more or at least no different popups than we get from X.509 failures.

but please everybody, don't dilute the DMNF thread with this argument.