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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
