On 6/3/13 5:16 AM, "Ben Laurie" <[email protected]> wrote: >On 31 May 2013 16:34, 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. > >Which is why they're default off. > >>> 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 don't have any particular view on whether browsers should or should >not implement protocols that don't work reliably, but my goal is to >accept reality and implement something that _is_ reliable (i.e. >Certificate Transparency).
It may be reliable but it does not address the problem the less reliable protocols address so you will still need to implement something else. The CT spec acknowledges this. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
