So far I don't see any interest in production deployment other than our own plans so I don't think your working group consensus has relevance. The point I am making applies to all forms of security policy, not just DANE. If the party enforcing a security policy is not the same as the party asserting it, the party enforcing that policy can and will treat it as advice. The big problem with all security policy mechanisms is that the policy records have to be maintained separately from the system being administered. That will inevitably lead to incompatibilities between the policy and the practice. Attempting to rely on raw, uncurated security policy records is a certain recipe for failure. You can try to order the policy enforcement point around in the Request For Comments, but here the comment is going to be 'we don't want to do that'. On Thu, May 3, 2012 at 11:54 AM, Ondřej Surý <ondrej.sury@xxxxxx> wrote: > Phillip, > > I haven't seen any consensus for the change of the document, thus > chairs think the document is fine as it is. > > Ondrej > > On 25. 4. 2012, at 15:52, Phillip Hallam-Baker wrote: > >> 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. >> _______________________________________________ >> dane mailing list >> dane@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/dane > > -- > Ondřej Surý -- Chief Science Officer > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@xxxxxx http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > -- Website: http://hallambaker.com/