[147994] in cryptography@c2.net mail archive
Re: [Cryptography] DNSSEC = completely unnecessary?
daemon@ATHENA.MIT.EDU (Ralph Holz)
Mon Nov 4 13:15:05 2013
X-Original-To: cryptography@metzdowd.com
Date: Mon, 04 Nov 2013 19:08:14 +0100
From: Ralph Holz <ralph-cryptometzger@ralphholz.de>
To: cryptography@metzdowd.com
In-Reply-To: <527773A2.9060809@witmond.nl>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
Hi,
> DNSSEC specifies the *intent* of the domain owner. A validated lookup
> tells you which of the 160 CAs is the chosen one. It's the domain
> owners' responsibility to run a monitoring script to detect rogue
> DNS-registrars that send out wrong data, and publicly sentence those to
> the internet death penalty.
First, DNSSEC != DANE-TLSA != CAA. The latter is about pointing to the
intended CA (as an identifier string), although TLSA can also do the
same (as the hash value of a root's public key). DNSSEC is about the
integrity of any RR.
Second, what seems to be often missing in the discussion is the
consideration of synchronising TLSA records and the certificate-in-use.
I don't subscribe to the view that this is very easy -- if scans of the
HTTPS and SSH ecosystems have shown anything, then it is that poor
deployment practices are to be blamed for a huge part of our problems,
and none of DNSSEC/DANE/CAA solve those.
E.g. I recently did a scan of SSHFP records for all known hosts serving
SSH (this is a very short description of the process). 94% were
accurate. Fine for SSH -- but 6% failed resolutions would be a huge
problem for the Web. So what I'm saying is: the consideration of how to
fail on TLSA errors (soft? hard?) is a hard one for browser vendors. (I
think the RFC for TLSA defines it, actually, but that's the RFC only)
> If you don't trust your chosen CA, ie, it might be coerced to sign a
> fake cert by an 'authority', create your own Root Key (on a smart card)
> and use that for your server certificate.
You may find your browsers rejecting it - because I don't see movement
among browsers anywhere to move away from the CA model towards a
TLSA-only model.
> The thing that is important is that the browsers must NOT look at the
> 'trusted' CA-list anymore!
Not buying this in its entirety, either. You're forgetting about
governments being able to take control of zones, and issue rogue RRs.
Ralph
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
