Code review request, 8028518, Increase the priorities of GCM cipher suites

Xuelei Fan Xuelei.Fan at Oracle.COM
Fri Jan 3 19:49:49 PST 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