More information on the scheme I am proposing is to be found in the following document: http://www.ietf.org/id/draft-hallambaker-securitypolicy-01.txt
One of the conversations that came up yesterday was why WebSec should do pinning if DANE is already doing this via DNSSEC. At the top level there are three major reasons. 1) WebSec was originally chartered to consider Security Policy in the form of Strict security. Thus as a process matter WebSec has a strong claim to address other forms of security policy 2) The DANE charter does not explicitly call out security policy as a deliverable. Thus while DANE has made Security Policy its primary concern as a WG it has no process claim to 'own' the issue as an IETF matter. 3) The approach taken in DANE does not support Security Policy as a stand alone function., It is only possible to use their key distribution if you also buy into their key distribution, it is only possible to use their key distribution if you buy into their security policy. It is not possible to use either independently. As a result I am unable to use either. In particular, I am very, very annoyed at the constant bleating of 'don't beat up on DNSSEC' followed by attacks on the existing PKIX infrastructure based on the claim that DNSSEC is absolutely perfect in all respects and 'more secure'. This happened several times during the WG meeting this morning. I note that each of the three individuals who protested that this was not the place to discuss the security of DNSSEC then went on to do exactly that. So what they were really demanding was a chance to get in as many free hits as they like against PKIX while running to hide behind mummy when the security of their proposal was examined. I do not have a great deal of respect for that mode of argument. If people want to argue that their new proposal is better then fine. But they are not going to get the free hits they demand. There are in fact many reasons to be skeptical of the DNSSEC system. Note that I am a proponent of DNSSEC and have argued for advancing it for the past ten years. But it is still a completely new infrastructure and is simply not ready for use as a PKIX replacement even if that is considered to be a worthwhile goal. My interest in DNSSEC has from the start been to provide a model of key distribution for very low assurance keys and to provide the basis for a security policy mechanism for very high assurance keys. The two application areas are almost entirely disjoint. First let us consider the components of the DNSSEC system. They have different levels of maturity. 1) ICANN Root Infrastructure 2) Domain Level Signatures 3) Registration of Domain Level Keys via registrars 4) Interface between the registrars and the registries 5) DNS query protocol Of these (1) and (2) are as good as can be expected. The major problems are (3) (4) and (5). On (3) the major problem is that the registrars are not specialists in cryptography. Sale of DNS names is a loss leader as far as their business models are concerned. As a commercial proposition it is highly unlikely that the registrars are going to invest in enabling DNSSEC unless that is going to provide a commercial return. Demand for DNSSEC is currently negligible and likely to remain so until critical mass is established. As a commercial proposition it really makes no difference to a CA if the basis for PKI is PKIX or DNSSEC. They both require the same degree of customer hand holding and support. During a transition period customers would need to deploy both so DNSSEC represents a growth opportunity. DNSSEC does not provide accountability and so does not provide a basis for EV type certificates. The major security problem is at step (4). Contrary to the claim of having a single CA, the DNSSEC ecosystem actually has a separate CA for each top level domain and several hundred entities that function as RAs beneath it. So even though I can only get a .com through the VeriSign registry, I cannot buy a domain from VeriSign direct. I have to go through one of several hundred registrars or several thousand resellers instead. The degree of complexity in those systems is vast. There is no party in the system that has oversight of the whole thing. While there are procedures in place that enforce 'domain locking' at the registry level, these depend on the interface between the resellers and the registrars being correct. Domain hijacking at the registrar level is a very, very frequent occurrence. So frequent that it no longer even attracts notice unless the target is a major player such as Twitter. On (5) the deployment of the DNS protocol does not support DNSSEC sufficiently reliably to use it as the basis for distribution of either key distribution or security policy. The most important limitation on the DANE infrastructure is what it does not attempt to provide. There is no party in the system that accepts any liability for operation of the PKI under any circumstances whatsoever. As a result the injured party in a breach is likely to sue every party they can in a joint action including the registry, registrar and browser vendor. Of these the registry is likely to have a good legal excuse, the registrar is unlikely to have the resources to fight the suit let alone pay damages leaving only the deep pockets of the browser vendor to catch the liability. Expecting that the browser vendors would accept this situation is rather naive. The reason that Microsoft and Netscape insisted on the formation of VeriSign (the CA) in the first place was to catch the liability. DANE as currently proposed requires that the domain owner switch from the established PKIX infrastructure that has known vulnerabilities and a very low rate of breaches to a completely new and untested infrastructure that has frequent breaches and is potentially subject to new and unexpected failure modes. DANE is intentionally an all or nothing proposition. I have to eiher drink all the KoolAid or not do any of it. I cannot pick out and use the parts that I want independently. Unpacking the key distribution and security policy functions and addressing them separately allows for the limitations of the immature DNSSEC system to be worked around. For key distribution any system must be as reliable as existing use of self signed certs. So I want to use a system that only depends on components (1) and (2), the components that are currently mature. DANE does not meet my needs in that respect because it forces me to depend on the DNS query protocol infrastructure what has a major legacy transition problem. The problem of key distribution has in my view been almost completely solved by Kaminsky and Langley in their proposal to pickle out the DNSSEC chain and place it within a certificate. If they are willing to change that approach to putting the DNSSEC validation chain into a stapled OCSP token instead then the objections resulting from the different validity intervals of the DNSSEC data and the Certificate data are completely resolved. The self signed cert can then have the long term validity interval required to make use acceptable with legacy browsers that will query the user on every certificate change and the DNSSEC validity information can be regenerated each time the zone is re-signed. For Security Policy it is very clear that DNS is one of the mechanisms that should be involved. DNS is the Internet infrastructure for making authoritative assertions about domain names. Security policy is an assertion about a domain name. Contrary to the arguments raised in the WG meeting however, effective use of Security Policy published in DNS does not mandate DNSSEC. The most valuable use of Security Policy information is to detect and report violations. Blocking user access to a site only protects one user and false positives impose a major cost. Since Security Policy is a new concept, false positives are inevitable. Over the past decade there has only been one incident in which genuine positives would have been detected and then only if you happened to be in Iran. While demanding a 'hard fail' position is clearly desirable to me from a security point of view, I can't see that I am likely to get it while the browser vendors still refuse to hard fail on lack of access to OCSP data. Over time we may well move to a position where browser vendors are willing to move to a hard fail model on security policy misconfiguration. In the transition period, I see the following as being more likely to be acceptable: * Security Policy Origination Security policy may be declared through DNS records, HTTP headers or out of band means (e.g. tell CABForum or APWG that you are a really serious phishing target). In some cases security policy will be obtained heuristically. * Security Policy Curation Security Policy is hard because it throws up many corner cases that can easily rat hole. Having some form of curation of the raw policy data allows these corner cases to be pushed to some intermediary that can handle them intelligently on a case by case basis. The principle experience that IETF has of security policy is in DKIM. Actual deployed DKIM security policies are of variable quality. But even though the information they provide is not a 100% accurate guide, DKIM works well in practice as one of the (many) inputs into anti-spam systems. Depending on raw Security Policy information may well prove to be impractical. But that is not the only option we have. Anti-Virus systems do not depend on code signing alone, they use it as one input into their systems. Code signing does not prevent code from being malicious, but once malicious code is found signed under a particular key then all other software signed under that key comes under a higher degree of scrutiny. If a Security Policy system is deployed and it just works then this component will be superfluous. Otherwise the ability to perform some form of curation of the raw security policy provides the answer to the various objections being made of practical experience such as what to do when the system administrator fouls up. At present the response to a CA breach involves various parties round the world being called out of bed to respond. We are dealing with an intelligent attacker who changes their attack in response to the countermeasures deployed against them. Thus having the option of curating the raw policy data is likely to be of significant value in developing the right response. * Security Policy Distribution Security policy may be distributed through multiple modes of distribution. No single distribution mode can ever be relied upon in all circumstances and provide the scalability and robustness required. If there is knowledge of an active attack against a very high value domain then the most appropriate technology is to push out a hotlist of security policy statements that includes that domain. That particular mechanism does not scale but it is capable of scaling to provide absolute protection for 95% of the most risky transactions. Even if such a mechanism is never actually used it would be very useful to have in our back pocket to use when needed. http://www.ietf.org/id/draft-hallambaker-securitypolicy-01.txt Hotlists do not scale and so some form of online mechanism is essential. HTTP headers and DNS statements both have pros and cons. But in practice both these channels are subject to MITM attack and DoS by nation state actors. Note that for the Iranian State adversary, denying access to Twitter is one of their main goals. In practice any distribution mechanism that is going to be effective in those environments is going to have to be capable of circumventing the normal communication channels that can be blocked. Thus end clients are going to need to be equipped with the capability to employ a range of distribution mechanisms. -- Website: http://hallambaker.com/
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
