Re: RFR: 8272162: S4U2Self ticket without forwardable flag [v2]

2021-11-23 Thread Weijun Wang
On Mon, 22 Nov 2021 21:26:05 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> some word changes > > src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line > 69: > >> 67:

Re: RFR: 8272162: S4U2Self ticket without forwardable flag [v2]

2021-11-23 Thread Weijun Wang
> The S4U2proxy extension requires that the service ticket to the first service > has the forwardable flag set, but some versions of Windows Server do not set > the forwardable flag in a S4U2self response and accept it in a S4U2proxy > request. > > There are 2 commits now. The 1st is a refactor

JEP draft: TLS Encrypted ClientHello (ECH)

2021-11-23 Thread Hans-Christoph Steiner
The next revision of the IETF-standardized TLS protocol is known as Encrypted ClientHello (ECH) [0] formerly known as Encrypted SNI (ESNI). There is a related standard DNS RR Type known as SVCB or HTTPS [8]. ECH is built on top of TLSv1.3 and completes unfinished work from the TLSv1.3 effort

Re: RFR: 8276660: Scalability bottleneck in java.security.Provider.getService()

2021-11-23 Thread Andrey Turbanov
On Tue, 23 Nov 2021 02:55:55 GMT, Valerie Peng wrote: > It is observed that when running crypto benchmark with large number of > threads, a lot of time is spent on the synchronized block inside the > Provider.getService() method. The cause for this is that > Provider.getService() method first

Re: RFR: 8276660: Scalability bottleneck in java.security.Provider.getService()

2021-11-23 Thread Andrey Turbanov
On Tue, 23 Nov 2021 02:55:55 GMT, Valerie Peng wrote: > It is observed that when running crypto benchmark with large number of > threads, a lot of time is spent on the synchronized block inside the > Provider.getService() method. The cause for this is that > Provider.getService() method first