Eddy Nigg (StartCom Ltd.) wrote: > Frank Hecker: >> (As a side note, based on my experience with and reading about >> industry dynamics, I think that advances in PKI-related technologies >> are much more likely to occur in new protocols and new products than >> in mainstream cases like browsing SSL web sites. A good example is >> Skype's implementation of an internal PKI infrastructure for securing >> VOIP traffic.) >> > > Outshhh, I don't like to even get into this one :-) > Except that they are using some kind of PKI and I'm not sure what's so > exceptional or new with it.
I don't want to go off on a tangent, but I think the Skype model is more significant than you think. I don't agree with Ian Grigg on everything, but I do think his proposed rule that "there is only one mode, and it is secure" is worthwhile: http://iang.org/ssl/h3_there_is_only_one_mode_and_it_is_secure.html As I understand it, out of the box Skype achieves encryption of users' VOIP calls and strong identification of a particular user's node (not tied to IP address), with no action needed on the part of the user. It doesn't tie a verified legal identity to the Skype instance (and so doesn't fit the classic X.509 model), but arguably this is not important for typical Skype use cases. >> I also think that with the advent of EV and the Firefox 3 UI that the >> world of certs will divide into EV and everything else (OV/IV/DV). >> Maybe I'm missing something, but I can't see any discernible >> difference between the UI for https://www.bankofamerica.com/ (OV cert) >> and the UI for https://www.hecker.org/ (DV cert). > > Which I personally view as a mistake, because I believe DV and IV/OV > certificates should be separated. See my separate comments on this point. > If EV doesn't become mainstream and > will replace IV/OV certs, than Mozilla (and the industry) will have to > come up with some better answers and address this particularly. If EV doesn't become mainstream, then IMO that will signal the utter irrelevance of the traditional PKI/CA model in terms of protecting user security for high-value transactions. After all, the EV model is the very embodiment of traditional thinking about how PKIs can protect user security: have a trusted third party do strong verification of legal identity and bind that identity to a public key, and have users then rely on that authenticated identity before entering into high-value transactions. If web site operators don't care to participate in the EV scheme, and web site users don't care if they don't see a strongly validated identity in the browser UI, then the only significant function of SSL in practice is to provide over-the-wire encryption and some minimal protection against MITM attacks. > When in the software world an exploit is detected, the software is > usually patched. When an exploit is detected in NSS, it's going to be > patched. If however an exploit is detected by a CAs procedure you > propose we do nothing until you are convinced that actually somebody is > exploiting it and than you propose to adjust the thinking about the > proposed threat. Really Frank? If there is a significant cost to protecting against a hypothetical exploit, and there are alternate means of dealing with the exploit in question (particularly more general measures that address more than just the exploit in question), then I suggest that we think carefully before investing time in implementing protection measures designed to deal specifically with such a hypothetical exploit. Take your idea of requiring identity verification for wildcard DV certs, which is designed to address the hypothetical threat of people setting up SSL-enabled phishing sites under their top-level domains (e.g., paypal.example.com). There's are multiple cost to implementing such an idea: a cost to CAs (who may have to change their procedures and product offerings), a cost to cert subscribers (who may have to pay more for certs), a cost to us (who have to figure out all the CAs doing wildcard DV certs, and then try to persuade them to change what they're doing), and potentially a cost to end users (e.g., if they can no longer access sites because we decide to punish CAs by removing their roots or disabling validation of certain wildcard certs). At the same time there are measures already in place to protect users against the general phishing threat, most notably the Firefox "phishing protection" features; these measures work against phishing sites using the hypothetical wildcard DV cert exploit, and against other phishing sites as well. There is also a general measure available to provide more assurance and accountability for web sites doing high-value SSL-enabled transactions, namely EV certs. So the specific question for me is as follows: Should I devote Mozilla Foundation resources (including my own time) to trying to combat the hypothetical threat posed by wildcard DV certs, a threat for which other protection measures already exist and would appear to be effective, or should I devote those resources to other tasks that arguably offer a greater return on investment in terms of increased security, like say getting more EV-qualified CAs approved to have their EV certs recognized in Firefox? That's a pretty easy question for me to answer. Frank -- Frank Hecker [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
