From sean.mullan at oracle.com Mon Apr 3 13:35:24 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 3 Apr 2017 09:35:24 -0400 Subject: RFR 8177291: [doc] weak algorithms and crypto policy in JGSS docs In-Reply-To: <7ad916de-d962-9b02-885f-684d1b223106@oracle.com> References: <7ad916de-d962-9b02-885f-684d1b223106@oracle.com> Message-ID: Hi Max, Just a few comments: "The default jurisdiction policy files bundled in Java SE is now unlimited, which means the AES-256 encryption type is available by default." s/is/are/ "The DES based encryption types (including des-cbc-md5 and des-cbc-crc) are disabled by default." Was this in the 8.0 release? If not, we probably should not list it here because this is for features in the major releases. "In "Goal of this exercise", remove "and DES", "DES-CBC-MD5" and "DES-CBC-CRC". I can't find this sentence in the doc. Also, these algorithms are still supported, just not enabled by default, so we should list them in the supported section. "At the end of this section, add "Note: DES based encryption types are disabed by default." s/disabed/disabled/ "First, you need to update to use the KDC that supports the required Kerberos encryption types, such as latest Solaris or the MIT Kerberos from MIT distribution. If you are using Active Directory on a Windows platform, the latest version also supports RC4-HMAC and AES encryption types." s/to use the KDC/the KDC/ s/such as latest Solaris or the MIT Kerberos from MIT distribution./such as the latest version of Solaris or the latest version of Kerberos from the MIT distribution./ --Sean On 3/20/17 10:01 PM, Weijun Wang wrote: > This is not exactly a code review, I'd like you to review my suggested > changes on the JGSS guides in > > https://bugs.openjdk.java.net/browse/JDK-8177291 > > If everything is OK, I can pass it to the doc writer. > > Thanks > Max From weijun.wang at oracle.com Mon Apr 3 14:44:15 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 3 Apr 2017 22:44:15 +0800 Subject: RFR 8177291: [doc] weak algorithms and crypto policy in JGSS docs In-Reply-To: References: <7ad916de-d962-9b02-885f-684d1b223106@oracle.com> Message-ID: On 04/03/2017 09:35 PM, Sean Mullan wrote: > Hi Max, > > Just a few comments: > > "The DES based encryption types (including des-cbc-md5 and des-cbc-crc) > are disabled by default." > > Was this in the 8.0 release? Yes. https://bugs.openjdk.java.net/browse/JDK-8012679. > > "First, you need to update to use the KDC that supports the required > Kerberos encryption types, such as latest Solaris or the MIT Kerberos > from MIT distribution. If you are using Active Directory on a Windows > platform, the latest version also supports RC4-HMAC and AES encryption > types." > > s/to use the KDC/the KDC/ "update the KDC that supports"? This sounds strange to me. Shall I use "update the KDC to support" or "update to a KDC that supports"? Thanks Max From weijun.wang at oracle.com Mon Apr 3 15:30:34 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 3 Apr 2017 23:30:34 +0800 Subject: [9] RFR 8177969: Faster FilePermission::implies by avoiding the use of Path::relativize Message-ID: <4f1e0c02-a11d-2694-84ad-cf8804021f3c@oracle.com> http://cr.openjdk.java.net/~weijun/8177969/webrev.00/ This new implementation of containsPath(Path,Path) uses the logic of Path::relativize without directly calling it, which is much faster now. Thanks Max From sean.mullan at oracle.com Mon Apr 3 15:50:03 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 3 Apr 2017 11:50:03 -0400 Subject: RFR: 3 security-libs release notes on keytool/krb5/etc In-Reply-To: References: <5d8c3f85-35f8-2078-775a-d967697dd72b@oracle.com> Message-ID: On 3/29/17 10:33 AM, Sean Mullan wrote: > https://bugs.openjdk.java.net/browse/JDK-8176087 > keytool now prints warnings when reading or generating cert/cert req > using weak algorithms > >> In all keytool functions, if the certificate/certificate request/CRL >> that is working on (whether it be the input, the output, or an >> existing object) is using a weak algorithm or key, a warning will be >> printed out. "working on" sounds a bit awkward. Also not sure it you need to mention all functions, and input, output, etc - I think that should be implied. You probably also want to mention the fix in https://bugs.openjdk.java.net/browse/JDK-8177569 here. How about: "With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing or verifying is using a weak algorithm or key. When the `-trustcacerts` option is specified or the `cacerts` keystore is being directly operated on, keytool will not print a warning for certificates in the `cacerts` keystore that have been signed with a weak signature algorithm." >> Precisely, an algorithm or a key is weak if it matches the value of >> the jdk.certpath.disabledAlgorithms security property defined in >> conf/security/java.security. Put the property name and file name in single backquotes, ex: `jdk.certpath.disabledAlgorithms`. Also I would say "in the `conf/security/java.security` file." --Sean From sean.mullan at oracle.com Tue Apr 4 14:54:20 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 4 Apr 2017 10:54:20 -0400 Subject: RFR 8177291: [doc] weak algorithms and crypto policy in JGSS docs In-Reply-To: References: <7ad916de-d962-9b02-885f-684d1b223106@oracle.com> Message-ID: On 4/3/17 10:44 AM, Weijun Wang wrote: >> "First, you need to update to use the KDC that supports the required >> Kerberos encryption types, such as latest Solaris or the MIT Kerberos >> from MIT distribution. If you are using Active Directory on a Windows >> platform, the latest version also supports RC4-HMAC and AES encryption >> types." >> >> s/to use the KDC/the KDC/ > > "update the KDC that supports"? This sounds strange to me. Shall I use > "update the KDC to support" or "update to a KDC that supports"? Or maybe just "use a KDC that supports". --Sean From anthony.scarpino at oracle.com Tue Apr 4 21:17:32 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 4 Apr 2017 14:17:32 -0700 Subject: RFR[9] 8165367: Additional tests for JEP 288: Disable SHA-1 Certificates In-Reply-To: <5181269b-89b0-08c6-9e50-8a5181eb6fb7@oracle.com> References: <5181269b-89b0-08c6-9e50-8a5181eb6fb7@oracle.com> Message-ID: <8d270035-94c1-d5b0-58c3-16e8489cc7fc@oracle.com> On 03/30/2017 07:41 AM, John Jiang wrote: > Hi, > This patch includes a set of new test cases for JEP 288. > The cases just focus on the usage constraints TLSSever and TLSClient > with TLS communication. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8165367 > Webrev: http://cr.openjdk.java.net/~jjiang/8165367/webrev.00 > > Best regards, > John Jiang > This looks fine. Tony From sean.mullan at oracle.com Thu Apr 6 16:46:15 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 6 Apr 2017 12:46:15 -0400 Subject: [10] RFR: 8161973: PKIXRevocationChecker.getSoftFailExceptions() not working Message-ID: Please review this fix to the getSoftFailExceptions method of PKIXRevocationChecker so that it does not always return an empty List. The problem was that the clone method of the PKIXRevocationChecker implementation was creating a new List each time it was called, and the Exceptions were not being added to the original List that is returned by getSoftFailException. The fix is to not override clone and make a copy of the List. This is still safe because the caller cannot modify its contents (the List returned by getSoftFailExceptions is unmodifiable). http://cr.openjdk.java.net/~mullan/webrevs/8161973/webrev.00/ --Sean From xuelei.fan at oracle.com Thu Apr 6 17:23:50 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 6 Apr 2017 10:23:50 -0700 Subject: [10] RFR: 8161973: PKIXRevocationChecker.getSoftFailExceptions() not working In-Reply-To: References: Message-ID: <8a1c871c-5022-54eb-7fcc-b55cc0ac02b2@oracle.com> Looks fine to me. Xuelei On 4/6/2017 9:46 AM, Sean Mullan wrote: > Please review this fix to the getSoftFailExceptions method of > PKIXRevocationChecker so that it does not always return an empty List. > The problem was that the clone method of the PKIXRevocationChecker > implementation was creating a new List each time it was called, and the > Exceptions were not being added to the original List that is returned by > getSoftFailException. The fix is to not override clone and make a copy > of the List. This is still safe because the caller cannot modify its > contents (the List returned by getSoftFailExceptions is unmodifiable). > > http://cr.openjdk.java.net/~mullan/webrevs/8161973/webrev.00/ > > --Sean From anthony.scarpino at oracle.com Thu Apr 6 20:39:26 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 6 Apr 2017 13:39:26 -0700 Subject: RFR 8177784 Use CounterMode intrinsic for AES/GCM Message-ID: I'd like to get a review for this performance change to use the existing CounterMode parallelized intrinsic instead of GCTR's own version. The two classes were nearly identical except for the doFinal() method which doesn't belong in CounterMode.java. I could have been more aggressive with this change, but I'm looking to get this into 9, so I stayed away from completely merging GCTR into CounterMode in case of incompatibilities. All tests security and hotspot tests pass. http://cr.openjdk.java.net/~ascarpino/8177784/webrev/ thanks Tony From chris.hegarty at oracle.com Fri Apr 7 13:58:36 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 7 Apr 2017 14:58:36 +0100 Subject: RFR 8177784 Use CounterMode intrinsic for AES/GCM In-Reply-To: References: Message-ID: <1e2e7497-c8f2-5e11-5123-aa0503a012ab@oracle.com> On 06/04/17 21:39, Anthony Scarpino wrote: > > I'd like to get a review for this performance change to use the existing > CounterMode parallelized intrinsic instead of GCTR's own version. The > two classes were nearly identical except for the doFinal() method which > doesn't belong in CounterMode.java. > > I could have been more aggressive with this change, but I'm looking to > get this into 9, so I stayed away from completely merging GCTR into > CounterMode in case of incompatibilities. All tests security and > hotspot tests pass. > > http://cr.openjdk.java.net/~ascarpino/8177784/webrev/ This change looks good to me. Trivially, the class-level comment in GCTR should be updated ( it refers to removed fields ). Also, CounterMode.counter could be protected ( rather than package-private ). -Chris. From anthony.scarpino at oracle.com Fri Apr 7 19:47:34 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 7 Apr 2017 12:47:34 -0700 Subject: RFR 8177784 Use CounterMode intrinsic for AES/GCM In-Reply-To: <1e2e7497-c8f2-5e11-5123-aa0503a012ab@oracle.com> References: <1e2e7497-c8f2-5e11-5123-aa0503a012ab@oracle.com> Message-ID: <8413b44e-539d-759c-e7f6-0eb57868a4b6@oracle.com> On 04/07/2017 06:58 AM, Chris Hegarty wrote: > On 06/04/17 21:39, Anthony Scarpino wrote: >> >> I'd like to get a review for this performance change to use the existing >> CounterMode parallelized intrinsic instead of GCTR's own version. The >> two classes were nearly identical except for the doFinal() method which >> doesn't belong in CounterMode.java. >> >> I could have been more aggressive with this change, but I'm looking to >> get this into 9, so I stayed away from completely merging GCTR into >> CounterMode in case of incompatibilities. All tests security and >> hotspot tests pass. >> >> http://cr.openjdk.java.net/~ascarpino/8177784/webrev/ > > This change looks good to me. Trivially, the class-level comment in > GCTR should be updated ( it refers to removed fields ). Also, > CounterMode.counter could be protected ( rather than package-private ). > > -Chris. Thanks Chris, I left CounterMode.counter as package-private because the package is what becomes the SunJCE provider. I don't believe there should be any outside package classes accessing this code. I updated the webrev at with the comment update: http://cr.openjdk.java.net/~ascarpino/8177784/webrev.01/ Tony From Sunny.Chan at gs.com Mon Apr 10 04:46:04 2017 From: Sunny.Chan at gs.com (Chan, Sunny) Date: Mon, 10 Apr 2017 04:46:04 +0000 Subject: JGSS-API supporting SSPI on Windows Message-ID: Hello, Windows has changed the default such that the session key is not included in TGT, and for Windows SSO to work with Java implementation out of the box it will required AllowTGTSessionKey options to be added to the registry. However, this options has associated security risk as it expose the session key to all apps, and it also means that right now Kerberos SSO in Windows does not work out of the box Looking at the Java bug database, there has been suggestion that Java could support SSPI as a JGSS-API provided which would allow Java to work out of the box without the AllowTGTSessionKey options. (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6722928). However, in the evaluation it says: Might support it, although I hope most of the functions of Windows SSPI can also be supported by pure Java. Interop is important between different platforms I would like to understand what is the "Interop" concern here? Have we evaluated how much work need to do to support it (so that we can consider contributing the implementation)? Sunny Chan Executive Director Technology Goldman Sachs (Asia) L.L.C. | 39th Floor | The Center | 99 Queens Road Central | Hong Kong Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 Learn more about Goldman Sachs GS.com | Blog | LinkedIn | YouTube | Twitter This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks inherent in electronic communication. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasadarao.koppula at oracle.com Mon Apr 10 06:02:14 2017 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Sun, 9 Apr 2017 23:02:14 -0700 (PDT) Subject: RFR[8u] JDK-8157035: Use stronger algorithms and keys for JSSE testing In-Reply-To: <6d8ceb06-fd32-4bb3-bfdd-aa510b6b4eca@default> References: <6d8ceb06-fd32-4bb3-bfdd-aa510b6b4eca@default> Message-ID: Hi, Please review this patch for "JDK-8157035: Use stronger algorithms and keys for JSSE testing" Issue: https://bugs.openjdk.java.net/browse/JDK-8157035 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ecoffeys/webrev.8157035.jdk8u/"http://cr.openjdk.java.net/~coffeys/webrev.8157035.jdk8u/ Changes: sun/security/ssl/etc/truststore and truststore are having old certs with weaker algorithms. Due to this, in some of the tests, "jdk.certpath.disabledAlgorithms" property is hardcoded with empty string(""). It's not direct backport. Following changes are made in addition to JDK9 changes. - Removed hardcoded value for jdk.certpath.disabledAlgorithms property in bellow test files. o test/javax/net/ssl/ciphersuites/DisabledAlgorithms.java o test/sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java Thanks, Prasad.K -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Apr 10 08:05:24 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 10 Apr 2017 16:05:24 +0800 Subject: JGSS-API supporting SSPI on Windows In-Reply-To: References: Message-ID: <5e828e31-7961-1a66-4517-71ae70535b88@oracle.com> Hi Sunny If I understand correctly, the major difference between SSPI and GSS-API is delegation. In GSS-API, the client initiates the delegation by forwarding a credential to the intermediate server so the latter can use this delegated credential to access a backend server on behalf of the client. In SSPI, the intermediate server itself asks the KDC (Active Directory Domain Server) whether it can impersonate a client to access the backend server. Microsoft calls it constrained delegation. Java supports both traditional delegation and constrained delegation, but if we add SSPI as a JGSS-API provider, it can only support constrained delegation. Implementing SSPI requires quite a lot of coding, including both Java and C codes. There will also be quite some testing work. A partial solution is to only support Windows' native service ticket retrieval. This means we can bypass the TGT (where AllowTGTSessionKey is needed) and acquire a service ticket directly. After this ticket is available, we still use the current Java codes to access the service. This solution also won't support traditional delegation. There is no decision yet. Any contribution is welcomed. Thanks Weijun On 04/10/2017 12:46 PM, Chan, Sunny wrote: > Hello, > > Windows has changed the default such that the session key is not > included in TGT, and for Windows SSO to work with Java implementation > out of the box it will required AllowTGTSessionKey options to be added > to the registry. However, this options has associated security risk as > it expose the session key to all apps, and it also means that right now > Kerberos SSO in Windows does not work out of the box > > Looking at the Java bug database, there has been suggestion that Java > could support SSPI as a JGSS-API provided which would allow Java to work > out of the box without the AllowTGTSessionKey options. > (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6722928). However, > in the evaluation it says: > > Might support it, although I hope most of the functions of Windows SSPI > can also be supported by pure Java. Interop is important between > different platforms > > I would like to understand what is the ?Interop? concern here? Have we > evaluated how much work need to do to support it (so that we can > consider contributing the implementation)? > > *Sunny Chan* > Executive Director > Technology > > *Goldman Sachs (Asia) L.L.C.*| 39th Floor | The Center | 99 Queens Road > Central | Hong Kong > > Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 From Sunny.Chan at gs.com Mon Apr 10 09:03:06 2017 From: Sunny.Chan at gs.com (Chan, Sunny) Date: Mon, 10 Apr 2017 09:03:06 +0000 Subject: JGSS-API supporting SSPI on Windows In-Reply-To: <5e828e31-7961-1a66-4517-71ae70535b88@oracle.com> References: <5e828e31-7961-1a66-4517-71ae70535b88@oracle.com> Message-ID: <3210263a4f974a3fb903ed60203ca55b@gsdghkp03etn1.firmwide.corp.gs.com> So just to clarify my understanding, this situation is similar to how Swing and AWT related to each other - Traditional Delegation for GSS-API is that most processing is done in Java code, so it will need access to Session Key in order to decrypt the ticket directly and communicate with the Kerberos server. While Microsoft's Constrained delegation is like AWT where all the authentication operations are delegated to Windows and JGSS is merely a wrapper to those API? Let's assume if we implement a Constrained Delegation client just for Windows and only turned on via a security property, would that be acceptable solution? -----Original Message----- From: Weijun Wang [mailto:weijun.wang at oracle.com] Sent: 10 April 2017 16:05 To: Chan, Sunny [Tech]; 'security-dev at openjdk.java.net' Subject: Re: JGSS-API supporting SSPI on Windows Hi Sunny If I understand correctly, the major difference between SSPI and GSS-API is delegation. In GSS-API, the client initiates the delegation by forwarding a credential to the intermediate server so the latter can use this delegated credential to access a backend server on behalf of the client. In SSPI, the intermediate server itself asks the KDC (Active Directory Domain Server) whether it can impersonate a client to access the backend server. Microsoft calls it constrained delegation. Java supports both traditional delegation and constrained delegation, but if we add SSPI as a JGSS-API provider, it can only support constrained delegation. Implementing SSPI requires quite a lot of coding, including both Java and C codes. There will also be quite some testing work. A partial solution is to only support Windows' native service ticket retrieval. This means we can bypass the TGT (where AllowTGTSessionKey is needed) and acquire a service ticket directly. After this ticket is available, we still use the current Java codes to access the service. This solution also won't support traditional delegation. There is no decision yet. Any contribution is welcomed. Thanks Weijun On 04/10/2017 12:46 PM, Chan, Sunny wrote: > Hello, > > Windows has changed the default such that the session key is not > included in TGT, and for Windows SSO to work with Java implementation > out of the box it will required AllowTGTSessionKey options to be added > to the registry. However, this options has associated security risk as > it expose the session key to all apps, and it also means that right > now Kerberos SSO in Windows does not work out of the box > > Looking at the Java bug database, there has been suggestion that Java > could support SSPI as a JGSS-API provided which would allow Java to > work out of the box without the AllowTGTSessionKey options. > (https://urldefense.proofpoint.com/v2/url?u=http-3A__bugs.java.com_bug > database_view-5Fbug.do-3Fbug-5Fid-3D6722928&d=DgID-g&c=7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLxfZlX4&r=e-nMYEAYoRWWms8SM-H97SgyQYsz-xaiLmQPYwZ3m5E&m=tVm1uVTgadiBY_OTgDIvULQDi4i4YBQTTE8cwwJhW9M&s=U0di20MO97JRZDulQs-1MtqrEE4yo9nygL-WvEBkZjM&e= ). However, in the evaluation it says: > > Might support it, although I hope most of the functions of Windows > SSPI can also be supported by pure Java. Interop is important between > different platforms > > I would like to understand what is the "Interop" concern here? Have we > evaluated how much work need to do to support it (so that we can > consider contributing the implementation)? > > *Sunny Chan* > Executive Director > Technology > > *Goldman Sachs (Asia) L.L.C.*| 39th Floor | The Center | 99 Queens > Road Central | Hong Kong > > Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 From weijun.wang at oracle.com Mon Apr 10 09:27:29 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 10 Apr 2017 17:27:29 +0800 Subject: JGSS-API supporting SSPI on Windows In-Reply-To: <3210263a4f974a3fb903ed60203ca55b@gsdghkp03etn1.firmwide.corp.gs.com> References: <5e828e31-7961-1a66-4517-71ae70535b88@oracle.com> <3210263a4f974a3fb903ed60203ca55b@gsdghkp03etn1.firmwide.corp.gs.com> Message-ID: <7bce38fb-e06c-1663-d884-a201dbae3202@oracle.com> On 04/10/2017 05:03 PM, Chan, Sunny wrote: > So just to clarify my understanding, this situation is similar to how > Swing and AWT related to each other - Traditional Delegation for > GSS-API is that most processing is done in Java code, so it will need > access to Session Key in order to decrypt the ticket directly and > communicate with the Kerberos server. While Microsoft's Constrained > delegation is like AWT where all the authentication operations are > delegated to Windows and JGSS is merely a wrapper to those API? Swing and AWT are all Java SE APIs. Java SE has only GSS-API. SSPI is a Windows native Win32 API. What I said implementing SSPI is not precise, it's actually creating another GSS-API provider that calls SSPI functions on Windows. You can imagine this as a bridge or a wrapper. > > Let's assume if we implement a Constrained Delegation client just for > Windows and only turned on via a security property, would that be > acceptable solution? It's implementing a SSPI wrapper just for Windows, and yes it can be turned on via a system property. But as I said, the 2 APIs do not have an exact 1-1 mapping (on delegation). One might say the new provider and the old one support different feature sets. --Weijun > > -----Original Message----- From: Weijun Wang > [mailto:weijun.wang at oracle.com] Sent: 10 April 2017 16:05 To: Chan, > Sunny [Tech]; 'security-dev at openjdk.java.net' Subject: Re: JGSS-API > supporting SSPI on Windows > > Hi Sunny > > If I understand correctly, the major difference between SSPI and > GSS-API is delegation. In GSS-API, the client initiates the > delegation by forwarding a credential to the intermediate server so > the latter can use this delegated credential to access a backend > server on behalf of the client. In SSPI, the intermediate server > itself asks the KDC (Active Directory Domain Server) whether it can > impersonate a client to access the backend server. Microsoft calls it > constrained delegation. > > Java supports both traditional delegation and constrained delegation, > but if we add SSPI as a JGSS-API provider, it can only support > constrained delegation. > > Implementing SSPI requires quite a lot of coding, including both Java > and C codes. There will also be quite some testing work. > > A partial solution is to only support Windows' native service ticket > retrieval. This means we can bypass the TGT (where AllowTGTSessionKey > is needed) and acquire a service ticket directly. After this ticket > is available, we still use the current Java codes to access the > service. This solution also won't support traditional delegation. > > There is no decision yet. > > Any contribution is welcomed. > > Thanks Weijun > > On 04/10/2017 12:46 PM, Chan, Sunny wrote: >> Hello, >> >> Windows has changed the default such that the session key is not >> included in TGT, and for Windows SSO to work with Java >> implementation out of the box it will required AllowTGTSessionKey >> options to be added to the registry. However, this options has >> associated security risk as it expose the session key to all apps, >> and it also means that right now Kerberos SSO in Windows does not >> work out of the box >> >> Looking at the Java bug database, there has been suggestion that >> Java could support SSPI as a JGSS-API provided which would allow >> Java to work out of the box without the AllowTGTSessionKey >> options. >> (https://urldefense.proofpoint.com/v2/url?u=http-3A__bugs.java.com_bug >> >> database_view-5Fbug.do-3Fbug-5Fid-3D6722928&d=DgID-g&c=7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLxfZlX4&r=e-nMYEAYoRWWms8SM-H97SgyQYsz-xaiLmQPYwZ3m5E&m=tVm1uVTgadiBY_OTgDIvULQDi4i4YBQTTE8cwwJhW9M&s=U0di20MO97JRZDulQs-1MtqrEE4yo9nygL-WvEBkZjM&e= ). However, in the evaluation it says: >> >> Might support it, although I hope most of the functions of Windows >> SSPI can also be supported by pure Java. Interop is important >> between different platforms >> >> I would like to understand what is the "Interop" concern here? Have >> we evaluated how much work need to do to support it (so that we can >> consider contributing the implementation)? >> >> *Sunny Chan* Executive Director Technology >> >> *Goldman Sachs (Asia) L.L.C.*| 39th Floor | The Center | 99 Queens >> Road Central | Hong Kong >> >> Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 >> 0633 From sean.coffey at oracle.com Mon Apr 10 13:11:33 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 10 Apr 2017 14:11:33 +0100 Subject: RFR[8u] JDK-8157035: Use stronger algorithms and keys for JSSE testing In-Reply-To: References: <6d8ceb06-fd32-4bb3-bfdd-aa510b6b4eca@default> Message-ID: <3c4a1a22-4ba0-abd1-f988-8df8ab6bad5d@oracle.com> Looks good to me Prasad. Thanks for fixing this. Regards, Sean. On 10/04/17 07:02, Prasadrao Koppula wrote: > > Hi, > > Please review this patch for ?JDK-8157035: Use stronger algorithms and > keys for JSSE testing? > > Issue: > > https://bugs.openjdk.java.net/browse/JDK-8157035 > > Webrev: > > http://cr.openjdk.java.net/~coffeys/webrev.8157035.jdk8u/ > > > Changes: > > sun/security/ssl/etc/truststore and truststore are having old certs > with weaker algorithms. Due to this, in some of the tests, > ?jdk.certpath.disabledAlgorithms? property is hardcoded with empty > string(??). > > It?s not direct backport. Following changes are made in addition to > JDK9 changes. > > -Removed hardcoded value for jdk.certpath.disabledAlgorithms property > in bellow test files. > > otest/javax/net/ssl/ciphersuites/DisabledAlgorithms.java > > otest/sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java > > Thanks, > > Prasad.K > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Mon Apr 10 17:27:02 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 10 Apr 2017 10:27:02 -0700 Subject: RFR 8177784 Use CounterMode intrinsic for AES/GCM In-Reply-To: <8413b44e-539d-759c-e7f6-0eb57868a4b6@oracle.com> References: <1e2e7497-c8f2-5e11-5123-aa0503a012ab@oracle.com> <8413b44e-539d-759c-e7f6-0eb57868a4b6@oracle.com> Message-ID: > On 7 Apr 2017, at 12:47, Anthony Scarpino wrote: > > On 04/07/2017 06:58 AM, Chris Hegarty wrote: >> On 06/04/17 21:39, Anthony Scarpino wrote: >>> >>> I'd like to get a review for this performance change to use the existing >>> CounterMode parallelized intrinsic instead of GCTR's own version. The >>> two classes were nearly identical except for the doFinal() method which >>> doesn't belong in CounterMode.java. >>> >>> I could have been more aggressive with this change, but I'm looking to >>> get this into 9, so I stayed away from completely merging GCTR into >>> CounterMode in case of incompatibilities. All tests security and >>> hotspot tests pass. >>> >>> http://cr.openjdk.java.net/~ascarpino/8177784/webrev/ >> >> This change looks good to me. Trivially, the class-level comment in >> GCTR should be updated ( it refers to removed fields ). Also, >> CounterMode.counter could be protected ( rather than package-private ). >> >> -Chris. > > Thanks Chris, > > I left CounterMode.counter as package-private because the package is what becomes the SunJCE provider. I don't believe there should be any outside package classes accessing this code. > > I updated the webrev at with the comment update: > http://cr.openjdk.java.net/~ascarpino/8177784/webrev.01/ > It?s the same pattern for ?iv? with CounterMode and FeedbackCipher, although i prefer protected as well if never accessed by other classes in the same package, it makes it easier to reason about the code, since i know more about what can access it. Suggestion, take it or leave it: personally i would prefer to see an additional constructor in CounterMode: GCTR(SymmetricCipher cipher, byte[] initialCounterBlk) { super(cipher, checkBlockSize(initialCounterBlk)); } Where new CounterMode constructor performs the clone, assignmentm and reset, the static method checkBlockSize checks the array length is equal to AES_BLOCK_SIZE Thereby you have a cleaner separation of concerns. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sean.mullan at oracle.com Mon Apr 10 19:18:34 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 10 Apr 2017 15:18:34 -0400 Subject: RFR 8177784 Use CounterMode intrinsic for AES/GCM In-Reply-To: References: Message-ID: On 4/6/17 4:39 PM, Anthony Scarpino wrote: > > I'd like to get a review for this performance change to use the existing > CounterMode parallelized intrinsic instead of GCTR's own version. The > two classes were nearly identical except for the doFinal() method which > doesn't belong in CounterMode.java. > > I could have been more aggressive with this change, but I'm looking to > get this into 9, so I stayed away from completely merging GCTR into > CounterMode in case of incompatibilities. If there is some additional followon work or additional performance improvement that you think should be done, please file that as a separate issue. > All tests security and > hotspot tests pass. > > http://cr.openjdk.java.net/~ascarpino/8177784/webrev/ GCTR.java: I had one question about the clone on line 62 -- it did not seem necessary as the array was subsequently copied in the reset method and I don't think the iv is needed again. Also a nit on line 66, add @Override to getFeedback(). Also, not part of your change but the doFinal method does not need to be protected - package-private is fine/better. Otherwise, it looks good to me. --Sean From sean.mullan at oracle.com Mon Apr 10 19:30:20 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 10 Apr 2017 15:30:20 -0400 Subject: RFR 8177784 Use CounterMode intrinsic for AES/GCM In-Reply-To: <8413b44e-539d-759c-e7f6-0eb57868a4b6@oracle.com> References: <1e2e7497-c8f2-5e11-5123-aa0503a012ab@oracle.com> <8413b44e-539d-759c-e7f6-0eb57868a4b6@oracle.com> Message-ID: <432b7e89-09fb-7f3f-9af2-f41addf76002@oracle.com> On 4/7/17 3:47 PM, Anthony Scarpino wrote: > On 04/07/2017 06:58 AM, Chris Hegarty wrote: >> On 06/04/17 21:39, Anthony Scarpino wrote: >>> >>> I'd like to get a review for this performance change to use the existing >>> CounterMode parallelized intrinsic instead of GCTR's own version. The >>> two classes were nearly identical except for the doFinal() method which >>> doesn't belong in CounterMode.java. >>> >>> I could have been more aggressive with this change, but I'm looking to >>> get this into 9, so I stayed away from completely merging GCTR into >>> CounterMode in case of incompatibilities. All tests security and >>> hotspot tests pass. >>> >>> http://cr.openjdk.java.net/~ascarpino/8177784/webrev/ >> >> This change looks good to me. Trivially, the class-level comment in >> GCTR should be updated ( it refers to removed fields ). Also, >> CounterMode.counter could be protected ( rather than package-private ). >> >> -Chris. > > Thanks Chris, > > I left CounterMode.counter as package-private because the package is > what becomes the SunJCE provider. I don't believe there should be any > outside package classes accessing this code. I agree it is better to keep it package-private since the field is not intended to be ever accessed outside the package, and keeping it package-private is in general a better practice for writing secure code. See also Guideline 4-1 of Java Secure Coding Guidelines: http://www.oracle.com/technetwork/java/seccodeguide-139067.html#4 --Sean From anthony.scarpino at oracle.com Tue Apr 11 17:58:26 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 11 Apr 2017 10:58:26 -0700 Subject: RFR 8177784 Use CounterMode intrinsic for AES/GCM In-Reply-To: References: <1e2e7497-c8f2-5e11-5123-aa0503a012ab@oracle.com> <8413b44e-539d-759c-e7f6-0eb57868a4b6@oracle.com> Message-ID: <17fe841c-f3e6-1571-ecb6-c0f29fdbcbe4@oracle.com> On 04/10/2017 10:27 AM, Paul Sandoz wrote: > >> On 7 Apr 2017, at 12:47, Anthony Scarpino wrote: >> >> On 04/07/2017 06:58 AM, Chris Hegarty wrote: >>> On 06/04/17 21:39, Anthony Scarpino wrote: >>>> >>>> I'd like to get a review for this performance change to use the existing >>>> CounterMode parallelized intrinsic instead of GCTR's own version. The >>>> two classes were nearly identical except for the doFinal() method which >>>> doesn't belong in CounterMode.java. >>>> >>>> I could have been more aggressive with this change, but I'm looking to >>>> get this into 9, so I stayed away from completely merging GCTR into >>>> CounterMode in case of incompatibilities. All tests security and >>>> hotspot tests pass. >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8177784/webrev/ >>> >>> This change looks good to me. Trivially, the class-level comment in >>> GCTR should be updated ( it refers to removed fields ). Also, >>> CounterMode.counter could be protected ( rather than package-private ). >>> >>> -Chris. >> >> Thanks Chris, >> >> I left CounterMode.counter as package-private because the package is what becomes the SunJCE provider. I don't believe there should be any outside package classes accessing this code. >> >> I updated the webrev at with the comment update: >> http://cr.openjdk.java.net/~ascarpino/8177784/webrev.01/ >> > > It?s the same pattern for ?iv? with CounterMode and FeedbackCipher, although i prefer protected as well if never accessed by other classes in the same package, it makes it easier to reason about the code, since i know more about what can access it. > > Suggestion, take it or leave it: personally i would prefer to see an additional constructor in CounterMode: > > GCTR(SymmetricCipher cipher, byte[] initialCounterBlk) { > super(cipher, checkBlockSize(initialCounterBlk)); > } > > Where new CounterMode constructor performs the clone, assignmentm and reset, the static method checkBlockSize checks the array length is equal to AES_BLOCK_SIZE Thereby you have a cleaner separation of concerns. > > Paul. > I contemplated putting changing the constructors, but went against it for the moment so a jdk9 change would be as minimal as possible. A future change would most likely include the new constructor in CounterMode. Tony From anthony.scarpino at oracle.com Tue Apr 11 18:23:08 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 11 Apr 2017 11:23:08 -0700 Subject: RFR 8177784 Use CounterMode intrinsic for AES/GCM In-Reply-To: References: Message-ID: <6918d276-1a5f-fc86-149b-bbc72a25effe@oracle.com> On 04/10/2017 12:18 PM, Sean Mullan wrote: > On 4/6/17 4:39 PM, Anthony Scarpino wrote: >> >> I'd like to get a review for this performance change to use the existing >> CounterMode parallelized intrinsic instead of GCTR's own version. The >> two classes were nearly identical except for the doFinal() method which >> doesn't belong in CounterMode.java. >> >> I could have been more aggressive with this change, but I'm looking to >> get this into 9, so I stayed away from completely merging GCTR into >> CounterMode in case of incompatibilities. > > If there is some additional followon work or additional performance > improvement that you think should be done, please file that as a > separate issue. > >> All tests security and >> hotspot tests pass. >> >> http://cr.openjdk.java.net/~ascarpino/8177784/webrev/ > > GCTR.java: > > I had one question about the clone on line 62 -- it did not seem > necessary as the array was subsequently copied in the reset method and I > don't think the iv is needed again. I did that to minimize risk, but you're probably right. The caller methods are never going to change the iv, and reset copies it, so there is no risk. > Also a nit on line 66, add @Override > to getFeedback(). Also, not part of your change but the doFinal method > does not need to be protected - package-private is fine/better. Sure http://cr.openjdk.java.net/~ascarpino/8177784/webrev.02/ > > Otherwise, it looks good to me. > > --Sean From sean.mullan at oracle.com Tue Apr 11 19:48:35 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Apr 2017 15:48:35 -0400 Subject: RFR 8177784 Use CounterMode intrinsic for AES/GCM In-Reply-To: <6918d276-1a5f-fc86-149b-bbc72a25effe@oracle.com> References: <6918d276-1a5f-fc86-149b-bbc72a25effe@oracle.com> Message-ID: > http://cr.openjdk.java.net/~ascarpino/8177784/webrev.02/ Looks good. --Sean From weijun.wang at oracle.com Wed Apr 12 15:52:15 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 12 Apr 2017 23:52:15 +0800 Subject: [10] RFR 8166222: Don't treat signed jars with invalid timestamps as unsigned Message-ID: <99291a07-a462-50f0-5b62-7e6907b081f5@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8166222/webrev.00/ The major code change is inside SignatureFileVerifier.java. Now if the timestamp on a signed jar is invalid (For example, using a weak algorithm now disabled), the jar file will be treated as a signed jar without a timestamp. Before this change, it was treated unsigned. In jarsigner/Main.java, I also add a line to validate the TSA cert chain. If not validated, a warning will be shown which is similar to the one when signer cert chain is not validated. If -strict is on, exit code will change too. I also make a small change at http://cr.openjdk.java.net/~weijun/8166222/root/webrev.00/ The executeCommand() method shows more info (mainly stdout and stderr outputs) than executeProcess(). Because of the behavior change and new warnings, this change will need a Compatibility and Specification Review (CSR). At the moment, please review the code change first. Thanks Max From xuelei.fan at oracle.com Thu Apr 13 18:15:04 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 13 Apr 2017 11:15:04 -0700 Subject: Code Review Request, JDK-8140436, Support the FFDHE TLS extension Message-ID: <7c39a09f-4b78-fa57-1e81-c5ce3a6e72ab@oracle.com> Hi, Please review the enhancement to support Finite Field Diffie-Hellman Ephemeral (FFDHE) Parameters negotiation in SSL/TLS/DTLS implementation. http://cr.openjdk.java.net/~xuelei/8140436/webrev.00/ Updates: 1. Support predefined FFDHE parameters. JDK will support the following FFDHE parameters defined in RFC 7919, in preference order: name | key size (bits) ---------------+------------------- ffdhe2048 | 2048 ---------------+------------------- ffdhe3072 | 3072 ---------------+------------------- ffdhe4096 | 4096 ---------------+------------------- ffdhe6144 | 6144 ---------------+------------------- ffdhe8192 | 8192 ---------------+------------------- 2. Define a new System Property so as to disable the FFDHE mechanism For RFC 7919 compatible client, the predefined FFDHE parameter names are present in the "supported_groups" TLS extension. Some server may not be able to handle this extension or the FFDHE groups in the extension. If there is an interop issue, the new defined System Property, "jsse.enableFFDHE", can be used to dismiss the predefined FFDHE parameters for DHE cipher suites. 3. Redefine the jdk.tls.ephemeralDHKeySize System Property. For connection request from RFC 7919 compatible clients, the server would prefer to use FFDHE mechanism at first unless "jdk.tls.ephemeralDHKeySize" is defined to use "legacy" mode for compatibility reason. jdk.tls.ephemeralDHKeySize | FFDHE | Server behavior ---------------------------+----------------------+---------------------- "legacy" | in any case | Use legacy mode. ---------------------------+----------------------+---------------------- not "legacy" | Not present in the | Use DHE parameters | ClientHello message | compatible to the | | System Property. ---------------------------+----------------------+---------------------- not "legacy" | Present in the | Use the FFDHE | ClientHello message | defined parameters. Note: Exportable cipher suites do not use the FFDHE mechanism. 4. Extend the "jdk.tls.namedGroups" System Property Extend the "jdk.tls.namedGroups" System Property to support customized FFDHE groups. The following names are now supported by the System Property. Names for named group | For EC or DH | Is it new in the update? ------------------------+---------------+------------------------- secp256r1 | ECDHE | No ------------------------+---------------+------------------------- secp384r1 | ECDHE | No ------------------------+---------------+------------------------- secp521r1 | ECDHE | No ------------------------+---------------+------------------------- sect283k1 | ECDHE | No ------------------------+---------------+------------------------- sect283r1 | ECDHE | No ------------------------+---------------+------------------------- sect409k1 | ECDHE | No ------------------------+---------------+------------------------- sect409r1 | ECDHE | No ------------------------+---------------+------------------------- sect571k1 | ECDHE | No ------------------------+---------------+------------------------- sect571r1 | ECDHE | No ------------------------+---------------+------------------------- ffdhe2048 | FFDHE | Yes ------------------------+---------------+------------------------- ffdhe3072 | FFDHE | Yes ------------------------+---------------+------------------------- ffdhe4096 | FFDHE | Yes ------------------------+---------------+------------------------- ffdhe6144 | FFDHE | Yes ------------------------+---------------+------------------------- ffdhe8192 | FFDHE | Yes ------------------------+---------------+------------------------- Thanks, Xuelei From tiantian.du at oracle.com Fri Apr 14 02:17:53 2017 From: tiantian.du at oracle.com (Tim Du) Date: Fri, 14 Apr 2017 10:17:53 +0800 Subject: [9] RFR:8178083 Remove intermittent key from java/security/SignedObject/Chain.java Message-ID: <2a5e25a1-f861-fe41-2bd7-01189d7363c3@oracle.com> Hi All, Would you help to review the path for "8178083:Remove intermittent key from java/security/SignedObject/Chain.java"? JDK-8136842 has been closed, @key intermittent can be removed.Thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8178083 webrev: http://cr.openjdk.java.net/~tidu/8178083/webrev.00/ Regards Tim From Xuelei.Fan at Oracle.Com Fri Apr 14 02:52:06 2017 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Thu, 13 Apr 2017 19:52:06 -0700 Subject: [9] RFR:8178083 Remove intermittent key from java/security/SignedObject/Chain.java In-Reply-To: <2a5e25a1-f861-fe41-2bd7-01189d7363c3@oracle.com> References: <2a5e25a1-f861-fe41-2bd7-01189d7363c3@oracle.com> Message-ID: Looks fine to me. > On Apr 13, 2017, at 7:17 PM, Tim Du wrote: > > Hi All, > > Would you help to review the path for "8178083:Remove intermittent key from java/security/SignedObject/Chain.java"? JDK-8136842 has been closed, @key intermittent can be removed.Thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8178083 > webrev: http://cr.openjdk.java.net/~tidu/8178083/webrev.00/ > > Regards > Tim > From weijun.wang at oracle.com Fri Apr 14 06:51:35 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 14 Apr 2017 14:51:35 +0800 Subject: RFR 8178795: krb5 Basic.java test should be basic Message-ID: Please take a review at http://cr.openjdk.java.net/~weijun/8178795/webrev.00/ Basic.java was reverted to what it was 5 years ago and an extra test ModuleName.java is created to cover what Basic.java does now, but simplified because it does not need any real communication between client/server/backend. After this change Basic.java becomes basic again so it's easy to create new tests based on it. Thanks Max From weijun.wang at oracle.com Fri Apr 14 07:18:42 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 14 Apr 2017 15:18:42 +0800 Subject: RFR 8178794: krb5 client should ignore sname in incoming tickets Message-ID: <0019ae5b-89da-de04-c143-1095893e5d45@oracle.com> Hi Valerie Please take a review of http://cr.openjdk.java.net/~weijun/8178794/webrev.00/ The sname field in the ticket is meant to be read by a server and the client should use the one inside KDC-REP's enc-part. Thanks Max From xuelei.fan at oracle.com Fri Apr 14 15:41:35 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 14 Apr 2017 08:41:35 -0700 Subject: RFR 8178795: krb5 Basic.java test should be basic In-Reply-To: References: Message-ID: <268f8efd-a63b-4a82-6a76-fa896d72c753@oracle.com> Looks fine to me. Xuelei On 4/13/2017 11:51 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8178795/webrev.00/ > > Basic.java was reverted to what it was 5 years ago and an extra test > ModuleName.java is created to cover what Basic.java does now, but > simplified because it does not need any real communication between > client/server/backend. > > After this change Basic.java becomes basic again so it's easy to create > new tests based on it. > > Thanks > Max From xuelei.fan at oracle.com Fri Apr 14 17:48:00 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 14 Apr 2017 10:48:00 -0700 Subject: Code Review Request, JDK-8140436, Support the FFDHE TLS extension In-Reply-To: <7c39a09f-4b78-fa57-1e81-c5ce3a6e72ab@oracle.com> References: <7c39a09f-4b78-fa57-1e81-c5ce3a6e72ab@oracle.com> Message-ID: <543886f9-8a5b-89a0-73c9-85aa8f1f8234@oracle.com> Hi, Adam Petcher have some good comments in a private mail to me. The webrev is updated accordingly: http://cr.openjdk.java.net/~xuelei/8140436/webrev.01/ Major update: No customization is allowed for the FFDHE parameters. Thanks, Xuelei On 4/13/2017 11:15 AM, Xuelei Fan wrote: > Hi, > > Please review the enhancement to support Finite Field Diffie-Hellman > Ephemeral (FFDHE) Parameters negotiation in SSL/TLS/DTLS implementation. > > http://cr.openjdk.java.net/~xuelei/8140436/webrev.00/ > > Updates: > 1. Support predefined FFDHE parameters. > JDK will support the following FFDHE parameters defined in RFC 7919, in > preference order: > name | key size (bits) > ---------------+------------------- > ffdhe2048 | 2048 > ---------------+------------------- > ffdhe3072 | 3072 > ---------------+------------------- > ffdhe4096 | 4096 > ---------------+------------------- > ffdhe6144 | 6144 > ---------------+------------------- > ffdhe8192 | 8192 > ---------------+------------------- > > > 2. Define a new System Property so as to disable the FFDHE mechanism > For RFC 7919 compatible client, the predefined FFDHE parameter names are > present in the "supported_groups" TLS extension. Some server may not be > able to handle this extension or the FFDHE groups in the extension. If > there is an interop issue, the new defined System Property, > "jsse.enableFFDHE", can be used to dismiss the predefined FFDHE > parameters for DHE cipher suites. > > 3. Redefine the jdk.tls.ephemeralDHKeySize System Property. > For connection request from RFC 7919 compatible clients, the server > would prefer to use FFDHE mechanism at first unless > "jdk.tls.ephemeralDHKeySize" is defined to use "legacy" mode for > compatibility reason. > > jdk.tls.ephemeralDHKeySize | FFDHE | Server behavior > ---------------------------+----------------------+---------------------- > "legacy" | in any case | Use legacy mode. > ---------------------------+----------------------+---------------------- > not "legacy" | Not present in the | Use DHE parameters > | ClientHello message | compatible to the > | | System Property. > ---------------------------+----------------------+---------------------- > not "legacy" | Present in the | Use the FFDHE > | ClientHello message | defined parameters. > > Note: Exportable cipher suites do not use the FFDHE mechanism. > > 4. Extend the "jdk.tls.namedGroups" System Property > Extend the "jdk.tls.namedGroups" System Property to support customized > FFDHE groups. The following names are now supported by the System > Property. > > Names for named group | For EC or DH | Is it new in the update? > ------------------------+---------------+------------------------- > secp256r1 | ECDHE | No > ------------------------+---------------+------------------------- > secp384r1 | ECDHE | No > ------------------------+---------------+------------------------- > secp521r1 | ECDHE | No > ------------------------+---------------+------------------------- > sect283k1 | ECDHE | No > ------------------------+---------------+------------------------- > sect283r1 | ECDHE | No > ------------------------+---------------+------------------------- > sect409k1 | ECDHE | No > ------------------------+---------------+------------------------- > sect409r1 | ECDHE | No > ------------------------+---------------+------------------------- > sect571k1 | ECDHE | No > ------------------------+---------------+------------------------- > sect571r1 | ECDHE | No > ------------------------+---------------+------------------------- > ffdhe2048 | FFDHE | Yes > ------------------------+---------------+------------------------- > ffdhe3072 | FFDHE | Yes > ------------------------+---------------+------------------------- > ffdhe4096 | FFDHE | Yes > ------------------------+---------------+------------------------- > ffdhe6144 | FFDHE | Yes > ------------------------+---------------+------------------------- > ffdhe8192 | FFDHE | Yes > ------------------------+---------------+------------------------- > > Thanks, > Xuelei > From steved at squareup.com Sat Apr 15 19:25:57 2017 From: steved at squareup.com (Steven Davidovitz) Date: Sat, 15 Apr 2017 12:25:57 -0700 Subject: RFR: Remove map synchronization from SignatureAndHashAlgorithm Message-ID: With the removal of the synchronization on priorityMap inside 'SignatureAndHashAlgorithm.getSupportedAlgorithms' in rev daaace32c979 [1], it seems unnecessary to use a synchronizedSortedMap. Benchmarking, I see a 2x performance increase by using the bare TreeMap. measureModified sample 11336330 11949.506 ? 1775.776 ns/op measureOriginal sample 10855026 23003.654 ? 2286.571 ns/op Thanks, Steven Davidovitz 1: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/daaace32c979 diff --git a/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java b/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java --- a/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java +++ b/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java @@ -396,46 +396,42 @@ } static { - supportedMap = Collections.synchronizedSortedMap( - new TreeMap()); - priorityMap = Collections.synchronizedSortedMap( - new TreeMap()); - - synchronized (supportedMap) { - int p = SUPPORTED_ALG_PRIORITY_MAX_NUM; - supports(HashAlgorithm.MD5, SignatureAlgorithm.RSA, - "MD5withRSA", --p); - supports(HashAlgorithm.SHA1, SignatureAlgorithm.DSA, - "SHA1withDSA", --p); - supports(HashAlgorithm.SHA1, SignatureAlgorithm.RSA, - "SHA1withRSA", --p); - supports(HashAlgorithm.SHA1, SignatureAlgorithm.ECDSA, - "SHA1withECDSA", --p); + supportedMap = new TreeMap(); + priorityMap = new TreeMap(); - if (Security.getProvider("SunMSCAPI") == null) { - supports(HashAlgorithm.SHA224, SignatureAlgorithm.DSA, - "SHA224withDSA", --p); - supports(HashAlgorithm.SHA224, SignatureAlgorithm.RSA, - "SHA224withRSA", --p); - supports(HashAlgorithm.SHA224, SignatureAlgorithm.ECDSA, - "SHA224withECDSA", --p); - } + int p = SUPPORTED_ALG_PRIORITY_MAX_NUM; + supports(HashAlgorithm.MD5, SignatureAlgorithm.RSA, + "MD5withRSA", --p); + supports(HashAlgorithm.SHA1, SignatureAlgorithm.DSA, + "SHA1withDSA", --p); + supports(HashAlgorithm.SHA1, SignatureAlgorithm.RSA, + "SHA1withRSA", --p); + supports(HashAlgorithm.SHA1, SignatureAlgorithm.ECDSA, + "SHA1withECDSA", --p); - supports(HashAlgorithm.SHA256, SignatureAlgorithm.DSA, - "SHA256withDSA", --p); - supports(HashAlgorithm.SHA256, SignatureAlgorithm.RSA, - "SHA256withRSA", --p); - supports(HashAlgorithm.SHA256, SignatureAlgorithm.ECDSA, - "SHA256withECDSA", --p); - supports(HashAlgorithm.SHA384, SignatureAlgorithm.RSA, - "SHA384withRSA", --p); - supports(HashAlgorithm.SHA384, SignatureAlgorithm.ECDSA, - "SHA384withECDSA", --p); - supports(HashAlgorithm.SHA512, SignatureAlgorithm.RSA, - "SHA512withRSA", --p); - supports(HashAlgorithm.SHA512, SignatureAlgorithm.ECDSA, - "SHA512withECDSA", --p); + if (Security.getProvider("SunMSCAPI") == null) { + supports(HashAlgorithm.SHA224, SignatureAlgorithm.DSA, + "SHA224withDSA", --p); + supports(HashAlgorithm.SHA224, SignatureAlgorithm.RSA, + "SHA224withRSA", --p); + supports(HashAlgorithm.SHA224, SignatureAlgorithm.ECDSA, + "SHA224withECDSA", --p); } + + supports(HashAlgorithm.SHA256, SignatureAlgorithm.DSA, + "SHA256withDSA", --p); + supports(HashAlgorithm.SHA256, SignatureAlgorithm.RSA, + "SHA256withRSA", --p); + supports(HashAlgorithm.SHA256, SignatureAlgorithm.ECDSA, + "SHA256withECDSA", --p); + supports(HashAlgorithm.SHA384, SignatureAlgorithm.RSA, + "SHA384withRSA", --p); + supports(HashAlgorithm.SHA384, SignatureAlgorithm.ECDSA, + "SHA384withECDSA", --p); + supports(HashAlgorithm.SHA512, SignatureAlgorithm.RSA, + "SHA512withRSA", --p); + supports(HashAlgorithm.SHA512, SignatureAlgorithm.ECDSA, + "SHA512withECDSA", --p); } } From openjdk at duigou.org Thu Apr 13 20:58:08 2017 From: openjdk at duigou.org (Mike Duigou) Date: Thu, 13 Apr 2017 13:58:08 -0700 Subject: Short AES GCM Tags? Message-ID: <8f592068a2fcbbc475112312d704b834@duigou.org> I've discovered that the Java 8 JSSE doesn't allow 64 or 32 bit tags to be used with AES GCM. (Enforced in CipherCore) I had hoped to use short tags per the guidance of NIST Special Publication 800-38D Appendix C. The Javadoc for GCMParameterSpec mentions 32 and 64 bit tags but I can't find an explanation of why small tags are not supported by Java 8 JSSE. Is there a reason that the short tags aren't offered? Thanks, Mike From valerie.peng at oracle.com Mon Apr 17 20:31:29 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 17 Apr 2017 13:31:29 -0700 Subject: Short AES GCM Tags? In-Reply-To: <8f592068a2fcbbc475112312d704b834@duigou.org> References: <8f592068a2fcbbc475112312d704b834@duigou.org> Message-ID: <6d720167-497b-7e91-5d9a-2a866956d83d@oracle.com> The short tag length is not for general applications and their usage comes with additional requirements such as length of input data and lifetime of the key which SunJCE provider does not implement. Thus, SunJCE provider limits the supported tag length to the 5 values defined for general-purpose applications. Regards, Valerie On 4/13/2017 1:58 PM, Mike Duigou wrote: > I've discovered that the Java 8 JSSE doesn't allow 64 or 32 bit tags > to be used with AES GCM. (Enforced in CipherCore) I had hoped to use > short tags per the guidance of NIST Special Publication 800-38D > Appendix C. The Javadoc for GCMParameterSpec mentions 32 and 64 bit > tags but I can't find an explanation of why small tags are not > supported by Java 8 JSSE. > > Is there a reason that the short tags aren't offered? > > Thanks, > > Mike From ecki at zusammenkunft.net Mon Apr 17 21:12:21 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 17 Apr 2017 21:12:21 +0000 Subject: Short AES GCM Tags? In-Reply-To: <6d720167-497b-7e91-5d9a-2a866956d83d@oracle.com> References: <8f592068a2fcbbc475112312d704b834@duigou.org>, <6d720167-497b-7e91-5d9a-2a866956d83d@oracle.com> Message-ID: Hello, I also think there is no short version for TLS anyway. RFC 5288 states that the Tag is 128 bit and the hmac truncation extension (which would allow 80 bit) is not valid for GCM. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: security-dev on behalf of Valerie Peng Sent: Monday, April 17, 2017 10:31:29 PM To: security-dev at openjdk.java.net Subject: Re: Short AES GCM Tags? The short tag length is not for general applications and their usage comes with additional requirements such as length of input data and lifetime of the key which SunJCE provider does not implement. Thus, SunJCE provider limits the supported tag length to the 5 values defined for general-purpose applications. Regards, Valerie On 4/13/2017 1:58 PM, Mike Duigou wrote: > I've discovered that the Java 8 JSSE doesn't allow 64 or 32 bit tags > to be used with AES GCM. (Enforced in CipherCore) I had hoped to use > short tags per the guidance of NIST Special Publication 800-38D > Appendix C. The Javadoc for GCMParameterSpec mentions 32 and 64 bit > tags but I can't find an explanation of why small tags are not > supported by Java 8 JSSE. > > Is there a reason that the short tags aren't offered? > > Thanks, > > Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Mon Apr 17 23:47:20 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 17 Apr 2017 16:47:20 -0700 Subject: Code Review Request, JDK-8140436, Support the FFDHE TLS extension In-Reply-To: <543886f9-8a5b-89a0-73c9-85aa8f1f8234@oracle.com> References: <7c39a09f-4b78-fa57-1e81-c5ce3a6e72ab@oracle.com> <543886f9-8a5b-89a0-73c9-85aa8f1f8234@oracle.com> Message-ID: <3189b87b-8ae7-7305-61d6-a19e4e3bc285@oracle.com> Hi Xuelei, one question and one nit, the rest looks pretty good. * SupportedGroupsExtension o Line 267 and 278: From what I can see historically and with TLS 1.3 draft 19 the underlying list for elliptic_curves and/or supported_groups extension data cannot be empty. Should there be guards in the two constructors to prevent use of an empty array or an incoming empty vector? * NamedGroup o This is a nit, but I'm curious why you didn't just overload valueOf as valueOf(int) and valueOf(String) similar to how Integer does it and others like it. I'm fine with it as-is if you prefer to keep it that way. --Jamil On 4/14/2017 10:48 AM, Xuelei Fan wrote: > Hi, > > Adam Petcher have some good comments in a private mail to me. The > webrev is updated accordingly: > > http://cr.openjdk.java.net/~xuelei/8140436/webrev.01/ > > Major update: No customization is allowed for the FFDHE parameters. > > Thanks, > Xuelei > > On 4/13/2017 11:15 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the enhancement to support Finite Field Diffie-Hellman >> Ephemeral (FFDHE) Parameters negotiation in SSL/TLS/DTLS implementation. >> >> http://cr.openjdk.java.net/~xuelei/8140436/webrev.00/ >> >> Updates: >> 1. Support predefined FFDHE parameters. >> JDK will support the following FFDHE parameters defined in RFC 7919, in >> preference order: >> name | key size (bits) >> ---------------+------------------- >> ffdhe2048 | 2048 >> ---------------+------------------- >> ffdhe3072 | 3072 >> ---------------+------------------- >> ffdhe4096 | 4096 >> ---------------+------------------- >> ffdhe6144 | 6144 >> ---------------+------------------- >> ffdhe8192 | 8192 >> ---------------+------------------- >> >> >> 2. Define a new System Property so as to disable the FFDHE mechanism >> For RFC 7919 compatible client, the predefined FFDHE parameter names are >> present in the "supported_groups" TLS extension. Some server may not be >> able to handle this extension or the FFDHE groups in the extension. If >> there is an interop issue, the new defined System Property, >> "jsse.enableFFDHE", can be used to dismiss the predefined FFDHE >> parameters for DHE cipher suites. >> >> 3. Redefine the jdk.tls.ephemeralDHKeySize System Property. >> For connection request from RFC 7919 compatible clients, the server >> would prefer to use FFDHE mechanism at first unless >> "jdk.tls.ephemeralDHKeySize" is defined to use "legacy" mode for >> compatibility reason. >> >> jdk.tls.ephemeralDHKeySize | FFDHE | Server behavior >> ---------------------------+----------------------+---------------------- >> >> "legacy" | in any case | Use legacy mode. >> ---------------------------+----------------------+---------------------- >> >> not "legacy" | Not present in the | Use DHE parameters >> | ClientHello message | compatible to the >> | | System Property. >> ---------------------------+----------------------+---------------------- >> >> not "legacy" | Present in the | Use the FFDHE >> | ClientHello message | defined parameters. >> >> Note: Exportable cipher suites do not use the FFDHE mechanism. >> >> 4. Extend the "jdk.tls.namedGroups" System Property >> Extend the "jdk.tls.namedGroups" System Property to support customized >> FFDHE groups. The following names are now supported by the System >> Property. >> >> Names for named group | For EC or DH | Is it new in the update? >> ------------------------+---------------+------------------------- >> secp256r1 | ECDHE | No >> ------------------------+---------------+------------------------- >> secp384r1 | ECDHE | No >> ------------------------+---------------+------------------------- >> secp521r1 | ECDHE | No >> ------------------------+---------------+------------------------- >> sect283k1 | ECDHE | No >> ------------------------+---------------+------------------------- >> sect283r1 | ECDHE | No >> ------------------------+---------------+------------------------- >> sect409k1 | ECDHE | No >> ------------------------+---------------+------------------------- >> sect409r1 | ECDHE | No >> ------------------------+---------------+------------------------- >> sect571k1 | ECDHE | No >> ------------------------+---------------+------------------------- >> sect571r1 | ECDHE | No >> ------------------------+---------------+------------------------- >> ffdhe2048 | FFDHE | Yes >> ------------------------+---------------+------------------------- >> ffdhe3072 | FFDHE | Yes >> ------------------------+---------------+------------------------- >> ffdhe4096 | FFDHE | Yes >> ------------------------+---------------+------------------------- >> ffdhe6144 | FFDHE | Yes >> ------------------------+---------------+------------------------- >> ffdhe8192 | FFDHE | Yes >> ------------------------+---------------+------------------------- >> >> Thanks, >> Xuelei >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Apr 18 03:18:08 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Apr 2017 20:18:08 -0700 Subject: Code Review Request, JDK-8140436, Support the FFDHE TLS extension In-Reply-To: <3189b87b-8ae7-7305-61d6-a19e4e3bc285@oracle.com> References: <7c39a09f-4b78-fa57-1e81-c5ce3a6e72ab@oracle.com> <543886f9-8a5b-89a0-73c9-85aa8f1f8234@oracle.com> <3189b87b-8ae7-7305-61d6-a19e4e3bc285@oracle.com> Message-ID: <0f017ba3-fb52-dbdd-3953-63bd9bafac02@oracle.com> On 4/17/2017 4:47 PM, Jamil Nimeh wrote: > Hi Xuelei, one question and one nit, the rest looks pretty good. > > * SupportedGroupsExtension > o Line 267 and 278: From what I can see historically and with TLS > 1.3 draft 19 the underlying list for elliptic_curves and/or > supported_groups extension data cannot be empty. Should there > be guards in the two constructors to prevent use of an empty > array or an incoming empty vector? Good catch! Line 267 is a private constructor. The caller does not use empty groups (line 356-364). For the comment for line 278, I added a check in line 274 (see the updated webrev.01): -274 if (((len & 1) != 0) || (k + 2 != len)) { +274 if (((len & 1) != 0) || (k == 0) || (k + 2 != len)) { An SSLProtocolException will be thrown if the incoming vector is empty. > * NamedGroup > o This is a nit, but I'm curious why you didn't just overload > valueOf as valueOf(int) and valueOf(String) similar to how > Integer does it and others like it. I'm fine with it as-is if > you prefer to keep it that way. > The valueOf(String) is a builtin method of Java enum, and cannot be overrode. So I use an alternative method, nameOf(String). Thanks, Xuelei > --Jamil > > > On 4/14/2017 10:48 AM, Xuelei Fan wrote: >> Hi, >> >> Adam Petcher have some good comments in a private mail to me. The >> webrev is updated accordingly: >> >> http://cr.openjdk.java.net/~xuelei/8140436/webrev.01/ >> >> Major update: No customization is allowed for the FFDHE parameters. >> >> Thanks, >> Xuelei >> >> On 4/13/2017 11:15 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review the enhancement to support Finite Field Diffie-Hellman >>> Ephemeral (FFDHE) Parameters negotiation in SSL/TLS/DTLS implementation. >>> >>> http://cr.openjdk.java.net/~xuelei/8140436/webrev.00/ >>> >>> Updates: >>> 1. Support predefined FFDHE parameters. >>> JDK will support the following FFDHE parameters defined in RFC 7919, in >>> preference order: >>> name | key size (bits) >>> ---------------+------------------- >>> ffdhe2048 | 2048 >>> ---------------+------------------- >>> ffdhe3072 | 3072 >>> ---------------+------------------- >>> ffdhe4096 | 4096 >>> ---------------+------------------- >>> ffdhe6144 | 6144 >>> ---------------+------------------- >>> ffdhe8192 | 8192 >>> ---------------+------------------- >>> >>> >>> 2. Define a new System Property so as to disable the FFDHE mechanism >>> For RFC 7919 compatible client, the predefined FFDHE parameter names are >>> present in the "supported_groups" TLS extension. Some server may not be >>> able to handle this extension or the FFDHE groups in the extension. If >>> there is an interop issue, the new defined System Property, >>> "jsse.enableFFDHE", can be used to dismiss the predefined FFDHE >>> parameters for DHE cipher suites. >>> >>> 3. Redefine the jdk.tls.ephemeralDHKeySize System Property. >>> For connection request from RFC 7919 compatible clients, the server >>> would prefer to use FFDHE mechanism at first unless >>> "jdk.tls.ephemeralDHKeySize" is defined to use "legacy" mode for >>> compatibility reason. >>> >>> jdk.tls.ephemeralDHKeySize | FFDHE | Server behavior >>> ---------------------------+----------------------+---------------------- >>> >>> "legacy" | in any case | Use legacy mode. >>> ---------------------------+----------------------+---------------------- >>> >>> not "legacy" | Not present in the | Use DHE parameters >>> | ClientHello message | compatible to the >>> | | System Property. >>> ---------------------------+----------------------+---------------------- >>> >>> not "legacy" | Present in the | Use the FFDHE >>> | ClientHello message | defined parameters. >>> >>> Note: Exportable cipher suites do not use the FFDHE mechanism. >>> >>> 4. Extend the "jdk.tls.namedGroups" System Property >>> Extend the "jdk.tls.namedGroups" System Property to support customized >>> FFDHE groups. The following names are now supported by the System >>> Property. >>> >>> Names for named group | For EC or DH | Is it new in the update? >>> ------------------------+---------------+------------------------- >>> secp256r1 | ECDHE | No >>> ------------------------+---------------+------------------------- >>> secp384r1 | ECDHE | No >>> ------------------------+---------------+------------------------- >>> secp521r1 | ECDHE | No >>> ------------------------+---------------+------------------------- >>> sect283k1 | ECDHE | No >>> ------------------------+---------------+------------------------- >>> sect283r1 | ECDHE | No >>> ------------------------+---------------+------------------------- >>> sect409k1 | ECDHE | No >>> ------------------------+---------------+------------------------- >>> sect409r1 | ECDHE | No >>> ------------------------+---------------+------------------------- >>> sect571k1 | ECDHE | No >>> ------------------------+---------------+------------------------- >>> sect571r1 | ECDHE | No >>> ------------------------+---------------+------------------------- >>> ffdhe2048 | FFDHE | Yes >>> ------------------------+---------------+------------------------- >>> ffdhe3072 | FFDHE | Yes >>> ------------------------+---------------+------------------------- >>> ffdhe4096 | FFDHE | Yes >>> ------------------------+---------------+------------------------- >>> ffdhe6144 | FFDHE | Yes >>> ------------------------+---------------+------------------------- >>> ffdhe8192 | FFDHE | Yes >>> ------------------------+---------------+------------------------- >>> >>> Thanks, >>> Xuelei >>> > From jamil.j.nimeh at oracle.com Tue Apr 18 04:06:34 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 17 Apr 2017 21:06:34 -0700 Subject: Code Review Request, JDK-8140436, Support the FFDHE TLS extension In-Reply-To: <0f017ba3-fb52-dbdd-3953-63bd9bafac02@oracle.com> References: <7c39a09f-4b78-fa57-1e81-c5ce3a6e72ab@oracle.com> <543886f9-8a5b-89a0-73c9-85aa8f1f8234@oracle.com> <3189b87b-8ae7-7305-61d6-a19e4e3bc285@oracle.com> <0f017ba3-fb52-dbdd-3953-63bd9bafac02@oracle.com> Message-ID: Hi Xuelei, comments in-line: On 4/17/2017 8:18 PM, Xuelei Fan wrote: > On 4/17/2017 4:47 PM, Jamil Nimeh wrote: >> Hi Xuelei, one question and one nit, the rest looks pretty good. >> >> * SupportedGroupsExtension >> o Line 267 and 278: From what I can see historically and with TLS >> 1.3 draft 19 the underlying list for elliptic_curves and/or >> supported_groups extension data cannot be empty. Should there >> be guards in the two constructors to prevent use of an empty >> array or an incoming empty vector? > Good catch! > > Line 267 is a private constructor. The caller does not use empty > groups (line 356-364). > > For the comment for line 278, I added a check in line 274 (see the > updated webrev.01): > -274 if (((len & 1) != 0) || (k + 2 != len)) { > +274 if (((len & 1) != 0) || (k == 0) || (k + 2 != len)) { > > An SSLProtocolException will be thrown if the incoming vector is empty. Looks good to me. > > >> * NamedGroup >> o This is a nit, but I'm curious why you didn't just overload >> valueOf as valueOf(int) and valueOf(String) similar to how >> Integer does it and others like it. I'm fine with it as-is if >> you prefer to keep it that way. >> > The valueOf(String) is a builtin method of Java enum, and cannot be > overrode. So I use an alternative method, nameOf(String). Okay, that works for me. > > Thanks, > Xuelei > >> --Jamil >> >> >> On 4/14/2017 10:48 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Adam Petcher have some good comments in a private mail to me. The >>> webrev is updated accordingly: >>> >>> http://cr.openjdk.java.net/~xuelei/8140436/webrev.01/ >>> >>> Major update: No customization is allowed for the FFDHE parameters. >>> >>> Thanks, >>> Xuelei >>> >>> On 4/13/2017 11:15 AM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Please review the enhancement to support Finite Field Diffie-Hellman >>>> Ephemeral (FFDHE) Parameters negotiation in SSL/TLS/DTLS >>>> implementation. >>>> >>>> http://cr.openjdk.java.net/~xuelei/8140436/webrev.00/ >>>> >>>> Updates: >>>> 1. Support predefined FFDHE parameters. >>>> JDK will support the following FFDHE parameters defined in RFC >>>> 7919, in >>>> preference order: >>>> name | key size (bits) >>>> ---------------+------------------- >>>> ffdhe2048 | 2048 >>>> ---------------+------------------- >>>> ffdhe3072 | 3072 >>>> ---------------+------------------- >>>> ffdhe4096 | 4096 >>>> ---------------+------------------- >>>> ffdhe6144 | 6144 >>>> ---------------+------------------- >>>> ffdhe8192 | 8192 >>>> ---------------+------------------- >>>> >>>> >>>> 2. Define a new System Property so as to disable the FFDHE mechanism >>>> For RFC 7919 compatible client, the predefined FFDHE parameter >>>> names are >>>> present in the "supported_groups" TLS extension. Some server may >>>> not be >>>> able to handle this extension or the FFDHE groups in the >>>> extension. If >>>> there is an interop issue, the new defined System Property, >>>> "jsse.enableFFDHE", can be used to dismiss the predefined FFDHE >>>> parameters for DHE cipher suites. >>>> >>>> 3. Redefine the jdk.tls.ephemeralDHKeySize System Property. >>>> For connection request from RFC 7919 compatible clients, the server >>>> would prefer to use FFDHE mechanism at first unless >>>> "jdk.tls.ephemeralDHKeySize" is defined to use "legacy" mode for >>>> compatibility reason. >>>> >>>> jdk.tls.ephemeralDHKeySize | FFDHE | Server behavior >>>> ---------------------------+----------------------+---------------------- >>>> >>>> >>>> "legacy" | in any case | Use legacy mode. >>>> ---------------------------+----------------------+---------------------- >>>> >>>> >>>> not "legacy" | Not present in the | Use DHE parameters >>>> | ClientHello message | compatible to the >>>> | | System Property. >>>> ---------------------------+----------------------+---------------------- >>>> >>>> >>>> not "legacy" | Present in the | Use the FFDHE >>>> | ClientHello message | defined >>>> parameters. >>>> >>>> Note: Exportable cipher suites do not use the FFDHE mechanism. >>>> >>>> 4. Extend the "jdk.tls.namedGroups" System Property >>>> Extend the "jdk.tls.namedGroups" System Property to support customized >>>> FFDHE groups. The following names are now supported by the System >>>> Property. >>>> >>>> Names for named group | For EC or DH | Is it new in the update? >>>> ------------------------+---------------+------------------------- >>>> secp256r1 | ECDHE | No >>>> ------------------------+---------------+------------------------- >>>> secp384r1 | ECDHE | No >>>> ------------------------+---------------+------------------------- >>>> secp521r1 | ECDHE | No >>>> ------------------------+---------------+------------------------- >>>> sect283k1 | ECDHE | No >>>> ------------------------+---------------+------------------------- >>>> sect283r1 | ECDHE | No >>>> ------------------------+---------------+------------------------- >>>> sect409k1 | ECDHE | No >>>> ------------------------+---------------+------------------------- >>>> sect409r1 | ECDHE | No >>>> ------------------------+---------------+------------------------- >>>> sect571k1 | ECDHE | No >>>> ------------------------+---------------+------------------------- >>>> sect571r1 | ECDHE | No >>>> ------------------------+---------------+------------------------- >>>> ffdhe2048 | FFDHE | Yes >>>> ------------------------+---------------+------------------------- >>>> ffdhe3072 | FFDHE | Yes >>>> ------------------------+---------------+------------------------- >>>> ffdhe4096 | FFDHE | Yes >>>> ------------------------+---------------+------------------------- >>>> ffdhe6144 | FFDHE | Yes >>>> ------------------------+---------------+------------------------- >>>> ffdhe8192 | FFDHE | Yes >>>> ------------------------+---------------+------------------------- >>>> >>>> Thanks, >>>> Xuelei >>>> >> From ecki at zusammenkunft.net Tue Apr 25 01:07:45 2017 From: ecki at zusammenkunft.net (Bernd) Date: Tue, 25 Apr 2017 03:07:45 +0200 Subject: NTNumericCredential of the NTLoginModule JAAS module Message-ID: Hello, I (re)discovered a class com.sun.security.auth.NTNumericCredential in the OpenJDK which I was researching ten years back but could not get an answer (then). Maybe somebody here knows: The NTLoginModule for JAAS reads the current users Windows security information and represents them as principals and credentials (i.e. it ignores the password callback as it only reads the current OS users context). It is somewhat nice to get username and group SIDs, but I am not sure how this can be used for authentication (since there is no client/server trust boundary). Anyway, the thing I am curious about: it also returns a public credential called NTNumericCredential which contains the long number of a security token duplicated for local impersonation. *

This class abstracts an NT security token * and provides a mechanism to do same-process security impersonation. http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/329609d00aef/src/jdk.security.auth/windows/native/libjaas/nt.c#l573 I can however nowhere find any sample how this can be used. Especially not since the token represents the current user / thread token which is IMHO not changed? Is this somehow used after other (native) authentication. Does anybody know how this can be used or how it was used? The UnixSystem/UnixLoginModule counterpart does not have this provision. Any generally is there a good use for the NTLoginModule, how would it be used to actually enforce access control? Gruss Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Apr 25 14:05:40 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 25 Apr 2017 10:05:40 -0400 Subject: RFR: Remove map synchronization from SignatureAndHashAlgorithm In-Reply-To: References: Message-ID: <6babf120-69b9-ffab-7542-831334762186@oracle.com> Hi Steven, Thanks, I filed an issue on your behalf for tracking purposes: https://bugs.openjdk.java.net/browse/JDK-8179275 Also, have you signed the OCA? See http://www.oracle.com/technetwork/community/oca-486395.html for more information. --Sean On 4/15/17 3:25 PM, Steven Davidovitz wrote: > With the removal of the synchronization on priorityMap inside > 'SignatureAndHashAlgorithm.getSupportedAlgorithms' in rev daaace32c979 > [1], it seems unnecessary to use a synchronizedSortedMap. > Benchmarking, I see a 2x performance increase by using the bare > TreeMap. > > measureModified sample 11336330 11949.506 ? 1775.776 ns/op > measureOriginal sample 10855026 23003.654 ? 2286.571 ns/op > > Thanks, > Steven Davidovitz > > 1: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/daaace32c979 > > diff --git a/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java > b/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java > --- a/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java > +++ b/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java > @@ -396,46 +396,42 @@ > } > > static { > - supportedMap = Collections.synchronizedSortedMap( > - new TreeMap()); > - priorityMap = Collections.synchronizedSortedMap( > - new TreeMap()); > - > - synchronized (supportedMap) { > - int p = SUPPORTED_ALG_PRIORITY_MAX_NUM; > - supports(HashAlgorithm.MD5, SignatureAlgorithm.RSA, > - "MD5withRSA", --p); > - supports(HashAlgorithm.SHA1, SignatureAlgorithm.DSA, > - "SHA1withDSA", --p); > - supports(HashAlgorithm.SHA1, SignatureAlgorithm.RSA, > - "SHA1withRSA", --p); > - supports(HashAlgorithm.SHA1, SignatureAlgorithm.ECDSA, > - "SHA1withECDSA", --p); > + supportedMap = new TreeMap(); > + priorityMap = new TreeMap(); > > - if (Security.getProvider("SunMSCAPI") == null) { > - supports(HashAlgorithm.SHA224, SignatureAlgorithm.DSA, > - "SHA224withDSA", --p); > - supports(HashAlgorithm.SHA224, SignatureAlgorithm.RSA, > - "SHA224withRSA", --p); > - supports(HashAlgorithm.SHA224, SignatureAlgorithm.ECDSA, > - "SHA224withECDSA", --p); > - } > + int p = SUPPORTED_ALG_PRIORITY_MAX_NUM; > + supports(HashAlgorithm.MD5, SignatureAlgorithm.RSA, > + "MD5withRSA", --p); > + supports(HashAlgorithm.SHA1, SignatureAlgorithm.DSA, > + "SHA1withDSA", --p); > + supports(HashAlgorithm.SHA1, SignatureAlgorithm.RSA, > + "SHA1withRSA", --p); > + supports(HashAlgorithm.SHA1, SignatureAlgorithm.ECDSA, > + "SHA1withECDSA", --p); > > - supports(HashAlgorithm.SHA256, SignatureAlgorithm.DSA, > - "SHA256withDSA", --p); > - supports(HashAlgorithm.SHA256, SignatureAlgorithm.RSA, > - "SHA256withRSA", --p); > - supports(HashAlgorithm.SHA256, SignatureAlgorithm.ECDSA, > - "SHA256withECDSA", --p); > - supports(HashAlgorithm.SHA384, SignatureAlgorithm.RSA, > - "SHA384withRSA", --p); > - supports(HashAlgorithm.SHA384, SignatureAlgorithm.ECDSA, > - "SHA384withECDSA", --p); > - supports(HashAlgorithm.SHA512, SignatureAlgorithm.RSA, > - "SHA512withRSA", --p); > - supports(HashAlgorithm.SHA512, SignatureAlgorithm.ECDSA, > - "SHA512withECDSA", --p); > + if (Security.getProvider("SunMSCAPI") == null) { > + supports(HashAlgorithm.SHA224, SignatureAlgorithm.DSA, > + "SHA224withDSA", --p); > + supports(HashAlgorithm.SHA224, SignatureAlgorithm.RSA, > + "SHA224withRSA", --p); > + supports(HashAlgorithm.SHA224, SignatureAlgorithm.ECDSA, > + "SHA224withECDSA", --p); > } > + > + supports(HashAlgorithm.SHA256, SignatureAlgorithm.DSA, > + "SHA256withDSA", --p); > + supports(HashAlgorithm.SHA256, SignatureAlgorithm.RSA, > + "SHA256withRSA", --p); > + supports(HashAlgorithm.SHA256, SignatureAlgorithm.ECDSA, > + "SHA256withECDSA", --p); > + supports(HashAlgorithm.SHA384, SignatureAlgorithm.RSA, > + "SHA384withRSA", --p); > + supports(HashAlgorithm.SHA384, SignatureAlgorithm.ECDSA, > + "SHA384withECDSA", --p); > + supports(HashAlgorithm.SHA512, SignatureAlgorithm.RSA, > + "SHA512withRSA", --p); > + supports(HashAlgorithm.SHA512, SignatureAlgorithm.ECDSA, > + "SHA512withECDSA", --p); > } > } > From steved at squareup.com Wed Apr 26 17:52:48 2017 From: steved at squareup.com (Steven Davidovitz) Date: Wed, 26 Apr 2017 10:52:48 -0700 Subject: RFR: Remove map synchronization from SignatureAndHashAlgorithm In-Reply-To: <6babf120-69b9-ffab-7542-831334762186@oracle.com> References: <6babf120-69b9-ffab-7542-831334762186@oracle.com> Message-ID: Thanks! I'm working on the OCA right now, I made a mistake when I submitted it before so I'll follow up when it's done. Anything else I need to do? Could this also be backported to version 8? On Tue, Apr 25, 2017 at 7:05 AM, Sean Mullan wrote: > Hi Steven, > > Thanks, I filed an issue on your behalf for tracking purposes: > https://bugs.openjdk.java.net/browse/JDK-8179275 > > Also, have you signed the OCA? See http://www.oracle.com/technetw > ork/community/oca-486395.html for more information. > > --Sean > > > On 4/15/17 3:25 PM, Steven Davidovitz wrote: > >> With the removal of the synchronization on priorityMap inside >> 'SignatureAndHashAlgorithm.getSupportedAlgorithms' in rev daaace32c979 >> [1], it seems unnecessary to use a synchronizedSortedMap. >> Benchmarking, I see a 2x performance increase by using the bare >> TreeMap. >> >> measureModified sample 11336330 11949.506 ? 1775.776 ns/op >> measureOriginal sample 10855026 23003.654 ? 2286.571 ns/op >> >> Thanks, >> Steven Davidovitz >> >> 1: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/daaace32c979 >> >> diff --git a/src/java.base/share/classes/sun/security/ssl/SignatureAndH >> ashAlgorithm.java >> b/src/java.base/share/classes/sun/security/ssl/SignatureAndH >> ashAlgorithm.java >> --- a/src/java.base/share/classes/sun/security/ssl/SignatureAndH >> ashAlgorithm.java >> +++ b/src/java.base/share/classes/sun/security/ssl/SignatureAndH >> ashAlgorithm.java >> @@ -396,46 +396,42 @@ >> } >> >> static { >> - supportedMap = Collections.synchronizedSortedMap( >> - new TreeMap()); >> - priorityMap = Collections.synchronizedSortedMap( >> - new TreeMap()); >> - >> - synchronized (supportedMap) { >> - int p = SUPPORTED_ALG_PRIORITY_MAX_NUM; >> - supports(HashAlgorithm.MD5, SignatureAlgorithm.RSA, >> - "MD5withRSA", --p); >> - supports(HashAlgorithm.SHA1, SignatureAlgorithm.DSA, >> - "SHA1withDSA", --p); >> - supports(HashAlgorithm.SHA1, SignatureAlgorithm.RSA, >> - "SHA1withRSA", --p); >> - supports(HashAlgorithm.SHA1, SignatureAlgorithm.ECDSA, >> - "SHA1withECDSA", --p); >> + supportedMap = new TreeMap(); >> + priorityMap = new TreeMap(); >> >> - if (Security.getProvider("SunMSCAPI") == null) { >> - supports(HashAlgorithm.SHA224, >> SignatureAlgorithm.DSA, >> - "SHA224withDSA", --p); >> - supports(HashAlgorithm.SHA224, >> SignatureAlgorithm.RSA, >> - "SHA224withRSA", --p); >> - supports(HashAlgorithm.SHA224, >> SignatureAlgorithm.ECDSA, >> - "SHA224withECDSA", --p); >> - } >> + int p = SUPPORTED_ALG_PRIORITY_MAX_NUM; >> + supports(HashAlgorithm.MD5, SignatureAlgorithm.RSA, >> + "MD5withRSA", --p); >> + supports(HashAlgorithm.SHA1, SignatureAlgorithm.DSA, >> + "SHA1withDSA", --p); >> + supports(HashAlgorithm.SHA1, SignatureAlgorithm.RSA, >> + "SHA1withRSA", --p); >> + supports(HashAlgorithm.SHA1, SignatureAlgorithm.ECDSA, >> + "SHA1withECDSA", --p); >> >> - supports(HashAlgorithm.SHA256, SignatureAlgorithm.DSA, >> - "SHA256withDSA", --p); >> - supports(HashAlgorithm.SHA256, SignatureAlgorithm.RSA, >> - "SHA256withRSA", --p); >> - supports(HashAlgorithm.SHA256, >> SignatureAlgorithm.ECDSA, >> - "SHA256withECDSA", --p); >> - supports(HashAlgorithm.SHA384, SignatureAlgorithm.RSA, >> - "SHA384withRSA", --p); >> - supports(HashAlgorithm.SHA384, >> SignatureAlgorithm.ECDSA, >> - "SHA384withECDSA", --p); >> - supports(HashAlgorithm.SHA512, SignatureAlgorithm.RSA, >> - "SHA512withRSA", --p); >> - supports(HashAlgorithm.SHA512, >> SignatureAlgorithm.ECDSA, >> - "SHA512withECDSA", --p); >> + if (Security.getProvider("SunMSCAPI") == null) { >> + supports(HashAlgorithm.SHA224, SignatureAlgorithm.DSA, >> + "SHA224withDSA", --p); >> + supports(HashAlgorithm.SHA224, SignatureAlgorithm.RSA, >> + "SHA224withRSA", --p); >> + supports(HashAlgorithm.SHA224, >> SignatureAlgorithm.ECDSA, >> + "SHA224withECDSA", --p); >> } >> + >> + supports(HashAlgorithm.SHA256, SignatureAlgorithm.DSA, >> + "SHA256withDSA", --p); >> + supports(HashAlgorithm.SHA256, SignatureAlgorithm.RSA, >> + "SHA256withRSA", --p); >> + supports(HashAlgorithm.SHA256, SignatureAlgorithm.ECDSA, >> + "SHA256withECDSA", --p); >> + supports(HashAlgorithm.SHA384, SignatureAlgorithm.RSA, >> + "SHA384withRSA", --p); >> + supports(HashAlgorithm.SHA384, SignatureAlgorithm.ECDSA, >> + "SHA384withECDSA", --p); >> + supports(HashAlgorithm.SHA512, SignatureAlgorithm.RSA, >> + "SHA512withRSA", --p); >> + supports(HashAlgorithm.SHA512, SignatureAlgorithm.ECDSA, >> + "SHA512withECDSA", --p); >> } >> } >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Apr 26 20:31:19 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 26 Apr 2017 16:31:19 -0400 Subject: RFR: Remove map synchronization from SignatureAndHashAlgorithm In-Reply-To: References: <6babf120-69b9-ffab-7542-831334762186@oracle.com> Message-ID: On 4/26/17 1:52 PM, Steven Davidovitz wrote: > Thanks! I'm working on the OCA right now, I made a mistake when I > submitted it before so I'll follow up when it's done. > > Anything else I need to do? Could this also be backported to version 8? We are already at RDP2 [1] for JDK 9. Only P1 and P2 bugs that are critical issues should be fixed now and in my opinion, this is not a critical issue for JDK 9. So we will need to fix it in JDK 10 first. Backports to a 9u/8u release can be considered later. --Sean [1] http://openjdk.java.net/projects/jdk9/rdp-2 > > On Tue, Apr 25, 2017 at 7:05 AM, Sean Mullan > wrote: > > Hi Steven, > > Thanks, I filed an issue on your behalf for tracking purposes: > https://bugs.openjdk.java.net/browse/JDK-8179275 > > > Also, have you signed the OCA? See > http://www.oracle.com/technetwork/community/oca-486395.html > for > more information. > > --Sean > > > On 4/15/17 3:25 PM, Steven Davidovitz wrote: > > With the removal of the synchronization on priorityMap inside > 'SignatureAndHashAlgorithm.getSupportedAlgorithms' in rev > daaace32c979 > [1], it seems unnecessary to use a synchronizedSortedMap. > Benchmarking, I see a 2x performance increase by using the bare > TreeMap. > > measureModified sample 11336330 11949.506 ? 1775.776 ns/op > measureOriginal sample 10855026 23003.654 ? 2286.571 ns/op > > Thanks, > Steven Davidovitz > > 1: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/daaace32c979 > > > diff --git > a/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java > b/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java > --- > a/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java > +++ > b/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java > @@ -396,46 +396,42 @@ > } > > static { > - supportedMap = Collections.synchronizedSortedMap( > - new TreeMap()); > - priorityMap = Collections.synchronizedSortedMap( > - new TreeMap()); > - > - synchronized (supportedMap) { > - int p = SUPPORTED_ALG_PRIORITY_MAX_NUM; > - supports(HashAlgorithm.MD5, > SignatureAlgorithm.RSA, > - "MD5withRSA", --p); > - supports(HashAlgorithm.SHA1, > SignatureAlgorithm.DSA, > - "SHA1withDSA", --p); > - supports(HashAlgorithm.SHA1, > SignatureAlgorithm.RSA, > - "SHA1withRSA", --p); > - supports(HashAlgorithm.SHA1, > SignatureAlgorithm.ECDSA, > - "SHA1withECDSA", --p); > + supportedMap = new TreeMap SignatureAndHashAlgorithm>(); > + priorityMap = new TreeMap SignatureAndHashAlgorithm>(); > > - if (Security.getProvider("SunMSCAPI") == null) { > - supports(HashAlgorithm.SHA224, > SignatureAlgorithm.DSA, > - "SHA224withDSA", --p); > - supports(HashAlgorithm.SHA224, > SignatureAlgorithm.RSA, > - "SHA224withRSA", --p); > - supports(HashAlgorithm.SHA224, > SignatureAlgorithm.ECDSA, > - "SHA224withECDSA", --p); > - } > + int p = SUPPORTED_ALG_PRIORITY_MAX_NUM; > + supports(HashAlgorithm.MD5, SignatureAlgorithm.RSA, > + "MD5withRSA", --p); > + supports(HashAlgorithm.SHA1, SignatureAlgorithm.DSA, > + "SHA1withDSA", --p); > + supports(HashAlgorithm.SHA1, SignatureAlgorithm.RSA, > + "SHA1withRSA", --p); > + supports(HashAlgorithm.SHA1, > SignatureAlgorithm.ECDSA, > + "SHA1withECDSA", --p); > > - supports(HashAlgorithm.SHA256, > SignatureAlgorithm.DSA, > - "SHA256withDSA", --p); > - supports(HashAlgorithm.SHA256, > SignatureAlgorithm.RSA, > - "SHA256withRSA", --p); > - supports(HashAlgorithm.SHA256, > SignatureAlgorithm.ECDSA, > - "SHA256withECDSA", --p); > - supports(HashAlgorithm.SHA384, > SignatureAlgorithm.RSA, > - "SHA384withRSA", --p); > - supports(HashAlgorithm.SHA384, > SignatureAlgorithm.ECDSA, > - "SHA384withECDSA", --p); > - supports(HashAlgorithm.SHA512, > SignatureAlgorithm.RSA, > - "SHA512withRSA", --p); > - supports(HashAlgorithm.SHA512, > SignatureAlgorithm.ECDSA, > - "SHA512withECDSA", --p); > + if (Security.getProvider("SunMSCAPI") == null) { > + supports(HashAlgorithm.SHA224, > SignatureAlgorithm.DSA, > + "SHA224withDSA", --p); > + supports(HashAlgorithm.SHA224, > SignatureAlgorithm.RSA, > + "SHA224withRSA", --p); > + supports(HashAlgorithm.SHA224, > SignatureAlgorithm.ECDSA, > + "SHA224withECDSA", --p); > } > + > + supports(HashAlgorithm.SHA256, SignatureAlgorithm.DSA, > + "SHA256withDSA", --p); > + supports(HashAlgorithm.SHA256, SignatureAlgorithm.RSA, > + "SHA256withRSA", --p); > + supports(HashAlgorithm.SHA256, > SignatureAlgorithm.ECDSA, > + "SHA256withECDSA", --p); > + supports(HashAlgorithm.SHA384, SignatureAlgorithm.RSA, > + "SHA384withRSA", --p); > + supports(HashAlgorithm.SHA384, > SignatureAlgorithm.ECDSA, > + "SHA384withECDSA", --p); > + supports(HashAlgorithm.SHA512, SignatureAlgorithm.RSA, > + "SHA512withRSA", --p); > + supports(HashAlgorithm.SHA512, > SignatureAlgorithm.ECDSA, > + "SHA512withECDSA", --p); > } > } > > From jonathan.gibbons at oracle.com Thu Apr 27 00:50:55 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 26 Apr 2017 17:50:55 -0700 Subject: RFR: 8179370: Replace use of ,

and tags in java.base Message-ID: <5901406F.6080402@oracle.com> Please review these mostly simple changes to replace HTML tags which are not valid in HTML 5 in public doc comments in java.base. As with the previous changes, the changes were done mechanically, using the following sed script: s|||g s|||g s|<\\/tt>|<\\/code>|g s|\(]*\)>
\([^<]*\)
|\1 style="text-align:center">\2| s|
|| s||| The unusual form of the 3rd line was to cover the occurrence in a makefile. The 4th line is specific for DataInput.java, and replaces
within a
with a style on the element itself. The 5th and 6th lines are specific to URLConnection. The use of the table itself and the ASCII art that follows it are questionable, but the intent here is just to update the HTML and not to rework the visual appearance of the generated documentation. The changes cover files in the following packages: java.base java/io java.base java/net java.base java/util java.base javax/net/ssl JBS: https://bugs.openjdk.java.net/browse/JDK-8179370 Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/ -- Jon From joe.darcy at oracle.com Thu Apr 27 00:55:49 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 26 Apr 2017 17:55:49 -0700 Subject: RFR: 8179370: Replace use of ,
and tags in java.base In-Reply-To: <5901406F.6080402@oracle.com> References: <5901406F.6080402@oracle.com> Message-ID: <59014195.1070408@oracle.com> Hi Jon, I'd prefer if the "foo" were replaced with "{@code tt}" rather than "foo"- none of the tricky cases which preclude use of {@code } use seem to be present here - but will approve the changeset in its current form too. Cheers, -Joe On 4/26/2017 5:50 PM, Jonathan Gibbons wrote: > Please review these mostly simple changes to replace HTML tags which > are not valid in HTML 5 in public doc comments in java.base. > > As with the previous changes, the changes were done mechanically, > using the following sed script: > > s|||g > s|||g > s|<\\/tt>|<\\/code>|g > s|\(]*\)>
\([^<]*\)
|\1 > style="text-align:center">\2| > s|
style="margin:0 auto" | > s||| > s| s||| > > The unusual form of the 3rd line was to cover the occurrence in a > makefile. > > The 4th line is specific for DataInput.java, and replaces
> within a
with a style on the element itself. > > The 5th and 6th lines are specific to URLConnection. The use of the > table itself and the ASCII art that follows it are questionable, but > the intent here is just to update the HTML and not to rework the > visual appearance of the generated documentation. > > The changes cover files in the following packages: > > java.base java/io > java.base java/net > java.base java/util > java.base javax/net/ssl > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8179370 > Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/ > > -- Jon From jonathan.gibbons at oracle.com Thu Apr 27 01:09:52 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 26 Apr 2017 18:09:52 -0700 Subject: RFR: 8179370: Replace use of ,
and tags in java.base In-Reply-To: <59014195.1070408@oracle.com> References: <5901406F.6080402@oracle.com> <59014195.1070408@oracle.com> Message-ID: <590144E0.4050400@oracle.com> Joe, Yes, there are occurrences here that require instead of {@code}, because of the presence of HTML entities. It's about 50/50. I'd prefer to stay with mechanical updates as much as possible for these bulk updates, as compared to manual updates, but I may be able to improve the sed script for this case. -- Jon On 04/26/2017 05:55 PM, Joseph D. Darcy wrote: > Hi Jon, > > I'd prefer if the "foo" were replaced with "{@code tt}" > rather than "foo"- none of the tricky cases which > preclude use of {@code } use seem to be present here - but will > approve the changeset in its current form too. > > Cheers, > > -Joe > > On 4/26/2017 5:50 PM, Jonathan Gibbons wrote: >> Please review these mostly simple changes to replace HTML tags which >> are not valid in HTML 5 in public doc comments in java.base. >> >> As with the previous changes, the changes were done mechanically, >> using the following sed script: >> >> s|||g >> s|||g >> s|<\\/tt>|<\\/code>|g >> s|\(]*\)>
\([^<]*\)
|\1 >> style="text-align:center">\2| >> s|
> style="margin:0 auto" | >> s||| >> s|> s||| >> >> The unusual form of the 3rd line was to cover the occurrence in a >> makefile. >> >> The 4th line is specific for DataInput.java, and replaces
>> within a
with a style on the element itself. >> >> The 5th and 6th lines are specific to URLConnection. The use of the >> table itself and the ASCII art that follows it are questionable, but >> the intent here is just to update the HTML and not to rework the >> visual appearance of the generated documentation. >> >> The changes cover files in the following packages: >> >> java.base java/io >> java.base java/net >> java.base java/util >> java.base javax/net/ssl >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8179370 >> Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/ >> >> -- Jon > From mandy.chung at oracle.com Thu Apr 27 01:23:06 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 26 Apr 2017 18:23:06 -0700 Subject: RFR: 8179370: Replace use of ,
and tags in java.base In-Reply-To: <5901406F.6080402@oracle.com> References: <5901406F.6080402@oracle.com> Message-ID: <89650C1C-15F8-4413-88B8-0A3E95849501@oracle.com> Looks okay. Mandy > On Apr 26, 2017, at 5:50 PM, Jonathan Gibbons wrote: > > Please review these mostly simple changes to replace HTML tags which are not valid in HTML 5 in public doc comments in java.base. > > As with the previous changes, the changes were done mechanically, using the following sed script: > > s|||g > s|||g > s|<\\/tt>|<\\/code>|g > s|\(]*\)>
\([^<]*\)
|\1 style="text-align:center">\2| > s|
s||| > s| s||| > > The unusual form of the 3rd line was to cover the occurrence in a makefile. > > The 4th line is specific for DataInput.java, and replaces
within a
with a style on the element itself. > > The 5th and 6th lines are specific to URLConnection. The use of the table itself and the ASCII art that follows it are questionable, but the intent here is just to update the HTML and not to rework the visual appearance of the generated documentation. > > The changes cover files in the following packages: > > java.base java/io > java.base java/net > java.base java/util > java.base javax/net/ssl > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8179370 > Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/ > > -- Jon From jonathan.gibbons at oracle.com Thu Apr 27 01:49:11 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 26 Apr 2017 18:49:11 -0700 Subject: RFR: 8179370: Replace use of ,
and tags in java.base In-Reply-To: <590144E0.4050400@oracle.com> References: <5901406F.6080402@oracle.com> <59014195.1070408@oracle.com> <590144E0.4050400@oracle.com> Message-ID: <59014E17.2020802@oracle.com> Updated webrev to address Joe's suggestion to try harder to use {@code} as a substitute for . http://cr.openjdk.java.net/~jjg/8179370/webrev.01 The modified sed script has a new first line: s|\([^&<>]*\)|{@code \1}|g s|||g s|||g s|<\\/tt>|<\\/code>|g s|\(]*\)>
\([^<]*\)
|\1 style="text-align:center">\2| s|
|| s||| Also note that there is a small visible bug in webrev. If you look at ServiceLoader.java:133, the second instance of is not converted to {@code} because the embedded '\' is actually an entity in the source file ... and so it is inappropriate to use {@code} for that instance. -- Jon On 04/26/2017 06:09 PM, Jonathan Gibbons wrote: > Joe, > > Yes, there are occurrences here that require instead of > {@code}, because of the presence of HTML entities. It's about 50/50. > > I'd prefer to stay with mechanical updates as much as possible for > these bulk updates, as compared to manual updates, but I may be able > to improve the sed script for this case. > > -- Jon > > On 04/26/2017 05:55 PM, Joseph D. Darcy wrote: >> Hi Jon, >> >> I'd prefer if the "foo" were replaced with "{@code tt}" >> rather than "foo"- none of the tricky cases which >> preclude use of {@code } use seem to be present here - but will >> approve the changeset in its current form too. >> >> Cheers, >> >> -Joe >> >> On 4/26/2017 5:50 PM, Jonathan Gibbons wrote: >>> Please review these mostly simple changes to replace HTML tags which >>> are not valid in HTML 5 in public doc comments in java.base. >>> >>> As with the previous changes, the changes were done mechanically, >>> using the following sed script: >>> >>> s|||g >>> s|||g >>> s|<\\/tt>|<\\/code>|g >>> s|\(]*\)>
\([^<]*\)
|\1 >>> style="text-align:center">\2| >>> s|
>> style="margin:0 auto" | >>> s||| >>> s|>> s||| >>> >>> The unusual form of the 3rd line was to cover the occurrence in a >>> makefile. >>> >>> The 4th line is specific for DataInput.java, and replaces
>>> within a
with a style on the element itself. >>> >>> The 5th and 6th lines are specific to URLConnection. The use of the >>> table itself and the ASCII art that follows it are questionable, but >>> the intent here is just to update the HTML and not to rework the >>> visual appearance of the generated documentation. >>> >>> The changes cover files in the following packages: >>> >>> java.base java/io >>> java.base java/net >>> java.base java/util >>> java.base javax/net/ssl >>> >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179370 >>> Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/ >>> >>> -- Jon >> > From joe.darcy at oracle.com Thu Apr 27 02:41:08 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 26 Apr 2017 19:41:08 -0700 Subject: RFR: 8179370: Replace use of ,
and tags in java.base In-Reply-To: <59014E17.2020802@oracle.com> References: <5901406F.6080402@oracle.com> <59014195.1070408@oracle.com> <590144E0.4050400@oracle.com> <59014E17.2020802@oracle.com> Message-ID: Looks better; thanks Jon, -Joe On 4/26/2017 6:49 PM, Jonathan Gibbons wrote: > Updated webrev to address Joe's suggestion to try harder to use > {@code} as a substitute for . > > http://cr.openjdk.java.net/~jjg/8179370/webrev.01 > > The modified sed script has a new first line: > > s|\([^&<>]*\)|{@code \1}|g > s|||g > s|||g > s|<\\/tt>|<\\/code>|g > s|\(]*\)>
\([^<]*\)
|\1 > style="text-align:center">\2| > s|
style="margin:0 auto" | > s||| > s| s||| > > Also note that there is a small visible bug in webrev. If you look at > ServiceLoader.java:133, > the second instance of is not converted to {@code} because the > embedded '\' is actually > an entity in the source file ... and so it is inappropriate to use > {@code} for that instance. > > -- Jon > > > > On 04/26/2017 06:09 PM, Jonathan Gibbons wrote: >> Joe, >> >> Yes, there are occurrences here that require instead of >> {@code}, because of the presence of HTML entities. It's about 50/50. >> >> I'd prefer to stay with mechanical updates as much as possible for >> these bulk updates, as compared to manual updates, but I may be able >> to improve the sed script for this case. >> >> -- Jon >> >> On 04/26/2017 05:55 PM, Joseph D. Darcy wrote: >>> Hi Jon, >>> >>> I'd prefer if the "foo" were replaced with "{@code tt}" >>> rather than "foo"- none of the tricky cases which >>> preclude use of {@code } use seem to be present here - but will >>> approve the changeset in its current form too. >>> >>> Cheers, >>> >>> -Joe >>> >>> On 4/26/2017 5:50 PM, Jonathan Gibbons wrote: >>>> Please review these mostly simple changes to replace HTML tags >>>> which are not valid in HTML 5 in public doc comments in java.base. >>>> >>>> As with the previous changes, the changes were done mechanically, >>>> using the following sed script: >>>> >>>> s|||g >>>> s|||g >>>> s|<\\/tt>|<\\/code>|g >>>> s|\(]*\)>
\([^<]*\)
|\1 >>>> style="text-align:center">\2| >>>> s|
>>> style="margin:0 auto" | >>>> s||| >>>> s|>>> s||| >>>> >>>> The unusual form of the 3rd line was to cover the occurrence in a >>>> makefile. >>>> >>>> The 4th line is specific for DataInput.java, and replaces
>>>> within a
with a style on the element itself. >>>> >>>> The 5th and 6th lines are specific to URLConnection. The use of the >>>> table itself and the ASCII art that follows it are questionable, >>>> but the intent here is just to update the HTML and not to rework >>>> the visual appearance of the generated documentation. >>>> >>>> The changes cover files in the following packages: >>>> >>>> java.base java/io >>>> java.base java/net >>>> java.base java/util >>>> java.base javax/net/ssl >>>> >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179370 >>>> Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/ >>>> >>>> -- Jon >>> >> > From Alan.Bateman at oracle.com Thu Apr 27 11:45:48 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 27 Apr 2017 12:45:48 +0100 Subject: RFR: 8179370: Replace use of ,
and tags in java.base In-Reply-To: <59014E17.2020802@oracle.com> References: <5901406F.6080402@oracle.com> <59014195.1070408@oracle.com> <590144E0.4050400@oracle.com> <59014E17.2020802@oracle.com> Message-ID: On 27/04/2017 02:49, Jonathan Gibbons wrote: > Updated webrev to address Joe's suggestion to try harder to use > {@code} as a substitute for . > > http://cr.openjdk.java.net/~jjg/8179370/webrev.01 > The updated version using {@code ... } looks better and also keeps the lines from growing too long. -Alan From weijun.wang at oracle.com Thu Apr 27 14:37:48 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 27 Apr 2017 22:37:48 +0800 Subject: RFR 8179369: src/java.security.jgss/share/classes/org/ietf/jgss/package.html should be HTML5-friendly Message-ID: <625d16c4-66c9-f38d-611d-a9a2c823b5ee@oracle.com> Please review this small doc change: diff --git a/src/java.security.jgss/share/classes/org/ietf/jgss/package.html b/src/java.security.jgss/share/classes/org/ietf/jgss/package.html --- a/src/java.security.jgss/share/classes/org/ietf/jgss/package.html +++ b/src/java.security.jgss/share/classes/org/ietf/jgss/package.html @@ -57,8 +57,7 @@ produces tokens that the application must somehow transport to the other end. -

Credential Acquisition

- +

Credential Acquisition

The GSS-API itself does not dictate how an underlying mechanism obtains the credentials that are needed for authentication. It is assumed that prior to calling the GSS-API, these credentials are Thanks Max From mandy.chung at oracle.com Thu Apr 27 15:03:01 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 27 Apr 2017 08:03:01 -0700 Subject: RFR: 8179370: Replace use of ,
and tags in java.base In-Reply-To: <59014E17.2020802@oracle.com> References: <5901406F.6080402@oracle.com> <59014195.1070408@oracle.com> <590144E0.4050400@oracle.com> <59014E17.2020802@oracle.com> Message-ID: > On Apr 26, 2017, at 6:49 PM, Jonathan Gibbons wrote: > > Updated webrev to address Joe's suggestion to try harder to use {@code} as a substitute for . > > http://cr.openjdk.java.net/~jjg/8179370/webrev.01 Looks good. Mandy From bradford.wetmore at oracle.com Thu Apr 27 18:07:39 2017 From: bradford.wetmore at oracle.com (Brad R. Wetmore) Date: Thu, 27 Apr 2017 11:07:39 -0700 Subject: RFR: 8179370: Replace use of ,
and tags in java.base In-Reply-To: <89650C1C-15F8-4413-88B8-0A3E95849501@oracle.com> References: <5901406F.6080402@oracle.com> <89650C1C-15F8-4413-88B8-0A3E95849501@oracle.com> Message-ID: <80e8a78c-2e83-110f-3ab3-dc0922aba03d@oracle.com> Only comment is updating the copyright dates to 2017. Brad On 4/26/2017 6:23 PM, Mandy Chung wrote: > Looks okay. > Mandy > >> On Apr 26, 2017, at 5:50 PM, Jonathan Gibbons wrote: >> >> Please review these mostly simple changes to replace HTML tags which are not valid in HTML 5 in public doc comments in java.base. >> >> As with the previous changes, the changes were done mechanically, using the following sed script: >> >> s|||g >> s|||g >> s|<\\/tt>|<\\/code>|g >> s|\(]*\)>
\([^<]*\)
|\1 style="text-align:center">\2| >> s|
> s||| >> s|> s||| >> >> The unusual form of the 3rd line was to cover the occurrence in a makefile. >> >> The 4th line is specific for DataInput.java, and replaces
within a
with a style on the element itself. >> >> The 5th and 6th lines are specific to URLConnection. The use of the table itself and the ASCII art that follows it are questionable, but the intent here is just to update the HTML and not to rework the visual appearance of the generated documentation. >> >> The changes cover files in the following packages: >> >> java.base java/io >> java.base java/net >> java.base java/util >> java.base javax/net/ssl >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8179370 >> Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/ >> >> -- Jon > From sean.mullan at oracle.com Thu Apr 27 19:46:48 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 27 Apr 2017 15:46:48 -0400 Subject: RFR 8179369: src/java.security.jgss/share/classes/org/ietf/jgss/package.html should be HTML5-friendly In-Reply-To: <625d16c4-66c9-f38d-611d-a9a2c823b5ee@oracle.com> References: <625d16c4-66c9-f38d-611d-a9a2c823b5ee@oracle.com> Message-ID: Update the copyright date. Otherwise looks fine. --Sean On 4/27/17 10:37 AM, Weijun Wang wrote: > Please review this small doc change: > > diff --git > a/src/java.security.jgss/share/classes/org/ietf/jgss/package.html > b/src/java.security.jgss/share/classes/org/ietf/jgss/package.html > --- a/src/java.security.jgss/share/classes/org/ietf/jgss/package.html > +++ b/src/java.security.jgss/share/classes/org/ietf/jgss/package.html > @@ -57,8 +57,7 @@ > produces tokens that the application must somehow transport to the > other end. > > -

Credential Acquisition

> - > +

Credential Acquisition

> The GSS-API itself does not dictate how an underlying mechanism > obtains the credentials that are needed for authentication. It is > assumed that prior to calling the GSS-API, these credentials are > > Thanks > Max From huizhe.wang at oracle.com Thu Apr 27 20:30:42 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 27 Apr 2017 13:30:42 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: References: Message-ID: <264d057f-2997-960b-9e50-669208f4472a@oracle.com> +1 Joe On 4/27/2017 12:08 PM, Brent Christian wrote: > Hi, > > This test times out under our automated testing configurations that > include -Xcomp. > > Please review my change to increase the timeout for this test. It is > sufficient for the test configurations in question to pass on two > different local machines (Mac & Linux). > > diff -r 7c04ab31b4d6 > test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java > --- a/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java > Wed Apr 26 09:37:23 2017 -0700 > +++ b/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java > Thu Apr 27 12:03:33 2017 -0700 > @@ -29,7 +29,7 @@ > * @library /lib/testlibrary > * @modules java.base/jdk.internal.module > * @build JarUtils CompilerUtils > - * @run main/timeout=240 ClassLoaderTest > + * @run main/timeout=1200 ClassLoaderTest > */ > > Thanks, > -Brent From joe.darcy at oracle.com Thu Apr 27 21:25:04 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 27 Apr 2017 14:25:04 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: References: Message-ID: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> I understand the interest in having test pass reliably, but I don't think giving the test very large timeouts is the preferred way of accomplishing that. For all configurations, the test can now run for up to 20 minutes, up from 4 minutes. We want to run the entire test suite, thousands of tests, in about 20 minutes. The the timeout factor used for Xcomp run, the test would probably now be able to run for over an hour before timing out. I suggest making the test run faster, or seeing if there has been a regressions in Xcomp to make test perform more poorly there. Thanks, -Joe On 4/27/2017 12:08 PM, Brent Christian wrote: > Hi, > > This test times out under our automated testing configurations that > include -Xcomp. > > Please review my change to increase the timeout for this test. It is > sufficient for the test configurations in question to pass on two > different local machines (Mac & Linux). > > diff -r 7c04ab31b4d6 > test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java > --- a/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java > Wed Apr 26 09:37:23 2017 -0700 > +++ b/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java > Thu Apr 27 12:03:33 2017 -0700 > @@ -29,7 +29,7 @@ > * @library /lib/testlibrary > * @modules java.base/jdk.internal.module > * @build JarUtils CompilerUtils > - * @run main/timeout=240 ClassLoaderTest > + * @run main/timeout=1200 ClassLoaderTest > */ > > Thanks, > -Brent From weijun.wang at oracle.com Sat Apr 29 00:44:19 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 29 Apr 2017 08:44:19 +0800 Subject: [10] RFR 8179389: X509Certificate generateCRLs is extremely slow using a PEM crl list Message-ID: <270204c9-c111-6ad7-69e2-8d44b39c8a89@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8179389/webrev.00/ The bug report [1] is correct that the frequent reallocation of data is the problem. This fix above delegate this task to ByteArrayOutputStream. There is no significant performance difference between this fix and the suggested fix in the bug report. The "if (next != 9 && next != 10 && next != 13 && next != 32)" filter is equivalent to replaceAll("\\s+", "") in Pem.decode(). noreg-perf. Thanks Max [1] https://bugs.openjdk.java.net/browse/JDK-8179389 [2] http://web.localhost/%7Eww155710/cgi-bin/hgwebdir.cgi/jdk9/dev/jdk/file/d34833290472/src/java.base/share/classes/sun/security/util/Pem.java#l46 From brent.christian at oracle.com Thu Apr 27 19:08:50 2017 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 27 Apr 2017 19:08:50 -0000 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp Message-ID: Hi, This test times out under our automated testing configurations that include -Xcomp. Please review my change to increase the timeout for this test. It is sufficient for the test configurations in question to pass on two different local machines (Mac & Linux). diff -r 7c04ab31b4d6 test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java --- a/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java Wed Apr 26 09:37:23 2017 -0700 +++ b/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java Thu Apr 27 12:03:33 2017 -0700 @@ -29,7 +29,7 @@ * @library /lib/testlibrary * @modules java.base/jdk.internal.module * @build JarUtils CompilerUtils - * @run main/timeout=240 ClassLoaderTest + * @run main/timeout=1200 ClassLoaderTest */ Thanks, -Brent