Hi again Ian, Yes I can appreciate that there are priorities and you're reluctant to get into something overly complex. It's probably wise then to drop any attempt to have the application sort out which is the weaker link and instead just bubble that information up to the user, so that they can assess whether or not the connection they've established is secure. It would be ideal if Firefox could steal a trick from putty where the user can set lower bounds--say allowing the user to specify a lower bound on the algorithm/strength used for each of authentication, agreement, and encryption. That's an ideal though, and short of that, it would be nice simply to be able to know.
Certainly you would want the information to be accurate information, and not a guess. The TLS spec does actually say that applications should not rely on TLS negotiating a secure connection but instead should check whether the parameters achieved are acceptable. I'm not so familiar with it, but it seems to me that implies there is actually a way for the application to check what was negotiated in a reliable way. A first simple stab at checking would be simply to display it somewhere, enabling the user to decide whether or not it's sufficient. As for the small devices with weak processors, the question there is really whether or not security should be compromised in the name of efficiency. In such cases I think it's probably even more important to display the values to the user so that no-one makes the mistake of believing those devices are actually good enough for secure applications. Justin On Aug 21, 8:40 am, Ian G <i...@iang.org> wrote: > Hello Justin, > > On 20/08/2009 17:45, Justin wells wrote: > > > Hi Ian, > > > Thanks for your reply! It's very enlightening, and I do agree that in > > the real world there are a lot of issues other than the cryptographic > > issues. Just to be sure, I am not suggesting that the weakest link > > should be as strong as the strongest link. I am just trying to > > understand how weak the weakest link is. > > OK. Well, imho you will not find it looking at the numbers. The > problem with the numbers is that they are comparable, but they are not > indicative of overall strength. > > > So far I haven't been able to find any documentation, or anyone, who > > can tell me what I actually get when I connect to a website. For all I > > know my browser is exchanging keys with a 256bit RSA key and then > > telling me that it's established a secure connection. > > > As you say RSA>2k is secure enough for most purposes, per NIST a > > 2048bit key is good enough for data that needs protection only to > > 2031, after which 3072 bit keys are acceptable. All I'm trying to do > > is sort out whether I've got that level of protection or not, and it > > seems tough to figure out. > > It is. Nelson provided a hint, there is a complicated key exchange > function in SSL that does "stuff" ... it's been far too long since I > read the SSL spec, but from my recollection, the way the key exchange > works, you don't get the "bit-strength" of the numbers. > > (I don't want to speculate more ... ) > > So, if the bit strenth of say 2048 RSA is not actually used, printing it > out to users is a classic case of false sense of security. > > > For Firefox I'd like to make the recommendation that the text that > > reads "Connection Encryption: High-grade Encryption (AES 256bit)" and > > the like be altered to instead state the strength of the weakest link, > > which in almost all cases is presumably the key exchange. Even AES 256 > > weakened by the recent attack is still providing some 110 to 112 bits > > of security, which is most likely still better than whatever is being > > used for key agreement. > > > If you are really going to assert that this is not the important > > factor then perhaps some caveats should be added to the "it is > > unlikely anyone read this page" message that Firefox prints just after > > giving the content encryption strength. > > Well, ok, it is possible to do this, but (a) it takes away work from > other important areas. Of which there are many many more important than > giving a user a number to play with; and > > (b) to do this properly is probably quite a serious exercise, it is akin > to the original work done by the 2 cryptographers who compared symmetric > and asymmetric, and came up with a table of comparisons > (ref,http://www.keylength.com/for the complete story. Nist copied them). > > Because SSL is quite complicated and has a lot of different parts and > interactions, it is likely quite an exercise to predict a single bit > strength metric. Not unwelcome results, but see (a). It's maybe the > sort of thing that would be suitable for a final year uni student as a > project. > > (c) unless this is done properly, I'd suggest not printing out these > numbers, because they lead to false senses of security. > > (d) for interesting comparison, see the Verisign / EV / mobile > discussion where we are grappling with the need to preserve the low > keylengths. That's another light on the overall problem space. > > iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
