[Cryptography] DNSSEC = completely unnecessary?

[Guido Witmond]

On 11/04/13 19:08, Ralph Holz wrote:
> 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.

Sorry for the confusion, I meant that DNSSEC + DANE specifies the
intent. Thanks for clearing it up.

Frankly, imho, DNSSEC without DANE is not worth the hassle. It's that
DNSSEC paves the way for DANE that makes it worthwhile.


> 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.

Agreed. It's not easy. I hope there will be some parties that will offer
these services for a modest fee to the site-operator. My DNS-registrar
already offers managed DNSSEC. They take care of all the key-stuff. And
if they mess up, there might be others. I have the choice. See it as a
market opportunity for hosting providers.


> 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)

With my eccentric-authentication protocol, I fail hard. But as the
protocol requires the user agents to remember the public key (or
fingerprint) of the site, it can survive transient errors in
DNSSEC/DANE. It makes it less brittle for the price of some storage space.


>> 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.

That's the big problem: How to get these browser vendors along DANE.

There is a prototype DNSSEC/DANE validator plugin for Firefox.
However, it's not in their interest. I more or less expect Google to go
into the CA business and offer to pin your site certificate into Chrome.
DANE with self generated Root-certs won't bring them revenue.

How do we get the message across that most browsers are written by
companies that want to spy on the user. And that other major one is
sponsored for 90% by an advertiser. Let's pray that Greenwald has some
nice slides :-)

>> 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.

Yes, that's why browsers must ignore the coerced 'trust' that this
CA-list requires.

Regards, Guido.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131104/25a3b834/attachment.pgp>