Viktor Dukhovni <[email protected]> writes: > On Sat, May 25, 2013 at 08:30:52PM +1000, oneofthem wrote: > >> 1. Is DANE finished? Ready to go, rock and roll? > > The TLSA RR has been standardized. What remains to do is to define > how TLSA records are to be used in various application protocols.
It's worth noting, since Viktor unintentionally glossed over it, that the base TLSA definition does include definitions for how to use it over TLS and targeted toward HTTPS specifically, so another document isn't needed for that case. The other protocols he mentioned still need some definition and binding, however. > OpenSSL does not yet provide ready-to-use DANE verification code, > so applications based on OpenSSL have to roll their own. Or use another library that provides DANE validation hooks to use for OpenSSL verification links. (eg: https://www.dnssec-tools.org/svn/dnssec-tools/trunk/htdocs/docs/tool-description/val_getdaneinfo.html ) It shouldn't be hard to get up and running today, and many applications and examples exist for you to glance at and study: https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/apps/curl/curl-7.29.0.patch >> 2. Is it possible for DANE to replace the CA system currently in place? > > For server domains that have deployed DNSSEC, and applications > where clients have DNSSEC validating caching resolvers (or have > chosen to embed DNSSEC capable stub-resolvers directly in application > code) it is possible to bypass the existing public CA PKI. Different people have different security needs and beliefs. So can DANE be used to bootstrap your security needs? Absolutely, if it meets your security requirements (and I think it meets the needs of most people quite well). -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
