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

Bernd Eckenfels bernd-2014 at eckenfels.net
Fri Jan 3 19:01:45 PST 2014


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?)

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 :-/)

Maybe the non-suite-b ciphers should also be ordered in groups which  
prefer ephermal exchanges (and not by symmetric bit length)

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.

Greetings
Bernd
-- 
http://bernd.eckenfels.net


More information about the security-dev mailing list