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.