On Thu, May 30, 2013 at 04:41:00PM +0100, Ben Laurie wrote:
> >> a) It introduces latency, and
> >
> > Negligible because DNS RRs are cached near the client, ideally at
> > 127.0.0.1 (a forwarding DNSSEC validating cache on every computer,
> > mobile phone, ...), thereby eliminating issues wrt. MITM attacks
> > between the client and the caching resolver.
>
> Even if this were true, first hit latency matters, too. As anecdotal
> evidence, I just resolved a name unlikely to be cached locally:
>
> $ dig www.disney.com
> ;; Query time: 535 msec
>
> Unacceptable.
That's how long it took to get the A record, which the browser
needs anyway! So it must be acceptable.
- This is I assume why Google does DNS pre-fetching, and the
same can be done for TLSA RRs.
- With a suitable asynchronous DNS lookup API, multiple DNS queries
can be sent in parallel, the A record, AAAA record and TLSA RRs
can all arrive in parallel.
What slows down page loads for me is not DNS, but the "skip this ad"
links that come up before the real page loads :-)
> > Also with a DNSSEC-validating cache, the client does not need to
> > repeatedly re-validate the same data.
>
> Our experiments suggest that a _large_ percentage of clients cannot
> see DNSSEC records at all.
This is fine, they can continue to use legacy PKI. DANE does not
apply when the client has no DNSSEC support. DANE is not intended
to "hard fail" when the client can't use DNSSEC. It only hardfails
when it can and the returned RRs are "bogus".
A more serious issue for browsers is corporate MITM proxies.
Browsers behind such proxies (much as Chrome does now, since it
"knows" about the certificates of some sites) need to be configured
to enable alternatives to the default TLS security policy.
> > With a "3 1 1" TLSA RR (matching a leaf cert ultimately signed by
> > a public CA for now), a DANE-aware browser can reliably succeed
> > where the public CA PKI fails, due to:
> >
> > - A rogue CA publishing unauthorized certificates.
> > - An incomplete (whatever that means) CA list on the client
> > - Problems with CRLs
> >
> > What specific problems do you anticipate with DANE TLSA that make
> > it unsafe to "hard-fail"?
>
> See above.
You have not yet mentioned anything that makes it unsafe to hardfail
when TLSA RRs don't match, or DNSSEC replies are bogus. Otherwise,
DANE does not hard fail. I really don't want to be oppositional,
sorry if it seems that way, difficult to seem otherwise in email.
It seems there may be some misconceptions about the DANE TLSA PKI
validation model, are you open to exploring this possibility?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
