Re: [websec] Certificate Pinning via HSTS

Or maybe DANE should consider migrating to the WEBSEC approach.

I was pushing for DANE to consider the pinning and 'must be SSL' approach
from the start. The consensus of the group has been that they don't want to
consider those use cases at all. Furthermore the response I have got from
the key contributors has been 'we don't want to consider those issues
because we can't understand the issues and have no interest in attempting to
do so'.

The reason that I was pushing hard to get the use of prefixes fixed was
because I have been looking at these use cases for two years now and I don't
see the naive prefix approach that has been insisted on will allow for
effective security policy.

If you want DANE to be compatible with the WebSec approach I suggest that
DANE make the accommodations to the deployed HTTP and TLS infrastructure
rather than propose a completely new infrastructure and then demand that
everyone work around the legacy you have just created.

There is 20 years of Web legacy. It is big, ugly and complex. There is 0
years of DANE legacy.

PKI is really hard for reasons that go beyond the syntax and structure of
X.509v3. The complexity of PKIX comes mostly from the fact that the original
design did not have enough flexibility to meet real world needs and so a
heck of a lot that should have been in the core ended up as ad-hoc
extensions and patches. In particular X.509 was originally designed round a
PEM style monolithic hierarchy.

On Mon, Sep 12, 2011 at 8:54 PM, Richard L. Barnes <rbarnes@bbn.com> wrote:

> Hey Chris & Chris,
>
> This seems like a useful near-term approach, but also probably something
> that might want to migrate to DANE over time.
>
> Is there any particular reason you're using key fingerprints instead of
> cert fingerprints?  It seems like the latter might be slightly easier to
> implement, since you don't have to parse the cert.
>
> --Richard
>
>
>
> On Sep 12, 2011, at 5:56 PM, Chris Palmer wrote:
>
> > Hi all,
> >
> > Chris Evans and I work at Google on the Chrome security team. We have
> > devised this specification for a new extension to Strict Transport
> > Security to allow site operators to "pin" certificates: UAs will
> > require that TLS connections be validated with at least one of the
> > public keys identified in the new "pins" directive in the HSTS header.
> > (Sites can pin to one or more public keys in end entity, subordinate
> > CA, and/or root CA certificates, for flexibility and disaster
> > recovery.)
> >
> > We hope that this mechanism opens up the benefits of certificate
> > pinning to more sites. Currently, Chrome can "pre-load" HSTS behavior
> > and certificate pins for sites, but the mechanism for doing this
> > (email us!) does not scale.
> >
> > We eagerly anticipate your comments, questions, concerns, et c. As you
> > can see from the Ideas section, there are some unanswered questions
> > about the behavior of UAs and hosts, and possible extensions to the
> > policy.
> >
> <CertificatePinningExtensionforHSTS.pdf>_______________________________________________
> > websec mailing list
> > websec@ietf.org
> > https://www.ietf.org/mailman/listinfo/websec
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>

-- 
Website: http://hallambaker.com/