On 1/4/2014 10:47 AM, Bradford Wetmore wrote:
On 1/3/2014 6:19 PM, Xuelei Fan wrote:
On 1/4/2014 6:41 AM, Bradford Wetmore wrote:
Looks ok to me, with the exception as you pointed out that this doesn't
follow section 4 of RFC 6460.
Sorry, I did not get it. Would you mind point out the line number of
the concern?
This section in RFC 6460:
A Suite B TLS client configured at a minimum level of security of 128
bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or the
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite in the
ClientHello message. The TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
cipher suite is preferred; if offered, it MUST appear before the
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite.
Understand. Do you note the circumstance of this spec, at the "level of
security of 128 bits"? In the next paragraph, it also talks about "
level of security of 192 bits".
If configured at a minimum level of security of 192 bits, the client
MUST offer the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite
and MUST NOT offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher
suite.
That's also one point I said that the preference are not RFC 6460
compliant at present. We may make improvement in the future.
You have:
993 add("TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
...
995 add("TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
Why was this done, and how did you
originally determine the original ciphersuite ordering for GCMs?
Per RFC 6460, there are two profiles, "Suite B Combination 1" and "Suite
B Combination 2". SunJSSE default cipher suite preference does not
compliant to the profiles at present. That's why it is said,
"The preference order of the GCM cipher suites does not follow the spec
of RFC 6460."
About the ordering, please refer to line 964-977 of CipherSuite.java
My question was, how did you choose the current order (currently lines
1080-1110:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
I think except the above two cipher suites, the order of the following
cipher suites still adhere to the rules described in line 964-977. Right?
Thanks,
Xuelei
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
Brad
Thanks,
Xuelei
Brad
On 12/29/2013 7:56 PM, Xuelei Fan wrote:
Hi,
Please review this small update.
webrev: http://cr.openjdk.java.net/~xuelei/8028518/webrev.00/
In TLS protocols, cipher suite specifies the crypto algorithms used in
TLS connections. The priorities of cipher suites define the preference
order that a cipher suite may be used in a TLS connection.
When introducing the AEAD/GCM cipher suites in SunJSSE provider (JEP
115)[1], for better compatibility and interoperability, we decided to
decrease the priority of cipher suites in GCM mode for a while before
GCM technologies mature in the industry.
It's time to consider to increase the priorities of GCM mode cipher
suite in early stage of JDK 9.
Thanks,
Xuelei
[1] http://openjdk.java.net/jeps/115
