On 1/4/2014 11:01 AM, Bernd Eckenfels wrote:
Hello,
Am 04.01.2014, 03:19 Uhr, schrieb Xuelei Fan <xuelei....@oracle.com>:
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."
Maybe it is best to change the comment, this wording suggest the
_ordering_ is the main difference, if I understood you correctly it is
mostly missing supported ciphersuits? (BTW: how to specify the curve to
use?)
Thanks for the suggestion. Looks like it is really confusing. Let's
parse it from the beginning.
line 964-977 comments:
1. Prefer Suite B compliant cipher suites, see RFC6460 (To be
changed later, see below).
2. Prefer the stronger bulk cipher, in the order of AES_256(GCM),
AES_128(GCM), AES_256, AES_128, RC-4, 3DES-EDE.
Then the cipher suites preference should be ordered as
1. Suite B compliant (Need to change in the future)
2. AES_256(GCM)
3. AES_128(GCM)
4. AES_256
5. AES_128
6. RC-4
7. 3DES-EDE
The actual order is performed as above.
I think the confusing may come from the some AES_256/128(GCM) may be of
Suite B cipher suites. I may change the comment as:
// Suite B compliant cipher suites, see RFC 6460.
//
// Note that, at present this provider is not Suite B compliant. The
// preference order of the GCM cipher suites does not follow the spec
- // of RFC 6460.
+ // of RFC 6460. In this section, only two cipher suites are listed
+ // so that applications can make use of Suite-B compliant cipher
+ // suite firstly.
add("TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
0xc02c, --p, K_ECDHE_ECDSA, B_AES_256_GCM, T, max, tls12, P_SHA384);
add("TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
0xc02b, --p, K_ECDHE_ECDSA, B_AES_128_GCM, T, max, tls12, P_SHA256);
If I see it right you prefer TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as
the only AES128 because it uses the Suit B compliant ECDHE. Maybe a
comment similiar to the existing groupings should make that clear
("//ECDHE AES_xxx(GCM) Suite B")? And in that case (as Bradford pointed
out as well) I think the order is wrong (it is a bit strange that there
is no "high as possible" security level specified as compliant :-/)
See above.
Maybe the non-suite-b ciphers should also be ordered in groups which
prefer ephermal exchanges (and not by symmetric bit length)
I think it's really hard to determine which is more important between
ephermal exchanges and symmetric algorithm. I'm open to discuss more
about a better ordering rule. There are four factors of a cipher
suites, key exchange algorithm, symmetric crypto algorithm and key size,
hash algorithm. What's your preference order if they can be grouped?
More generally asked: is there a analysis done to follow Suit B
recommendation in this specific way? It seems to me the optimisting
relying on ECDSA might need to be at least reconsidered (especially with
standard curces and the need for good random source)
(I guess my comment is geared more towards the order within those cypers
not the moving of the GCM block in general.)
And all those questions combined makes me wonder if it would actually be
a good idea to have a global "compliance" switch, which can take a few
common scenarios (PCI, Suite B LOW, Suite B HI, ...) and configure the
list accordingly. The default can then be more practially oriented.
We might consider it in the future. See also the related session [1] in
JavaOne shanghai, 2013.
Thanks for the comment, Bernd.
Xuelei
[1]:
https://oraclecn.activeevents.com/connect/sessionDetail.ww?SESSION_ID=1389
