Hi! Sorry for being rather late in my reply; most of your questions/remarks are already answered.
> The guide is not backward compatible with all clients. We, at Mozilla, must > maintain > backward compatibility with even the oldest, most broken, clients on the > internet, and > this shapes our guidelines. For example, the ciphersuite B doesn't contain > 3DES or RC4, > and is therefore unusable on *a lot* of PC that still run Windows XP. I wish > we could > just remove these two ciphers, but it's not a realistic goal in the near > future. True. I personally consider unsupported software depreciated and will not put effort in supporting it. In case you need to support WinXP and Java6 we discussed a workaround some months ago: you may simply use the lack of SNI support in those software stacks to provide a default virtual host with a weaker cipher set hinting the user to upgrade their clients/cryptostack/os/whatever. Java7, however, supports SNI -- therefor this will not work for Java7. Another possibility would be to filter access to certain services (login for example) based on a cipher white list: only users with strong ciphers are allowed to access the login page; the rest gets redirected to a different page. Both of those recommendations are way beyond the scope of our guide, I guess. And at least the second one is not trivial to get right... ;-) There is another aspect too: this cipher string is meant to protect secrets (passwords and the like) for at least some reasonable amount of time, so I see no way to offer support for Java6 or WinXP (at least with its default crypto stack). If I understood correctly you are trying to achieve some kind of opportunistic encryption where it does not matter that much how strong the crypto around the download really is: if that is the case, you may just enable 3DES and/or RC4 and you're fine off. But that case is different for two reasons: First you are a real sysadmin able to choose on your own (which is excellent btw.) and second there is a difference in secrets that need protection. > I *think* they want to prefer CAMELLIA to AES, judging by the published > ciphersuite. > But the construction must be wrong because it returns AES first. If the > intent is to > prefer Camellia, then I am most interesting in the rationale. The intention of the cipher string is to support both: CAMELLIA and AES as ENISA recommends in their paper too. That it returns AES first is unfortunate and caused by OpenSSL: all the CAMELLIA suites in TLSv1.2 aren't implemented in OpenSSL, so e.g. no CAMELLIA+GCM is available and no CAMELLIA with SHA-2. The ordering of ciphers by putting SSLv3 (and TLSv1.0) at the end and prefering TLSv1.2 is obvious (see +SSLv3 in the cipher string). > ECDSA is explicitely discarded. It doesn't hurt to have it enabled, and > makes the > ciphersuite portable to systems that prefer ECDSA certicates (granted, > it's not that many...). Yup. We disabled DSA because all our recommendations deal with RSA; adding DSA would need more research on best practices and the like around DSA. -- Adi
signature.asc
Description: Digital signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
