Cryptographic identity management

Status: on hold; 2011 (supersedes any conflicting remarks left on this page; see the home page for definitions)

Every day, I make TLS connections to many different secure services, which today are associated with host names in the IANA DNS.  You probably do too.  Keeping these connections secure is a big deal.  The crux of the problem is to authenticate the server as a legitimate host of the logical service you want, however defined; other than that, it is just a matter of employing the right cryptographic algorithms and protocols.  The same applies to securely exchanging email or other messages with individuals.

DANE is the natural solution for services associated with DNS names and would be a huge step forward from the inconvenient and increasingly untrustworthy public CA system if it were adopted.  But in principle, the idea that IANA, Verisign GRS, etc. can do a better job of naming and maintaining a relationship with my friend than I can is absurd.  I look forward to a system based on local names and introductions, like UIA, that can also handle the IANA DNS as one case.

Some non-solutions:

• While individuals of course build trust in one another over time, it should go without saying that "trust on first use" for a relationship that already exists in another form is unacceptable.
• A "web of trust" based on signatures of name/email IDs, as popularly practiced with GPG, is awkward at best because the significance of a given name/email to a given relying party is not clear in general.  In particular, it would be a mess if a domain were usurped via legal process and relying parties needed to distinguish former and current owners.

Unfortunately, the ideal system is a long way off, and DNSSEC even has some support for direct relationships with others, avoiding exposure to third parties, via trust anchor pinning.  Thus, I helped to push DANE forward.  To this end...

DANE implementation for NSS[# Top]

Status: obsolete (supersedes any conflicting remarks left on this page; see the home page for definitions)

I have completed a proof-of-concept implementation of DANE for NSS, available in the form of a patch.  See the included security/nss/README.dane.

You can test this against the mattmccutchen.net zone with TLSA_RRTYPE=65468.  I will publish the tools I use to maintain the TLSA data when I have a chance.  With regrets, I disabled DNSSEC on mattmccutchen.net on 2015-11-23.

Thanks to Dan Kaminsky's Phreeload for showing me how to use libunbound.

For questions or comments about this prototype or the TLSA data on mattmccutchen.net, please email me.  Direct questions or comments about DANE itself to the working group.