On Thu, May 30, 2013 at 03:55:06PM +0100, Ben Laurie wrote:
> > You are imagining a future in which browsers suddenly decide that
> > out-of-band checking is acceptable, which seems unlikely to actually
> > occur other than in fantasy.
> >
> >
> > Why?
>
> Because:
>
> 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.
Also with a DNSSEC-validating cache, the client does not need to
repeatedly re-validate the same data.
The Postfix SMTP client maintains a small in-memory working-set of
such records, which further reduces latency to completely negligible
levels.
> b) It isn't reliable, so cannot be hard-fail.
I have to click "OK" multiple times a day with the current PKI,
often with ietf.org sites when the URL uses an different name for
the site than is found in its certificate, or because I don't trust
a bunch of questionable CAs, ... will likely be far *more* reliable
(fewer false rejections) than the existing public CA PKI.
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"?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
