On Fri, Oct 1, 2010 at 12:02 PM, Ben Laurie <b...@google.com> wrote: > On 1 October 2010 08:29, Phillip Hallam-Baker <hal...@gmail.com> wrote: > > The reason that I started with the requirement to use SSL is that > security > > policy relating to trust criteria is meaningless until you have a > statement > > that use of SSL is required. > > I can't agree with this. If a user types an https URL, say, then > there's every reason security policy should apply despite the lack of > a statement that SSL is required.
I regard typing https as being a policy statement. I don't think anyone could use the TLSFP scheme as a substitute for DV validation for about a decade. As of today 0% of the deployed browsers support TLSFP so if someone types https and the cert is not DV validated they are going to see the self-signed cert warning box. What I would see as being much more practical is a scheme that works automatically when the user types in http. If the browser does not support the DNS mechanism then the user goes to the site unencrypted as they do today. If the browser and site both support the DNS mechanism, the communication is encrypted and the user need not know anything about it. I would like to get rid of the padlock entirely and eventually go to a user experience when the user is only warned when going to one of the few remaining sites that does NOT offer free transparent security. > I have no objection to doing security policy. But I do have a real > objection > > to an approach that negates PKIX semantics as the TLSFP approach does. > > Then I'd like to see your proposal for _optionally_ allowing PKIX to > be overridden. > _http._tcp.example.com ESRV "TLS=required CERTFP=required" This is still a potential shoot-in-foot situation for humans. But I can write a script that can extract the necessary information to do the job right. -- Website: http://hallambaker.com/
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
