Code review request, 8028518, Increase the priorities of GCM cipher suites
Xuelei Fan
Xuelei.Fan at Oracle.COM
Sat Jan 4 03:49:49 UTC 2014
On 1/4/2014 11:01 AM, Bernd Eckenfels wrote:
> Hello,
>
> Am 04.01.2014, 03:19 Uhr, schrieb Xuelei Fan <Xuelei.Fan at 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
More information about the security-dev
mailing list