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.

Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
dev-tech-crypto mailing list

Reply via email to