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