On Fri, Aug 16, 2013 at 5:58 PM, Wan-Teh Chang <w...@google.com> wrote:
> On Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling <rob.stradl...@comodo.com> > wrote: > > > > Wan-Teh, why do you think Firefox should specify a preference for ECDSA > over > > RSA? > > Because ECDSA is more secure than RSA, and ECC implementations will > become faster over time. > > The ordering of RSA and ECDSA is really a "symbolic gesture" right now > because they each require a certificate, and very few websites have > both an RSA certificate and an ECDSA certificate. > I agree that the ordering of ECDSA vs. RSA is mostly a symbolic gesture at this point in time due to the small number of websites that have both types of certificates, and the motivations for those sites to have both types. But, I don't think we should base the order that browsers choose based on this symbolic meaning; instead, we should base the ordering on what gives the client the best security/performance/compatibility tradeoff. I am not sure that we can say that ECDSA is more secure than RSA in a meaningful way. The old Debian OpenSSL bug and the new Android OpenSSL bug both offer some empirical evidence that implementation errors in PRNGS are more likely to reduce security than the theoretical concerns that would indicate that ECDSA is generally more secure than RSA. Also, the minimum RSA key size that is acceptable according to the baseline requirements is 2048 bits. For digital signatures, there seems to be quite a significant margin between what seems to be needed to authenticate a single TLS handshake and the security level that RSA 2048 offers. If we assume that websites will generally choose the smallest/fastest key that is considered acceptable according to the CABForum baseline requirements (RSA 2048 and ECDSA P-256) then especially on ARM there is quite a performance advantage for the client to get an RSA signature instead of an ECDSA signature. If the server is choosing which certificate to use based on the client's preferences instead of its own performance needs, then the client should be suggesting what is best for the client, on the assumption that the server is making a rational decision. More generally, the ordering I suggested isn't intended to be the ordering that servers should use if they are configured to disregard the client's preferences. For example, many servers wouldn't want to choose CBC-based ciphersuites over RC4 yet if they are concerned about BEAST or Lucky 13. But, for NSS-based clients, it does make sense to choose the CBC-based ciphersuites in the proposal over RC4 because the NSS-based clients have implemented fixes for BEAST and Lucky 13, but not for the RC4 issue. I will update the proposal to mention these things. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
