On Sep 10, 2011, at 8:28 AM, Ian G wrote: > Hi Adam, > > On 10/09/2011, at 20:16, Adam Back <a...@cypherspace.org> wrote: > >> So I hear CA pinning mentioned a bit as a probable way forward, but I didnt >> see anyone define it on this list, > > Adam described it in this list. The specific mechanism is less important than > what it achieves: the browser knows that the website is constrained to use > the certs of only one CA. > > The rest is implementation detail.
It's not at all though! Today CA compromise isn't even a, let alone the most, common way of "exploiting" the blanket trust of all CAs involved in the PKI infrastructure. The two most common methods are: 1) MITM where the attacker controls the victim's network connection to some extent and redirects them to or proxies them through a different server. 2) Phishing using a similar-looking domain name. In case 1 any type of pinning that is not hardcoded in the software, like with chrome which I assume we can all agree is not a scalable solution, does absolutely nothing to stop this. Especially DNS pinning. Unless some magical milestone was passed where clients now have full dns sec validating resolvers installed with correct '.' trust keys and I missed something? Considering dnssec is designed so that clients will most likely never actually do direct validation means that even in the mythical future where dnssec is fully deployed it won't stop this attack. In the more common case 2 the attacker already controls all said information about the similar domain and pinning therefore does absolutely nothing. This vector is only going to get more interesting as more CAs let certs for domains with fun unicode characters slip through. Oddly enough, I think any solution that adequately addresses these two common cases would also make it simpler to deal with compromised CAs. This is where discussion should be focused and would actually be productive. > >> so from web search what I can find is >> that certificate holder can define the CAs that are allowed to issue certs >> for its domain. > > Where the info comes from is less relevant. Yes, the subscriber could it. So > could the user (TrustBar, Petnames) or the vendor (google). It is very relevant as I just pointed out. I think it comes down to, as has been stated several times lately here and on other lists and similar threads: PKI never solved any of these problems to begin with and had way too narrow a use case defined in the design process to be useful as it is actually deployed in the wild today. The real question should be: What should we use instead? -- Douglas Huff
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
