On Fri, Mar 06, 2015 at 02:28:44AM -0500, John C Klensin wrote: > That said, if the IETF considers it to be a valid implementation > of DNSSEC to have the closest-to-user validating system be an > ISP-based forwarder rather than a machine on the user's LAN, > there isn't a lot of point in building DNSSEC capability into > zeroconf stuff that is mostly applicable intra-LAN or otherwise > within a trust perimeter that the DNSSEC validator is outside of. Where did this notion come from? I've seen no documents that suggest this. On the contrary, there is even some push back to using a security-aware non-validating stub resolver that chains to a trusted loopback-net validating cache. *Trusting* the ISP's validating resolver is indeed pointless and I've not seen anyone suggest this. If grandma had wheels, she'd be a wagon. Of course once can still *use* an ISP's validating resolver as an untrusted cache, with or without "CD" as appropriate. > Put differently, any time a DNSSEC-based trust model comes down > to "trust your ISP", then it is pointless overhead for any of us > who already know our ISPs can't be trusted. And _that_ is why > I'm reluctant to see it oversold in circumstances like the > current document. In any case nobody's suggesting over-selling DNSSEC here, all the suggested changes have been about the claims for DNSSEC being originally too strong. Nevertheless if a URI RR is to be trusted to change the authenticated authority (RFC6125 reference identifier), then one should at least do DNSSEC or else (when DNSSEC is not fit for purpose) not change the authority (and fail authentication when the target's certificate fails to match the original domain). In the latter case complications may arise with SNI (which domain goes in the client's SNI extension and may it differ from the HTTP request Host: header?). All the document has to do is avoid claiming that trusting DNSSEC is *equivalent* to trusting the application's "usual" PKIX trust-anchors (whatever they might be). Sometimes DNSSEC is worse, sometimes it is better. It should also caution against accepting completely unauthenticated redirection, so given that the redirection is via DNS you either use DNSSEC or don't trust the redirection choose one. Nothing controversial, just basic tautologies that may not be obvious to all. -- Viktor.