Features Download
From: Nikos Mavrogiannopoulos <nmav-c5N7Ur/I1ocdnm+yROfE0A <at> public.gmane.org>
Subject: an implementor's comments on DANE
Newsgroups: gmane.ietf.dane
Date: Saturday 6th October 2012 09:16:13 UTC (over 5 years ago)
 In this mail I list the issues I noticed while implementing DANE. No
matter the direct language they are comments in good faith. They may be
wrong because of my misunderstanding of the protocol, so feel free to
correct me if this is the case.

I think that DANE is _too_ complex for its purpose.

1. DANE does not imply DNSSEC, and verified using DANE may mean nothing.
Why? Is there any reason not to require DNSSEC? How would a user that
uses DANE over DNS and a user that uses it over DNSSEC understand the
difference? What is the added value of using DANE over DNS? The RFC
claims that there is no harm, but there is no reason either and in
addition it introduces issues due to misconfiguration. Bottom line: DANE
w/DNS adds no additional security and has the risk of verification false
positives due to misconfiguration, so IMO no point for it.

(DANE w/DNSSEC also introduces the risk of misconfiguration _but_ it
adds additional security if configured properly)

It is also a marketing issue. DANE should mean something better than
before (i.e. dnssec), not just the same thing as before with a new name.

2. Too many certificate usage fields to indicate the _same_ thing.
It is nice to see that there is a document (RFC6394) describing DANE
real-world use-cases, but then the main protocol instead of defining a
single protocol to cover all use cases, it makes several subprotocols
for each use case. There are 4 certificate usage fields but only 2 of
them are actually different.

Certificate usage 0 is exactly the same as 2, and usage 1 is the same as
3. The difference is that if my certificate is signed by a CA I use 1,
but if the CA signature expires but I don't renew I have to notify the
DNS administrator to change it to 3. That's quite interesting. What is
that for? So that the user knows that my certificate is expired? He
already knows that.

The same if I have a self-signed certificate that one can verify using
DANE. If I decide to buy a signature from a CA to increase security, I
actually create confusion for the users of DANE. Users of DANE would see
the certificate usage 3 in my public key, and what should they think?
That they are under attack, or that 3==0 and that this is a common

3. Too many options for the selector field.
Note that having more options is not better, it is worse because of
incompatibilities. People will ignore DANE verification due to the many
false positives. Why allow _both_ full X.509 and SubjectPublicKeyInfo
fields? What is the advantage? The answer is none. You could also have
allowed raw RSA keys, raw RSA keys that have e and m reversed and so on.
But more options do not add additional security.

My suggestion would be to simplify DANE by having a profile that is
simple to implement and understand its purpose. That is:
* Restrict DANE only with DNSSEC. If there is no DNSSEC, then there no
* Deprecate usage fields 2 and 3. The serve no real purpose.
* Only allow selectors for SubjectPublicKeyInfo.

CD: 17ms