On Fri, May 31, 2013 at 11:34 AM, Jakob Schlyter <[email protected]> wrote:
> On 30 maj 2013, at 16:55, Ben Laurie <[email protected]> wrote: > > > a) It introduces latency, and > > so does checking revocation lists and OCSP. > > > b) It isn't reliable, so cannot be hard-fail. > > I'm a bit disappointed that browsers vendors are not willing to implement > new protocols, like DANE, just because there exists clients out there that > cannot reliable use them. I'm not saying we should enable these features by > default, but to be able to test them and learn more we need them in > something that is not an experimental build. > > I would even stretch my neck out and claim that the additional controls > provided by using DANE with certificate use 0/1 (i.e. backed by classic > PKIX) would make sense even without DNSSEC. I know this is a very dangerous > path and may dragons lure along it, but I still believe this is something > we should explore further. > > jakob I did tell everyone that I have been banging my head against that particular wall for the past 20 years. But did anyone listen? I predicted phishing back in 1993 and proposed DIGEST to pre-empt the problem. But it was rejected due to a UNIX superstition against shadow passwords and Rob and Ari's desire to be able to use the existing UNIX password file to validate requests. The reason I am proposing Omnibroker is because changing the browser is hard and if we are going to improve Web security we need to decouple security research from the need to deploy new browsers. If we can get them to do omnibroker then we make one change and we move the security nexus out to a place where we can do interesting stuff. -- Website: http://hallambaker.com/
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
