Re: [TLS] Cert Enumeration and Key Assurance With DNSSEC

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Oct 1, 2010 at 12:02 PM, Ben Laurie <[e-mail]> wrote:

> On 1 October 2010 08:29, Phillip Hallam-Baker <[e-mail]> 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/