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.