Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Thu, Aug 15, 2013 at 10:15 AM, Chris Richardson ch...@randomnonce.orgwrote: I believe this plan would have poor side effects. For example, if Apple ships clients with a broken ECDSA implementation [0], a server cannot detect detect if a connecting client is an Apple product and avoid the use of ECDSA in that subset of connections. Instead, ECDSA suddenly becomes unsafe for anyone to use anywhere. I think your argument is more about the Future work: A comprehensive profile for browsers' use of TLS part of the document, since the fingerprinting that OpenSSL is now using to detect Safari 10.8 uses the presence and ordering of TLS extensions like SNI that are not in the scope of the current proposal. Although I think browsers could now realistically all agree on the sequence of ciphersuites to offer by default in their client hello, we're far from standardizing on the contents of the entire client hello. Let's defer the debate the pros/cons of completely eliminating fingerprinting in TLS until it is more realistic to do so (if ever). Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco cvie...@mozilla.com wrote: Hello Brian I think this proposal has 3 sections. 1. Unifing SSL behavior on browsers. 2. Altering the criteria for cipher suite selection in Firefox (actually NSS) 3. removing certain cipher suites from the default firefox ciphersuite. On 2: The proposal is not clear. I want an algorithmic definition. snip This criteria gets to your ordering proposal. What do you think of re-framing your list in a criteria like this? (note national ciphers could go in step 6 instead of step 3). That sounds reasonable to me. I did not invest too much effort on making the results computable from the rationale section because I think it is likely that a lot (or all) of the rationale section would be reduced or removed from any IETF internet draft that proposed a web browser profile of TLS. On 3: Not adding: TLS_(EC?)DHE_RSA_WITH_AES_(**128|256)_CBC_SHA256 Disagree I dont think a potential performance issue should prevent us from deploying that suite as there could be sha1 attacks that we dont know of. Now that NSS has AES-GCM, we have an alternative to HMAC-SHA1. Also, if we are a little presumptuous, we can expect to have a third alternative in Salsa20/12+(UMAC|VMAC|Poly1305) sometime in the near future. If we find it is important to offer HMAC-SHA256/384 later, we can do so then. But, if we add them now, we will have difficulty removing them later. If we have enough space in the handshake I see no problem in including them. We will have to determine whether the 256-byte client hello limitation is really something that we have to deal with in the long term. But, even if that turns out now to be something we need to ever worry about, I would still be against adding HMAC-SHA256/384 when there seem to be better alternatives that do not regress performance from what we're offering now. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
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
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Aug 12, 2013 at 6:52 AM, Gervase Markham g...@mozilla.org wrote: On 09/08/13 18:12, Brian Smith wrote: No, each combination is hard-coded into its own distinct code point that is registered with IANA: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 . This is a design choice based on the fact that many crypto modules don't let you mix/match algorithms at will, and because you often can't/shouldn't move keys between crypto modules. OK. So you are choosing from a fixed palette, and changing that palette is outside the scope of this proposal? It is possible to add new cipher suites, but new cipher suites should have substantial value and a realistic shot at becoming widely-deployed. I agree this is theoretically possible but, as Tom points out, if we posit an attacker who can see your traffic, the chances of you concealing the identity of your user agent from him are pretty small. When risk is there to a user of having a network eavesdropper able to tell that they are using a particular browser? If I had an exploit for a particular browser, I'd just try it anyway and see if it worked. That seems to be the normal pattern. One example is Tor: it tries to look like a normal browser so that it is hard to detect that you are using Tor. And, if Tor is properly configured then the network attacker will never see any non-TLS traffic. * Re: Camellia and SEED: we should talk to the organisations which pushed for their addition, and our business development people in the region, before eliminating them. (This is not to say that we will definitely not remove them if they raise objections.) Do you have suggestions for who to contact? The first person I would talk to would be Gen Kanai g...@mozilla.com, although he may put you in touch with others. Thanks. I will send ask him to forward a link to these threads to the people he thinks may be interested in it. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
