On Tue, Nov 11, 2014 at 6:01 PM, Orit Levin (LCA) <[email protected]> wrote: > https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/
> o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]. > > Rationale: TLS 1.0 (published in 1999) does not support many > modern, strong cipher suites. I think that the lack of a per-record IV for CBC-based cipher suites is a more serious issue. Also, I think the fact that the TLS 1.0 specification does not say " The receiver MUST check this padding and MUST use the bad_record_mac alert to indicate padding errors." is another more serious problem. > o Implementations MAY negotiate TLS version 1.1 [RFC4346]. > > Rationale: TLS 1.1 (published in 2006) is a security improvement > over TLS 1.0, but still does not support certain stronger cipher > suites. The rationale SHOULD NOT for TLS 1.0 is that it doesn't support many modern, strong cipher suites. But, the set of cipher suites supported by TLS 1.1 is the same, or approximately so. > o Implementations MUST support, and prefer to negotiate, TLS version > 1.2 [RFC5246]. I suggest clarifying this as "Implementations MUST support TLS 1.2, and MUST prefer to negotiate TLS 1.2 over earlier versions of TLS." If/when TLS 1.3 or later versions are ready, it probably wouldn't be good to still prefer TLS 1.2. Section 3.1.3 "Fallback to Lower Versions" is unclear: Does it apply to the standard, "secure," type of version rollback that is protected by the TLS handshake, or does it apply to the non-secure fallback that the TLS_FALLBACK_SCSV is designed to protect. > o Ticket keys MUST be changed regularly, e.g., once every week, so > as not to negate the benefits of forward secrecy (see Section 7.3 > for details on forward secrecy). > > o Session ticket validity SHOULD be limited to a reasonable duration > (e.g., 1 day), for similar reasons. IMO, session ticket keys should be rotated at about half the frequency that session tickets are invalidated. So, if you're recommending session tickets last no more than one day, then session ticket keys should be rotated every two days, at a minimum. > To counter the Triple Handshake attack, we adopt the recommendation > from [triple-handshake]: TLS clients SHOULD ensure that all > certificates received over a connection are valid for the current > server endpoint, and abort the handshake if they are not. TLS clients MUST always ensure that the server's end-entity certificate is valid for the server's identity on every handshake. Also, that wasn't really the issue with triple handshake for most implementations. The issue that most implementations had with triple handshake was that they did certificate verification for renegotiations too late in the handshake, after they'd already sent private data using the keys negotiated during the renegotiation. For example, Firefox did the certificate verification before sending any secret information under the new keys, so it wasn't vulnerable, but MSIE and Chrome (IIUC) waited until the renegotiation handshake was finished, which was after they'd sent private information using the new keys. So, IMO this whole section needs improvement. > o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > > o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > > o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 I generally agree with these recommendations, but I think it is inappropriate to recommend that clients support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 or TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 at this time. Too many servers only have 1024-bit or smaller(!!!) DHE keys, and there's no way for the client to negotiate a minimum DHE key strength yet. Mozilla's data for the Firefox web browser [1] shows that in the most recent release, 97% of handshakes that use TLS_DHE_* cipher suites use a 1024 bit key and 2% of handshakes that use TLS_DHE_* cipher suites use 512-bit(!!!!!) keys. Approximately 0% of connections that negotiate TLS_DHE_* cipher suites use a key DHE size that meets the minimum 112 bit security level that the document is attempting to acheive. > Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the > first proposal to any server, unless they have prior knowledge that > the server cannot respond to a TLS 1.2 client_hello message. The team that implements NSS decided that it is better to suggest TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ahead of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Also, Google Chrome often proposes ChaCha20-Poly1305 cipher suites ahead of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. I believe that these are reasonable and even good policies, so I think that the above text should be rewritten in such a way that NSS and Chrome's behavior meets the requirements. > Servers SHOULD prefer this cipher suite whenever it is proposed, even > if it is not the first proposal. This is not a good suggestion, for similar reasons. Many (most) servers, when given the choice, will prefer TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 over TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for performance reasons. > This document is not an application profile standard, in the sense of > Section 9 of [RFC5246]. As a result, clients and servers are still > REQUIRED to support the mandatory TLS cipher suite, > TLS_RSA_WITH_AES_128_CBC_SHA. A BCP defining cipher suite recommendations should not have a higher level of requirement for TLS_RSA_WITH_AES_128_CBC_SHA than it has for TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, at least. I think it is OK to just say that the TLS specification was wrong to mandate TLS_RSA_WITH_AES_128_CBC_SHA, or don't mention it at all. > With regard to PKIX certificates, servers SHOULD support OCSP and > OCSP stapling, including the OCSP stapling extension defined in > [RFC6961], as a best practice given the current state of the art and > as a foundation for a possible future solution. Please also say that servers SHOULD support the original stapling mechanism, the certificate status request extension defined in RFC6066, section 8. In practice, no clients support the RFC6961 mechanism, and that lack of support is partly intentional and unlikely to change soon. Also, some browsers are working on new revocation schemes that they feel make RFC6066 irrelevant for them, but where RFC6066 is likely to remain relevant. Accordingly, it is fine to recommend servers support RFC6961 but it is even more critical that they support RFC6066. Cheers, Brian [1] http://telemetry.mozilla.org/#filter=release%2F33%2FSSL_KEA_DHE_KEY_SIZE_FULL Here is the key, directly from the source code of Firefox: bits < 512 ? 1 : bits == 512 ? 2 : bits < 768 ? 3 : bits == 768 ? 4 : bits < 1024 ? 5 : bits == 1024 ? 6 : bits < 1280 ? 7 : bits == 1280 ? 8 : bits < 1536 ? 9 : bits == 1536 ? 10 : bits < 2048 ? 11 : bits == 2048 ? 12 : bits < 3072 ? 13 : bits == 3072 ? 14 : bits < 4096 ? 15 : bits == 4096 ? 16 : bits < 8192 ? 17 : bits == 8192 ? 18 : bits < 16384 ? 19 : bits == 16384 ? 20 : 0; _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
