Re: [websec] Certificate Pinning via HSTS

I think we have a potential convergence here between four sets of security
policy data and four delivery mechanisms:

A) Revocation information for certs/roots
B) Security protocol policy 'MUST USE TLS'
C) Security Trust Policy 'use only this CA'
D) Reporting

1) Data baked into the browser
2) Data pushed out to the browser in a signed format out of band
3) Data acquired by the browser from HTTP headers
4) Data acquired by the browser via DNS/DNSSEC

The first clearly does not scale but has huge leverage since ten domains
represent the biggest targets on the net for certain typs of criminal
behavior.

The second does not scale either but provides us with a vital tool to use
when responding to an actual in-progress attack.

The third scales but only gives secure after first contact. It is difficult
to see how far hardfail will be practical.

The fourth scales but is dependent on deployment of infrastructure and
access to that infrastructure which means that it is going to be some time
before clients can hardfail if the data is not available.

Having the three mechanisms using a common data format allows for an agile
approach to response.

For example let us imagine that paymentgate.com is attacked and a bogus cert
is issued.

paymentgate.com has decided that it is a likely target for attack and has
implemented and published a security policy through DNS records and
published it with DNSSEC.

paymentgate.com is not however sufficiently prominent to be amongst 10 or so
security policies that are baked into browsers.

A client that has _reliable_ access to DNSSEC data will detect the bogus
cert and reject it. But that is only going to be effective if the browser
can hardfail if the DNSSEC data is not present. If Iran is performing a
network level MITM attack you can be certain that they will strip all DNSSEC
data the minute that any deployed clients start relying on it.

So perversely DNSSEC only provides direct security for the people who are
not likely being attacked. :-(

We can however get some DNSSEC data through using other channels and so it
is quite reasonable to expect that we can get a notification that the attack
is in in progress by those clients reading the security policy data in the
DNS and then making use of whatever reporting infrastructure we build into
those clients.

However we have the option of using the Langley/Kaminsky hack of pickling a
chain of DNS data and putting it into another signed object. For example a
certificate or an OCSP token.

So when a report is received, the browser provider looks at the taget(s) of
the attack and can attempt to retrieve security policy from the DNS. If
there is a published policy they can decide to add paymentgate.com to the
list of data driven security policy they push out.

So in summary, I would like to address all four delivery mechanisms as if
they are merely different delivery mechanisms for the same data types.

Despite that, I would like all three mechanisms to employ the
On Tue, Sep 13, 2011 at 2:11 PM, Chris Palmer <palmer@google.com> wrote:

> Hi everybody,
>
> Thanks for your comments and questions — good ones! I'll try to
> address them in the XMLified draft that I'm working on now, and which
> I'll send out today.
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>

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