On 11/11/14, 9:10 PM, Brian Smith wrote:
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.
Noted.
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.
You make a good point. I'd be fine with SHOULD NOT for TLS 1.1 but I
would like to know what other WG participants (and my co-authors) think
before changing the document.
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.
I expect that this BCP will be obsoleted by another BCP once TLS 1.3 is
published and implemented and deployed.
But your suggestion is acceptable to me.
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.
Speaking only for myself, I don't think the authors differentiated
between *how* you might get to TLS 1.0 or SSLv3 - only that you end up
there at all.
In any case TLS_FALLBACK_SCSV is probably too new for us to recommend it
as a best *current* practice.
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.
I don't have strong opinions on the time relationship here.
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.
Thanks for pointing out the weaknesses here.
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.
Do I understand correctly that you would recommend the ECDHE ciphers but
not the DHE ciphers? Or would you recommend some other DHE ciphers?
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.
The authors will discuss this amongst themselves to see what we think is
reasonable. Naturally we also look to the WG for feedback!
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.
I don't know if RFC 5246 was *wrong*, but the situation on the ground
has changed since 2008.
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.
We've had another proposal for text on these points, so the authors will
take a closer look.
Brian, thanks for your detailed review.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
