I have raised these comments in the WG numerous times, I am raising
them here as I do not believe that anyone is going to implement the
specification as currently described.
As currently written, the specification attempts to mandate client
behavior when DANE records are encountered in ways that are outside
the scope of interoperability. While the objective of the authors is
to mandate certain behavior they consider necessary for security
reasons, what they end up doing is attempting to substitute their own
judgement for that of the security experts who advise the client
providers.
Client providers already ignore significant parts of the PKIX
specification because they do not meet their performance criteria. In
particular virtually all browsers treat inability to obtain OCSP
certificate status as being equivalent to 'good'. This is a terrible
security design, one that every CA would like to see change. But it is
also a fact that we have been trying to get this changed for ten years
without success.
The browser providers do not hard fail on OCSP because doing so would
require them to wait for the OCSP response within the TLS handshake
and this is considered an unacceptable performance degradation. I do
not like this situation, but I can either play Canute and tell the
tide to turn or I can consider it to be a fact and try to work round
it.
DANE attempts to fix PKI with another mandate that is certain to be
ignored. In this case the mandate is to establish a critical
dependency on the DNSSEC trust chain despite the easily observed fact
that less than 97% of DNS resolvers will pass anything other than
A/AAAA and CNAME records.
Section 4 of the draft mandates a client hardfail if the DNSSEC trust
chain cannot be obtained. This is essential if the client is going to
use DNSSEC to establish certificate constraints just as certificate
revocation is an essential part of the PKIX model. But no browser
provider can expect to succeed with a product that simply stops
working when the user tries to surf the Web from a coffee shop.
Since the coffee shop problem is not intentional we might imagine that
it will eventually go away. But this puts DANE in a deployment
deadlock bind. Nobody is going to fix their coffee shop routers until
there is a need to and that need won't exist until the coffee shop
routers are fixed.
It is not just coffee shops that are the problem either. It might seem
really easy to put an SSL cert on a server and keep it up to date but
IETF participants represent the 1% of network admins. We all know from
experience how successful protocols that require two sets of records
to be kept in sync are. A protocol that requires a network admin to
remember to update their DNS with each cert change or suffer a
hardfail is going to have a very high administrative error rate.
Rather than mandating hardfail or any particular client behavior, the
specification should simply state that the client MUST conclude that
the DANE status of the certificate is invalid and then leave the
client to decide on what course of action to take. This will depend on
the circumstances of the particular user and the client provider's
assessment of the reliability of the DANE data and might range from do
nothing to send a security policy violation notification somewhere to
hardfail.
Contrary to the assumptions of the specification authors, hard fail is
not the best option. It is not even the best option in the case that
the users are dissidents.
To understand the logic of the dissident case it is important to have
a change of perspective. The objective of the authorities is not to
intimidate a single protester, it is to intimidate a whole country.
Being a protester carries inevitable risks. No security protocol is
going to eliminate those risks for the individual. What is important
is to minimize the risk for the population as a whole.
The Google cert pinning code did not provide much direct protection to
the Iranian dissidents because it only covered one site. But it proved
critical in exposing the Diginotar situation because it provided the
first evidence of the breach. Had the client been designed slightly
differently the breach might have become evident earlier.
The coffee shop issue is unintended but there are also parties that
are going to intentionally sabotage any infrastructure that looks like
DANE. We are not in the 1990s any longer, people in authority no
longer expect OSI to replace the Internet. The result is that it is
much harder to get away with no infrastructure. At present there is no
point in blocking DNSSEC records. But you can be sure that Iran,
Russia and China will be doing so the minute any client started to
make use of DANE. These countries can (and will) make use of a client
hard fail to ensure that people don't use browsers that might be used
for 'information terrorism' or freedom of speech as the rest of us
call it.
And don't think that out own governments necessarily mean what they
say. In public Thatcher was a stalwart champion of freedom. In private
she was begging Gorbachev to send in the tanks to stop the fall of the
Berlin wall. Her own foundation has materials that report this
exchange:
http://www.margaretthatcher.org/document/112006
The last thing I want to do is to hand the authorities another tool
that can be used to selectively shut down the network at the critical
moment in a crisis. Completely shutting off the Internet is one thing,
it probably worked in our favor in Egypt as the 101st keyboarders lost
their Internet connection and were forced to find out what was going
on in the streets. It was a visceral sign of panic on the part of the
regime.
DANE is really a form of security policy information and so far there
is no case where we have succeeded in applying raw security policy
information at the client end. DKIM policies are a success because
they are filtered and interpreted by the anti-spam services. There is
a huge infrastructure in place that is working to apply the data from
the DKIM records intelligently and equally importantly provides
feedback to publishers of inconsistent records.
DANE is proposed on the basis of a mistaken interpretation of how DKIM
security policies work in practice and the result is a protocol that
is deeply flawed and likely to fail.
It would be a pity if the lack of success of a group that has
steadfastly worked to ignore and discourage outside advice became a
precedent to avoid future security policy efforts. Security policy is
a very powerful tool, one that we can and must use if we are going to
make the insecure Internet secure. But the DANE approach is too
dogmatic to succeed.