hg: jdk8/tl/jdk: 2 new changesets
Changeset: 46c727d6ecc2 Author:aefimov Date: 2013-12-30 16:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46c727d6ecc2 8025051: Update resource files for TimeZone display names Reviewed-by: okutsu, mfang ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/java/util/Calendar/GenericTimeZoneNamesTest.sh ! test/sun/util/resources/TimeZone/Bug6317929.java + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_de.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_de_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_es.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_es_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_fr.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_fr_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_it.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_it_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ja.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ja_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ko.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ko_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_pt_BR.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_pt_BR_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_sv.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_sv_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_CN.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_CN_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_TW.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_TW_short.properties Changeset: c0970860803e Author:coffeys Date: 2014-01-03 16:45 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0970860803e Merge
hg: jdk8/tl/jdk: 8030212: Several api.java.util.stream tests got NaN value instead of Infinity or -Infinity
Changeset: 68de5492a06d Author:darcy Date: 2014-01-03 11:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68de5492a06d 8030212: Several api.java.util.stream tests got NaN value instead of Infinity or -Infinity Reviewed-by: mduigou, psandoz ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DoublePipeline.java ! test/java/util/stream/TestDoubleSumAverage.java
Re: Code review request, 8028518, Increase the priorities of GCM cipher suites
Looks ok to me, with the exception as you pointed out that this doesn't follow section 4 of RFC 6460. Why was this done, and how did you originally determine the original ciphersuite ordering for GCMs? 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
Re: Code review request, 8028518, Increase the priorities of GCM cipher suites
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. 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 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
Re: Code review request, 8028518, Increase the priorities of GCM cipher suites
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
Re: Code review request, 8028518, Increase the priorities of GCM cipher suites
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?) 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
Re: Code review request, 8028518, Increase the priorities of GCM cipher suites
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
