I am starting to work on a suite of drafts to set out the architecture I described earlier in the pdf document. The starting point I am working from is the security policy draft Rob and I wrote earlier:
http://tools.ietf.org/html/draft-hallambaker-securitypolicy-01 The idea of this draft was that it would serve the needs of static security policy distribution which is one of the modes of policy distribution we are going to need. I see a need for the following documents: 1) Security Policy Specification * Abstract security policy statements * Format for representing static security policy statements by trust brokers * Format for originating security policy as DNS headers * Format for originating security policy as application (i.e. HTTP) headers 2) Online broker protocol * Abstract protocol * Web Service REST binding * UDP REST binding * DNS binding 3) Architecture document In a bit more detail: 1) Security Policy Specification Having looked at this problem a lot I think we need to support more than one way to exchange security policy statements. In particular there is definitely a need to be able to originate security policy as application headers (e.g. WebSec pinning) and the DNS is clearly the proper infrastructure to originate authoritative statements about domain names. But merely originating security policy is not enough. First it is unlikely that there will be a great deal of security policy available to start with. Second, relying on administrator originated assertions is likely to give too many false positives to hardfail. So the scenario I think will prevail at the start is something like 5% or so of SSL web sites publish security policies through the DNS 20% or so publish security policies as application headers 90% or so of Web sites are stable enough for a low confidence security policy to be inferred by observation and heuristics One of the things we have learned from experience is that detecting and reporting security policy violations has greater benefit to the community of users than merely protecting individual users. So things like Convergence and CT and such add to what is provided by the EFF observatory alone, but the core value comes from detecting and reporting. The good news is that we can get detecting and reporting for 90% of the Web through the trust broker model without any adoption by Web sites. This is critical as far as deployment goes as it breaks the deployment deadlock cycle. There is an incentive for clients to deploy on day 1. As the number of deployed clients increases, there is an incentive for Web sites to originate policy assertions and guide the process. I see two modes for broker interactions. The first is a static hotlist of 'critical' security policies that the trust broker pushes out to the client. This would be used for ensuring policy enforcement in cases of actual attack. Some sites are attacked so frequently as to make the permanent hotlist. The second mode is an online protocol performed on a per IP connection basis and has rather different performance constraints and so needs to be considered separately. 2) Online broker protocol At present a HTTPS client typically performs the following interactions: 1) DNS lookup to resolve 'www.example.com' 2) Connect to port 443 on www.example.com 3) Start TLS session, acquire cert 4) DNS lookup to resolve ocsp.ca.com 5) OCSP request to ocsp.ca.com 6) WTF starts TLS session 7) OCSP response is received (too late) Adding in a call to a trust broker on top is a non starter. So any trust broker interaction has to replace either or both of the DNS and OSCP interactions. I suggest both. So the abstract protocol becomes 1) UDP request to trustbroker.com ? DNS-name + Port + Protocol *(+ options) UDP response : IPaddress + Port + SecurityOptions *(+ options) *(+ proof) 2) Client connects to specified IPaddress, port, etc. The proof might consist of: DNS RRs DNSSEC RRs Notary statements Certificates SAML assertions etc. How much proof a client requires would depend on the application and the user. Needs will differ. As a practical matter, there would be a need to use the protocol when the only ports available are 80, 443 and port 53 to the DNS resolver chosen by the ISP. So there would be a need to layer the protocol onto DNS. This would probably mean some sort of BASE32/64 encoding hack and TXT records. Trying to pass proof over that type of connection is probably a non-starter and so there would have to be a http/REST service as well. -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
