from:"xueleifan\(XueleiFan\)"

Re: [Internet]Re: Re: JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16)

2022-05-13 Thread xueleifan(XueleiFan)

Would you mind send the debug log information, with System property 
javax.net.debug=all?

Thanks,
Xuelei

> On May 13, 2022, at 8:27 AM, xueleifan(XueleiFan)  
> wrote:
> 
> Hm, I get a hint about the issue now.  Did SunJSSE provider used in both 
> client and server?
> 
> Xuelei
> 
>> On Apr 26, 2022, at 7:36 AM, Thomas Lußnig  wrote:
>> 
>> Hi,
>> 
>> i changed the logging and now better get the Location of the error
>> 
>> javax.crypto.BadPaddingException: Insufficient buffer remaining for AEAD 
>> cipher fragment (2). Needs to be more than tag size (16)
>>at 
>> java.base/sun.security.ssl.SSLCipher$T13GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1898)
>>at 
>> java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:239)
>>at 
>> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:196)
>>at 
>> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:159)
>>at 
>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
>>at 
>> java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736)
>>at 
>> java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691)
>>at 
>> java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506)
>>at 
>> java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482)
>>at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:679)
>>at 
>> org.eclipse.jetty.io.ssl.SslConnection.unwrap(SslConnection.java:406)
>> 
>> 
>> Gruß Thomas
>> 
>> 
>

Re: [Internet]Re: JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16)

2022-05-13 Thread xueleifan(XueleiFan)

Hm, I get a hint about the issue now.  Did SunJSSE provider used in both client 
and server?

Xuelei

> On Apr 26, 2022, at 7:36 AM, Thomas Lußnig  wrote:
> 
> Hi,
> 
> i changed the logging and now better get the Location of the error
> 
> javax.crypto.BadPaddingException: Insufficient buffer remaining for AEAD 
> cipher fragment (2). Needs to be more than tag size (16)
> at 
> java.base/sun.security.ssl.SSLCipher$T13GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1898)
> at 
> java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:239)
> at 
> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:196)
> at 
> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:159)
> at 
> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
> at 
> java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736)
> at 
> java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691)
> at 
> java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506)
> at 
> java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482)
> at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:679)
> at 
> org.eclipse.jetty.io.ssl.SslConnection.unwrap(SslConnection.java:406)
> 
> 
> Gruß Thomas
> 
>

Re: [Internet]Re: Reproducer for JDK-8221218

2022-05-13 Thread xueleifan(XueleiFan)

Ping …

Is there a link to the "How to reproduce” information?

Thanks,
Xuelei

On Apr 26, 2022, at 7:16 AM, xueleifan(XueleiFan) 
mailto:xuelei...@tencent.com>> wrote:

I will have a look at it.  I may need help for more information.


On Apr 25, 2022, at 7:45 AM, Flavia Rainone 
mailto:frain...@redhat.com>> wrote:

Hi everyone,

I work with the XNIO ( https://github.com/xnio/xnio/ ) project, led by David 
Lloyd in CC.

I'm not sure if this is the best way to get in touch, but I could not find out 
how to create an account for OpenJDK Jira to add a comment there.

We have a reproducer for JDK-8221218, and it appears it is not solved yet 
(tested with jdk 11.0.12). It is not intermittent, and it happens when we try 
to do an SSLEngine.unwrap with a zero remaining() ByteBuffer (in older 
versions, the engine would just return a BUFFER_UNDERFLOW result).


It is expected to check the remaining before reading the packet.  Is there a 
working closing thread while unwrap() is in progress?  Did you have the debug 
log (-Djavax.net<http://djavax.net/>.debug=all) and the exception stacks that I 
can refer to?

It would be nice if JDK 17 or 18 get checked as well.

You can see more information about this here: 
https://issues.redhat.com/browse/XNIO-406

To reproduce the issue, just follow the steps in "How to reproduce" using JDK11 
and add a breakpoint at this line:
https://github.com/xnio/xnio/pull/282/commits/2ae0c1b368c6e0886f9c03030ec443c346cb0a71#diff-9f162fd704e4d5eaff8abb932a923ae868adf3f642d85bc6f5bcfd5f7fe1763bR695


Is there a link to "How to reproduce”?

Thanks,
Xuelei


Or you can simply open the test output file to view the exception: 
xnio/nio-impl/target/surefire-reports/org.xnio.nio.test.NioSslTcpChannelTestCase-output.txt
 (but then you have to comment out the XNIO-406 workaround above)

Notice that there are other failures with XNIO testsuite related to JDK11 and 
newer, as tracked by another Jira (XNIO-347), but they seem to be unrelated to 
this issue, hence why the mvn clean install -DskipTests in the reproduce steps.

Branch of choice should be 3.8

Since I won't be around for the next few days, Richard Opalka in CC will follow 
up with you.


Best regards,

--
Flavia Rainone
Principal Software Engineer

Red Hat<https://www.redhat.com/>

frain...@redhat.com<mailto:frain...@redhat.com>

[https://static.redhat.com/libs/redhat/brand-assets/2/corp/logo--200.png]<https://www.redhat.com/>

Interesting in TLS Ticket Requests

2022-05-02 Thread xueleifan(XueleiFan)

Hi,


A new standard, RFC 9149 TLS Ticket Requests, was published on April 2022. Is 
anyone interested in have it implemented in JDK?

As described in RFC 8446/TLS 1.3, TLS servers vend clients an arbitrary number 
of session tickets for session resumption.  However, the number may be not what 
clients desired.  For security reason, session ticket can be used only one 
time.  If the client desired number and server supplied number does not match, 
the performance impact could be significant.

Currently, in JDK, the server vends only one session ticket for each 
handshaking.  However, clients can open parallel TLS connections to the same 
server for HTTP, or they can race TLS connections across different network 
interfaces.  In such circumstances, one session ticket is hardly to be good for 
TLS connections performance.  But, without an explicit desired number requested 
from the client, it is hard to know what is the best number of session tickets 
that the server should vend to clients.  The issues could be addressed with RFC 
9149, TLS Ticket Requests.

Are you interested to have the TLS Ticket Requests feature in JDK?  Please let 
me know your ideas and concerns.

Thanks,
Xuelei

Interesting in DTLS 1.3

2022-05-02 Thread xueleifan(XueleiFan)

Hi,

The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 (DTLS 1.3) 
has been published on April 2022. 
The specification describes the most current version of the DTLS protocol as a 
delta from TLS 1.3 and obsoletes DTLS 1.2.

In JDK, the Java specifications for DTLS 1.0 and DTLS 1.2 are 
defined
 and 
implemented.
 For DTLS 1.3, there may be three different choices for JDK.

The 1st one is doing nothing, and JDK will not support DTLS 1.3 in the future.

The 2nd one is define the specification in JDK, but without the implementation. 
 Third party’s provider could have the implementation if this feature is 
required in some circumstances.

The 3rd one, as DTLS 1.0 and DTLS 1.2, is to have an implementation in JDK.

Are you using DTLS protocols in your applications?  Is anyone interested in 
have DTLS 1.3 in JDK? Which option is best for you?

Thanks,
Xuelei

Re: [Internet]Re: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4 [v2]

2022-04-26 Thread xueleifan(XueleiFan)

With this update, is the purpose of this PR changed?  The bug subject and 
description may need an update.

Xuelei

> On Apr 26, 2022, at 9:02 AM, Weijun Wang  wrote:
> 
>> Compare encoded instead of decoded digest in RSA signature verification.
> 
> Weijun Wang has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>  only check digest value
> 
> -
> 
> Changes:
>  - all: https://git.openjdk.java.net/jdk/pull/8365/files
>  - new: https://git.openjdk.java.net/jdk/pull/8365/files/a8499bb3..09188779
> 
> Webrevs:
> - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8365&range=01
> - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8365&range=00-01
> 
>  Stats: 37 lines in 2 files changed: 33 ins; 3 del; 1 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/8365.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8365/head:pull/8365
> 
> PR: https://git.openjdk.java.net/jdk/pull/8365
>

Re: [Internet]Re: JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16)

2022-04-26 Thread xueleifan(XueleiFan)

Is it the same problem as discussed in this thread: 
https://mail.openjdk.java.net/pipermail/security-dev/2022-April/030129.html

Xuelei

On Apr 26, 2022, at 7:36 AM, Thomas Lußnig 
mailto:open...@suche.org>> wrote:

Hi,

i changed the logging and now better get the Location of the error

javax.crypto.BadPaddingException: Insufficient buffer remaining for AEAD cipher 
fragment (2). Needs to be more than tag size (16)
at 
java.base/sun.security.ssl.SSLCipher$T13GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1898)
at 
java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:239)
at 
java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:196)
at 
java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:159)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
at 
java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736)
at 
java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691)
at 
java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506)
at 
java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482)
at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:679)
at org.eclipse.jetty.io.ssl.SslConnection.unwrap(SslConnection.java:406)


Gruß Thomas

Re: [Internet]Reproducer for JDK-8221218

2022-04-26 Thread xueleifan(XueleiFan)

I will have a look at it. I may need help for more information.

On Apr 25, 2022, at 7:45 AM, Flavia Rainone
mailto:frain...@redhat.com>> wrote:

Hi everyone,

I work with the XNIO ( https://github.com/xnio/xnio/ ) project, led by David
Lloyd in CC.

I'm not sure if this is the best way to get in touch, but I could not find out
how to create an account for OpenJDK Jira to add a comment there.

We have a reproducer for JDK-8221218, and it appears it is not solved yet
(tested with jdk 11.0.12). It is not intermittent, and it happens when we try
to do an SSLEngine.unwrap with a zero remaining() ByteBuffer (in older
versions, the engine would just return a BUFFER_UNDERFLOW result).

It is expected to check the remaining before reading the packet. Is there a
working closing thread while unwrap() is in progress? Did you have the debug
log (-Djavax.net.debug=all) and the exception stacks that I
can refer to?

It would be nice if JDK 17 or 18 get checked as well.

You can see more information about this here:
https://issues.redhat.com/browse/XNIO-406

To reproduce the issue, just follow the steps in "How to reproduce" using JDK11
and add a breakpoint at this line:
https://github.com/xnio/xnio/pull/282/commits/2ae0c1b368c6e0886f9c03030ec443c346cb0a71#diff-9f162fd704e4d5eaff8abb932a923ae868adf3f642d85bc6f5bcfd5f7fe1763bR695

Is there a link to "How to reproduce”?

Thanks,
Xuelei

Or you can simply open the test output file to view the exception:
xnio/nio-impl/target/surefire-reports/org.xnio.nio.test.NioSslTcpChannelTestCase-output.txt
(but then you have to comment out the XNIO-406 workaround above)

Notice that there are other failures with XNIO testsuite related to JDK11 and
newer, as tracked by another Jira (XNIO-347), but they seem to be unrelated to
this issue, hence why the mvn clean install -DskipTests in the reproduce steps.

Branch of choice should be 3.8

Since I won't be around for the next few days, Richard Opalka in CC will follow
up with you.

Best regards,

--
Flavia Rainone
Principal Software Engineer

Red Hat

frain...@redhat.com

[https://static.redhat.com/libs/redhat/brand-assets/2/corp/logo--200.png]

JDK-8221218 is not yet fixed

2022-04-24 Thread xueleifan(XueleiFan)


Hi Thomas,

Did you have reproducing code that I could play with?

Thanks,
Xuelei

Re: [Internet]JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16)

2022-04-24 Thread xueleifan(XueleiFan)

Hi Thomas,

Did you have a reproducing code that I would play with?

Thanks,

Xuelei

On Apr 24, 2022, at 2:01 PM, Thomas Lußnig 
mailto:open...@suche.org>> wrote:

Hi,

i like to inform you that this problem is not yet fixed. I Use java 18.0.1 and 
the problem still popup.
OS: Win 11
openjdk 18 2022-03-22
OpenJDK Runtime Environment (build 18+36-2087)
OpenJDK 64-Bit Server VM (build 18+36-2087, mixed mode, sharing)

Espacialy under larger load.

Gruß Thomas

java.io.IOException: javax.net.ssl.SSLException: Insufficient buffer remaining 
for AEAD cipher fragment (2). Needs to be more than tag size (16)

at org.eclipse.jetty.util.FutureCallback.block(FutureCallback.java:163)
at 
org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint.sendBlocking(JettyWebSocketRemoteEndpoint.java:224)
at 
org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint.sendString(JettyWebSocketRemoteEndpoint.java:85)
   ...
Caused by: javax.net.ssl.SSLException: Insufficient buffer remaining for AEAD 
cipher fragment (2). Needs to be more than tag size (16)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:134)
at 
java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736)
at 
java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691)
at 
java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506)
at 
java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482)
at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:679)
at org.eclipse.jetty.io.ssl.SslConnection.unwrap(SslConnection.java:406)
at 
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:701)
at 
org.eclipse.jetty.websocket.core.internal.WebSocketConnection.fillAndParse(WebSocketConnection.java:470)
... 16 more
Suppressed: java.io.IOException: Broken pipe
at 
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.flush(SslConnection.java:1118)
at 
org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:417)
at 
org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:272)
at 
org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:418)
at 
org.eclipse.jetty.websocket.core.internal.FrameFlusher.process(FrameFlusher.java:329)
at 
org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:232)
at 
org.eclipse.jetty.util.IteratingCallback.succeeded(IteratingCallback.java:350)
at 
org.eclipse.jetty.util.Callback$Nested.succeeded(Callback.java:314)
at 
org.eclipse.jetty.io.WriteFlusher.completeWrite(WriteFlusher.java:389)
at 
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint$IncompleteWriteCallback.succeeded(SslConnection.java:1562)
at 
org.eclipse.jetty.io.WriteFlusher.completeWrite(WriteFlusher.java:389)
at 
org.eclipse.jetty.io.SocketChannelEndPoint$2.run(SocketChannelEndPoint.java:116)
... 8 more

Re: [Internet]Re: JEP Review Request: TLS Certificate Compression

2022-04-13 Thread xueleifan(XueleiFan)

On Apr 13, 2022, at 2:07 PM, Bernd Eckenfels 
mailto:e...@zusammenkunft.net>> wrote:

Hello,

For multiple connections session- or ticket reuse would be much more efficient.

In fact I think cert compression looks like the wrong solution. Having a 
immutable certificate download Chain would be a cool alternative solution - 
especially with future large postquantumcrypto certificates. That’s also easy 
to cache.

I agreed, it would be cool as well if the certificate chain could be cached in 
the DNS record.

Thanks,
Xuelei

(But I recon that’s not for this list to discuss, it’s just an argument against 
implementing a draft standard)

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

Von: security-dev 
mailto:security-dev-r...@openjdk.java.net>> 
im Auftrag von Daniel Jeliński 
mailto:djelins...@gmail.com>>
Gesendet: Wednesday, April 13, 2022 10:01:29 PM
An: xueleifan(XueleiFan) mailto:xuelei...@tencent.com>>
Cc: OpenJDK Dev list 
mailto:security-dev@openjdk.java.net>>
Betreff: Re: JEP Review Request: TLS Certificate Compression

I like the idea of implementing certificate compression. Only one
concern: TLS handshakes are generally a CPU-intensive operation, and
certificate compression / decompression will only make it worse. Will
it be possible to compress a certificate once and use it across
multiple handshakes? Decompression has to be performed every time,
obviously.

Regards,
Daniel

pon., 21 mar 2022 o 16:49 xueleifan(XueleiFan) 
mailto:xuelei...@tencent.com>>
napisał(a):
>
> Hi,
>
>
> The JDK Enhancement Proposal, TLS Certificate Compression, has been opened 
> for community review.  Detailed, please refer to the draft:
>
> https://bugs.openjdk.java.net/browse/JDK-8281710
>
> and the discussion of this potential feature at security-dev:
>
> 
> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html
>
>
> Please feel free to make comments and review the JEP.
>
> Thanks,
> Xuelei

Re: [Internet]Re: JEP Review Request: TLS Certificate Compression

2022-04-13 Thread xueleifan(XueleiFan)

Hi Daniel,

Actually, I’m considering the improvement, by using cached compressed 
certificates, for the implementation.  The solution is not straightforward yet 
to me.  But it is a direction I will consider seriously.

Thanks,
Xuelei

> On Apr 13, 2022, at 1:01 PM, Daniel Jeliński  wrote:
> 
> I like the idea of implementing certificate compression. Only one
> concern: TLS handshakes are generally a CPU-intensive operation, and
> certificate compression / decompression will only make it worse. Will
> it be possible to compress a certificate once and use it across
> multiple handshakes? Decompression has to be performed every time,
> obviously.
> 
> Regards,
> Daniel
> 
> pon., 21 mar 2022 o 16:49 xueleifan(XueleiFan) 
> napisał(a):
>> 
>> Hi,
>> 
>> 
>> The JDK Enhancement Proposal, TLS Certificate Compression, has been opened 
>> for community review.  Detailed, please refer to the draft:
>> 
>>https://bugs.openjdk.java.net/browse/JDK-8281710
>> 
>> and the discussion of this potential feature at security-dev:
>> 
>>
>> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html
>> 
>> 
>> Please feel free to make comments and review the JEP.
>> 
>> Thanks,
>> Xuelei
>

Re: [Internet]Re: JEP Review Request: TLS Certificate Compression

2022-04-13 Thread xueleifan(XueleiFan)

Ping …

Xuelei

> On Mar 24, 2022, at 1:05 PM, Sean Mullan  wrote:
> 
> 
> 
> On 3/21/22 11:49 AM, xueleifan(XueleiFan) wrote:
>> Hi,
>> 
>> 
>> The JDK Enhancement Proposal, TLS Certificate Compression, has been opened 
>> for community review.  Detailed, please refer to the draft:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8281710
> 
> Or a more readable version at https://openjdk.java.net/jeps/8281710
> 
> --Sean
> 
>> 
>> and the discussion of this potential feature at security-dev:
>> 
>> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html
>> 
>> 
>> Please feel free to make comments and review the JEP.
>> 
>> Thanks,
>> Xuelei
> 
>

Re: [Internet]Re: RFR: 8284415: Collapse identical catch branches in security libs

2022-04-06 Thread xueleifan(XueleiFan)

I think it is a good point, Mike.  Some of the exception constructors do not 
accept cause parameters, for example UnrecoverableKeyException.  And some 
others do, for example InvalidKeyException.  I would like to keep original 
cause.  I read this patch as a format clean-up. It is fine to me to have an 
additional update to take the causes back.  But I appreciate if Andrey could 
take care of the update in the PR as well.

Xuelei

> On Apr 6, 2022, at 10:43 AM, Mike StJohns  wrote:
> 
> Before you approve this, why would you rethrow just the message rather than 
> the actual original cause? Seems like you’re losing debug info including the 
> type of the original exception for no good reason.
> 
> Mike
> 
> Sent from my iPad
> 
>> On Apr 6, 2022, at 11:26, Xue-Lei Andrew Fan  wrote:
>> 
>> On Fri, 1 Apr 2022 07:32:21 GMT, Andrey Turbanov  
>> wrote:
>> 
>>> Let's take advantage of Java 7 language feature - "Catching Multiple 
>>> Exception Types".
>>> It simplifies code. Reduces duplication.
>>> Found by IntelliJ IDEA inspection `Identical 'catch' branches in 'try' 
>>> statement`
>> 
>> Looks good to me.
>> 
>> -
>> 
>> Marked as reviewed by xuelei (Reviewer).
>> 
>> PR: https://git.openjdk.java.net/jdk/pull/8068
> 
>

Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA

2022-03-29 Thread xueleifan(XueleiFan)



> On Mar 29, 2022, at 10:18 AM, Anders Rundgren  
> wrote:
> 
> On 2022-03-28 21:57, xueleifan(XueleiFan) wrote:
>> Thank you for the information and discussion, Anders, Bernd and Mike.  I had 
>> a better understand of JOSE/COSE and the problems.
> 
> Thanx Xuelei!
> May I ask a highly related question?
> 
> Assume there is a new cool XYZ algorithm family supported by a third party 
> JCE provider.
> What would be needed in order to make XYZ public keys in X.509 certificates 
> automatically decode into an associated XYXPublicKey (also supplied by the 
> third party)?
> 
It depends.  For the JDK X509 certificate implementation, KeyFactory are used  
to generated the public key from X509 encoded key specification (public key DER 
value in the cert).

X509EncodedKeySpec x509KeySpec
= new X509EncodedKeySpec(x509EncodedKeyStream.toByteArray());
KeyFactory keyFac = KeyFactory.getInstance(algid.getName());
keyFac.generatePublic(x509KeySpec);

The “algid” is also recorded in the X.509 certificate.  So, a third party 
provider may be able to get it supported by support XYZ algorithm in its 
KeyFactory implementation.

KeyFactory keyFac = KeyFactory.getInstance(“XYZ”/“XYZ-OID”);

But it really depends on the X.509 provider implementation behaviors.  I know 
there are cases that X.509 provider was updated, or forked, here and there in 
order to support new algorithms, unfortunately.

Best,
Xuelei


> I tried to follow the JDK X.509 decoder source but I failed :(
> 
> Regards,
> Anders
> 
>> For the crypto implementation, for example Ed25519 in the SunEC provider, I 
>> would prefer to keep the footprint in OpenJDK as minimal as possible.  For 
>> example, the Ed25519 key factory could accept XECPublicKeySpec and 
>> XECPrivateKeySpec only, and support no more encoding format (currently, 
>> X509EncodedKeySpec and PKCS8EncodedKeySpec are also supported by the SunEC 
>> provider).  Except COSE/JOSE/PEM, there may be a few other known encoding 
>> formats, and more in the future.  It would be challenging to track many 
>> encoding formats in specific protocols and their development in OpenJDK.  If 
>> a provider does not support protocol specific format, the application rely 
>> on it could fail, which is not good for application developers.  And thus 
>> the purpose to support more encoding format in one provider could be 
>> frangible.
>> There could be third party's encoding format specific provider, for example 
>> a KeyFactory provider accepting JOSE/COSE format and converting between 
>> XECPublicKeySpec/XECPrivateKeySpec and protocol specific formats.  The 
>> factory might belong more to the protocol specific library, rather than the 
>> OpenJDK reference implementation. Unfortunately, the current 
>> KeyFactory.getInstance(“ Ed25519”) design cannot identify the encoding 
>> formats, and thus may just return a provider that does not support the 
>> expected encoding format.  It might be a workaround to use different 
>> algorithm name, like “JOSE/Ed25519”.
>> Alternatively, the JOSE/COSE could transfer the encoded stream to 
>> XECPublicKeySpec and XECPrivateKeySpec, without using KeyFactory.  It may be 
>> transparent to application developers if the transferring is wrapped in the 
>> protocol specific lib.
>> Just my $.02.
>> Xuelei
>>> On Mar 28, 2022, at 2:30 AM, Bernd Eckenfels >> <mailto:e...@zusammenkunft.net>> wrote:
>>> 
>>> Hello,
>>> 
>>> I think both might be too protocol specific to include it in JCE, but a 
>>> library for JWK would fit into JWT support in Jakarta EE.
>>> 
>>>  For COSE the key descriptors are very simple (no certificates), not sure 
>>> if anything besides a cose library is really needed. (That library would 
>>> benefit from a curve registry, but since cose uses

Re: [Internet]Re: Re: "Pluggable" key serialization in JCE/JCA

2022-03-28 Thread xueleifan(XueleiFan)

Thank you for the information and discussion, Anders, Bernd and Mike.  I had a 
better understand of JOSE/COSE and the problems.

For the crypto implementation, for example Ed25519 in the SunEC provider, I 
would prefer to keep the footprint in OpenJDK as minimal as possible.  For 
example, the Ed25519 key factory could accept XECPublicKeySpec and 
XECPrivateKeySpec only, and support no more encoding format (currently, 
X509EncodedKeySpec and PKCS8EncodedKeySpec are also supported by the SunEC 
provider).  Except COSE/JOSE/PEM, there may be a few other known encoding 
formats, and more in the future.  It would be challenging to track many 
encoding formats in specific protocols and their development in OpenJDK.  If a 
provider does not support protocol specific format, the application rely on it 
could fail, which is not good for application developers.  And thus the purpose 
to support more encoding format in one provider could be frangible.

There could be third party's encoding format specific provider, for example a 
KeyFactory provider accepting JOSE/COSE format and converting between 
XECPublicKeySpec/XECPrivateKeySpec and protocol specific formats.  The factory 
might belong more to the protocol specific library, rather than the OpenJDK 
reference implementation. Unfortunately, the current KeyFactory.getInstance(“ 
Ed25519”) design cannot identify the encoding formats, and thus may just return 
a provider that does not support the expected encoding format.  It might be a 
workaround to use different algorithm name, like “JOSE/Ed25519”.

Alternatively, the JOSE/COSE could transfer the encoded stream to 
XECPublicKeySpec and XECPrivateKeySpec, without using KeyFactory.  It may be 
transparent to application developers if the transferring is wrapped in the 
protocol specific lib.

Just my $.02.

Xuelei

On Mar 28, 2022, at 2:30 AM, Bernd Eckenfels 
mailto:e...@zusammenkunft.net>> wrote:

Hello,

I think both might be too protocol specific to include it in JCE, but a library 
for JWK would fit into JWT support in Jakarta EE.

 For COSE the key descriptors are very simple (no certificates), not sure if 
anything besides a cose library is really needed. (That library would benefit 
from a curve registry, but since cose uses its own code values for the curve 
access to the CurveDB would not help I think).

CBOR is not QR specific, it’s specific for the Covid Vaccination Certificate 
framework (due to the QR code size restriction it can’t use JSON).

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

Von: Anthony Scarpino 
mailto:anthony.scarp...@oracle.com>>
Gesendet: Monday, March 28, 2022 6:31:29 AM
An: Anders Rundgren 
mailto:anders.rundgren@gmail.com>>
Cc: Bernd Eckenfels mailto:e...@zusammenkunft.net>>; 
security-dev@openjdk.java.net 
mailto:security-dev@openjdk.java.net>>
Betreff: Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA

Thanks for all the info. We don’t have experience with JOSE or COSE, I think we 
need to digest some of this data before making a future step

Not knowing this technology until you brought it up a few days ago, a few 
questions i have are how is this used and how common?  Would I see this used 
for more secure sites like banks or shopping through the browser or it more 
common sites. Is it only browser-based or are their other used cases?  Bernd 
mentioned QR codes, is COSE used inside the QR code or the authentication for 
the user to get to their QR code?

Thanks

Tony

> On Mar 26, 2022, at 11:48 PM, Anders Rundgren 
> mailto:anders.rundgren@gmail.com>> wrote:
>
> On 2022-03-26 23:14, Bernd Eckenfels wrote:
>> Just for completeness, the standard for key transport in JOSE is JWK 
>> (RFC7517).
>> In COSE it is a COSE_Key(Set) as defined in RFC8152 sect13.
>> BTW the most widely used CBOR/COSE application are probably the QR codes 
>> around Covid and Vaccination certificates of the EU.
>
> Thanx Bernd and Michael for the additional clarifications!
>
> Now to the thing that spurred this discussion: 
> https://datatracker.ietf.org/doc/html/rfc8037
>
>   This document defines how to use the Diffie-Hellman algorithms
>   "X25519" and "X448" as well as the signature algorithms "Ed25519" and
>   "Ed448" from the IRTF CFRG elliptic curves work in JSON Object
>   Signing and Encryption (JOSE).
>
> When RFC 8037 was created the assumption was that the "OKP" key container 
> {sh|c}ould be used for other crypto systems having the same parameter set.  
> This is now an active proposal:
> https://www.ietf.org/archive/id/draft-looker-cose-bls-key-representations-00.html
>
> Obviously everything works just fine if you look at the container in 
> isolation. However, it means that "OKP" encoder/decoder code must be updated 
> for every new reuse ("overloading").  To be meaningful these new algorithms 
> would also have to coerced into the existing XEC or EdDSA interfaces.
>
> IMO, this would be VERY UNFORTUNA

Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA

2022-03-26 Thread xueleifan(XueleiFan)

Hi Anders,

I would like to have look at the COSE/JOSE specs.  If it is convenient to you, 
any suggestions about where I could start from? RFC 8812?  Do you know where 
(areas and products) the COSE/JOSE specs are used in practice?

Thanks,
Xuelei

> On Mar 25, 2022, at 11:56 AM, Anders Rundgren  
> wrote:
> 
> Hi Michael & the JDK crypto team,
> 
> Although it might be cool writing a JEP it is not really my job.  There are 
> also multiple ways of addressing this issue.
> 
> BTW, the COSE/JOSE folks who are about to introduce new algorithms want to 
> overload RFC 8037 which defines a key type OKP.
> I'm not in favor of this idea since breaks existing OKP code.
> I'm suggesting that each new crypto system should get its own name space and 
> thus long-term corresponding Java interfaces.
> 
> Since this is happening NOW and there is no turning back, it would be useful 
> to get some early feedback from the JDK folks.  In fact, this is the origin 
> of this request.
> 
> It seems that nobody representing JDK crypto is involved in COSE/JOSE.
> 
> Thanx,
> Anders
> 
> 
> On 2022-03-25 18:23, Michael StJohns wrote:
>> On 3/25/2022 12:33 PM, Anders Rundgren wrote:
>>> On 2022-03-25 17:12, Anthony Scarpino wrote:
 When you say "construct and EC key", do you mean creating an EC key from
 an existing set of values via PKCS8 or X509 encoding?  Or are you
 talking about EC key generation?
>>> 
>>> I was talking about creating keys from parameter data supplied by for
>>> example JOSE:
>>>   {
>>> "kty": "EC",
>>> "crv": "P-256",
>>> "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU",
>>> "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg"
>>>   }
>>> 
>>> Apparently this particular issue have solution (as Michael StJohns
>>> showed), although it is not particularity intuitive as well as
>>> undocumented.
>>> 
>>> Another take on this issue:
>>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded()
>>> 
>>> "Returns the key in its primary encoding format, or null if this key
>>> does not support encoding"
>>> 
>>> With COSE/JOSE there is no longer an obvious primary encoding format.
>> Of course there is.  You may not like that it's not COSE or JOSE, but
>> the encoding spec remains as is and 10s of 1000s of implementations that
>> use that encoding would be annoyed if you tried to claim a new "primary
>> encoding format".
>> The SubjectPublicKeyInfo encoding for PublicKeys, the PKCS8 encoding for
>> private keys, and RAW encoding for SecretKeys is what's there and I'm
>> pretty sure won't change.  I occasionally wished for a getEncoded()
>> method that took an encoding type as an argument (e.g.
>> getEncoded("bareXY") or some such), but that's not in the API.
>> What I'd suggest is that you write a JEP for adding EncodedKeySpec
>> classes for COSE and JOSE to the API.   I'd probably also add a
>> GenericKeyEncodingSpec class.  That should be simple enough as a first step.
>> The second step would be to write and contribute a Jose and Cose
>> KeyFactory implementation that uses those classes.
>> As I noted, it should be possible to externalize any preferred encoding
>> by using the getKeySpec method of KeyFactory rather than just the key
>> types default encoding.
>> Later, Mike
>>> 
>>> Anders
>>> 
 
 Tony
> 
>

Re: [Internet]"Pluggable" key serialization in JCE/JCA

2022-03-24 Thread xueleifan(XueleiFan)


> On Mar 23, 2022, at 11:46 PM, Anders Rundgren  
> wrote:
> 
> Hi List,
> 
> I find it a bit strange that every user of crypto either have to write or 
> install specific software for converting JOSE/COSE/PEM keys back-and-forth to 
> Java's internal representation. This reduces the value of the abstract types 
> as well.
> 
> Now there is whole bunch of new algorithms coming to the Java platform making 
> this task even less attractive.
> 
> So my question is simply: How about including this part in an enhanced 
> JCE/JCA?  That is, making the encoder/decoder "pluggable" and hiding this 
> complexity from users and library developers?
> 
> Eventually you could end up with something like:
> 
> PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or stream);
> 
> You would not even have to know in which format the key is supplied in since 
> this could be accomplished by simple "sniffing".
> 

If I understand the proposal correctly, it may be challenging in the current 
JCA/JCE framework, especially for interoperability, unless one just wants to 
work with one provider only.  A third provider need to understand the private 
key spec so that it can work with it.  It may be doable by defining the export 
method accordingly, but again it will run into the problem you concerned about 
“converting the keys back-and-forth”.

Xuelei


> To make "pluggability" feasible, I'm trying to convince the JOSE/COSE folks 
> to give each new crypto system a separate namespace as an alternative to 
> overloading OKP (RFC 8037), even if the parameters match technically.  
> AFAICT, X.509 public keys essentially already adhere to this notion.
> 
> I would exclude private key import and export in HSMs since these are 
> specific and rare occasions.
> 
> WDYT?
> 
> Thanx,
> Anders
>

JEP Review Request: TLS Certificate Compression

2022-03-21 Thread xueleifan(XueleiFan)

Hi,


The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for 
community review.  Detailed, please refer to the draft:

https://bugs.openjdk.java.net/browse/JDK-8281710

and the discussion of this potential feature at security-dev:

https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html


Please feel free to make comments and review the JEP.

Thanks,
Xuelei

Re: [Internet]Re: Proposal for potential new feature: TLS Certificate Compression

2022-03-14 Thread xueleifan(XueleiFan)

Hi Jamil,

Thank you for the support of this proposal. I am happy to move on to the next
JEP process if no objections or comments in the coming weeks.

Hi All,

Please let me know if more time is required for the review of the proposal.

Thanks,
Xuelei

On Mar 11, 2022, at 7:25 AM, Jamil Nimeh
mailto:jamil.j.ni...@oracle.com>> wrote:

Hi Xuelei,

After reading over your descriptions and the supporting documentation this
certainly seems like it would be a nice addition to JSSE. It definitely seems
like a performance win for QUIC and also for bandwidth-constrained devices.
I'm all for seeing this JEP proceed. I'll likely have more comments down the
line and I have taken a look at the proposed code changes and will go back and
do a deeper dive on it. I just don't want to jump any of the JEP process hoops
by talking about code changes before some of the important first steps for the
JEP have been cleared. But you've got my support on this one!

--Jamil

On 3/7/2022 11:46 AM, xueleifan(XueleiFan) wrote:
Hi,

The TLS Certificate Compression standard was described in RFC 8879, and has
been enabled in browser Chrome and Safari. What’s TLS Certificate Compression
and what’s the benefits of this feature?

For TLS connections, a client must authenticate the identity of the server.
This typically involves verification that the identity of the server is
included in a certificate and that the certificate is issued by a trusted
entity.

Where servers provide certificates for authentication, the size of the
certificate chain can consume a large number of bytes. Controlling the size of
certificate chains is critical to performance and security in QUIC. TLS
certificate compression has the potential to ameliorate the attacks/problems by
reducing the size of the handshakes to a size compatible with the security
restriction. The TLS Certificate Compression feature is an essential part for
QUIC-TLS protocols.

For more details, please refer to section 4.4 in RFC 9001 (Using TLS to Secure
QUIC):
-
Note: Where servers provide certificates for authentication, the size of the
certificate chain can consume a large number of bytes. Controlling the size of
certificate chains is critical to performance in QUIC as servers are limited to
sending 3 bytes for every byte received prior to validating the client address;
see Section 8.1 of [QUIC-TRANSPORT]. The size of a certificate chain can be
managed by limiting the number of names or extensions; using keys with small
public key representations, like ECDSA; or by using certificate compression
[COMPRESS].

and a more detailed description in the blog “Does the QUIC handshake require
compression to be
fast?”(https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study).
I just copy part of the conclusion section of the bog here for your quick
reference.
-
First, the TLS certificate compression extension has a very large impact on
QUIC performance. Even though the extension is new and being introduced fairly
late in the process when compared to overall QUIC deployment schedules, it
seems quite important for both clients and servers to implement the new
extension so that the QUIC handshake can live up to its billing. Without some
help, 40% of QUIC full handshakes would be no better than TCP, but compression
can repair most of that issue. I have heard of other non-standardized
approaches to reducing the size of the certificate chain, and they seem
reasonable, but this is a problem worth addressing immediately with the
existing compression extension.
...
Lastly, data from the real world again proves to be more insightful than
intuition and is invaluable in making protocol design and implementation
decisions. When I started this work I expected the impact of compression to be
positive but marginally focused on a few edge cases. The data shows this
optimization lands right on the sweet spot that ties configurations and the
QUIC specification together and impacts a large portion of QUIC handshakes. My
thanks to the authors of the compression extension.
-

Besides, reducing the amount of information exchanged during a TLS handshake to
a minimum helps to improve performance in environments, for example Internet of
Things, where devices are connected to a network with a low bandwidth and lossy
radio technology.

This feature is a part to improve the performance of TLS connections, and it is
also a part of the path towards QUIC standards.

Chrome support TLS certificate compression with Brotil compression algorithm,
and Safari support TLS certificate compression with Zlib compression algorithm.

In a summary, JDK could benefits from supporting RFC 8879 in the following
areas:

Performance - Reduce latency and improve performance of TLS and QUIC
connections by support the TLS certificate compression standard in JDK.
Security - Mitigate the impac

Re: [Internet]Need a reviewer for CSR: JDK-8282768

2022-03-08 Thread xueleifan(XueleiFan)

The CSR looks good to me, and I added my name as reviewer.

Xuelei

> On Mar 7, 2022, at 1:38 PM, Bradford Wetmore  
> wrote:
> 
> 
> Hi,
> 
> We (zzambers/I) need a reviewer for this CSR involving the close @apiNote of 
> SSLSocket.java:
> 
>https://bugs.openjdk.java.net/browse/JDK-8282768
>Fix API Note in javadoc for javax.net.ssl.SSLSocket
> 
> The original bug JDK-8282529[1] is/has been discussed in these threads 
> [2][3], and has this pull request[4].
> 
> Brad
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8282529
> [2] 
> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029132.html
> [3] 
> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029163.html
> [4] https://github.com/openjdk/jdk/pull/7648
> 
> 
>

Proposal for potential new feature: TLS Certificate Compression

2022-03-07 Thread xueleifan(XueleiFan)

Hi,

The TLS Certificate Compression standard was described in RFC 8879, and has
been enabled in browser Chrome and Safari. What’s TLS Certificate Compression
and what’s the benefits of this feature?

and a more detailed description in the blog “Does the QUIC handshake require
compression to be
fast?”(https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study

).
I just copy part of the conclusion section of the bog here for your quick
reference.
-
First, the TLS certificate compression extension has a very large impact on
QUIC performance. Even though the extension is new and being introduced fairly
late in the process when compared to overall QUIC deployment schedules, it
seems quite important for both clients and servers to implement the new
extension so that the QUIC handshake can live up to its billing. Without some
help, 40% of QUIC full handshakes would be no better than TCP, but compression
can repair most of that issue. I have heard of other non-standardized
approaches to reducing the size of the certificate chain, and they seem
reasonable, but this is a problem worth addressing immediately with the
existing compression extension.
...
Lastly, data from the real world again proves to be more insightful than
intuition and is invaluable in making protocol design and implementation
decisions. When I started this work I expected the impact of compression to be
positive but marginally focused on a few edge cases. The data shows this optimi
zation lands right on the sweet spot that ties configurations and the QUIC
specification together and impacts a large portion of QUIC handshakes. My
thanks to the authors of the compression extension.
-

This feature is a part to improve the performance of TLS connections, and it is
also a part of the path towards QUIC standards.

Chrome support TLS certificate compression with Brotil compression algorithm,
and Safari support TLS certificate compression with Zlib compression algorithm.

In a summary, JDK could benefits from support RFC 8879 in the following areas:

Performance - Reduce latency and improve performance of TLS and QUIC
connections by support the TLS certificate compression standard in JDK.
Security - Mitigate the impact of amplification attacks threat by reducing
the size of the TLS handshakes with compressed certificates.

What do you think? Do you want it to be a part of OpenJDK? Please feel free
to share you comments.

Thanks,
Xuelei

Re: [Internet]Re: Re: JEP Review Request: TLS Certificate Compression

2022-03-07 Thread xueleifan(XueleiFan)

Thank you for the suggestion, Sean.

Hi all, please discuss the proposal in the new thread: 
   https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html

Xuelei

> On Mar 7, 2022, at 10:16 AM, Sean Mullan  wrote:
> 
> Hi Xuelei,
> 
> Please start this discussion in a new thread with a new subject (ex: Proposal 
> for potential new feature: TLS Certificate Compression) as it should be 
> evaluated on its own prior to reaching consensus and deciding if a JEP should 
> be drafted.
> 
> Also, keep in mind that it may take a few days or longer for members of the 
> Security Group and other interested participants to find time to review new 
> proposals for significant features.
> 
> Thanks,
> Sean
> 
> On 2/28/22 3:33 PM, xueleifan(XueleiFan) wrote:
>> Hi,
>> It may be better to have more detail here, rather than refer you to the 
>> draft JEP.  The first question maybe, if TLS Certificate Compression is 
>> something we want it in OpenJDK?
>> The TLS Certificate Compression standard was described in RFC 8879, and has 
>> been enabled in browser Chrome and Safari. But, what’s TLS Certificate 
>> Compression and what’s the benefits of this feature?
>> For TLS connections, a client must authenticate the identity of the server. 
>> This typically involves verification that the identity of the server is 
>> included in a certificate and that the certificate is issued by a trusted 
>> entity.
>> Where servers provide certificates for authentication, the size of the 
>> certificate chain can consume a large number of bytes. Controlling the size 
>> of certificate chains is critical to performance and security in QUIC. TLS 
>> certificate compression has the potential to ameliorate the attacks/problems 
>> by reducing the size of the handshakes to a size compatible with the 
>> security restriction.  The TLS Certificate Compression feature is an 
>> essential part for QUIC-TLS protocols.
>> For more details, please refer to section 4.4 in RFC 9001 (Using TLS to 
>> Secure QUIC):
>> -
>> Note: Where servers provide certificates for authentication, the size of the 
>> certificate chain can consume a large number of bytes. Controlling the size 
>> of certificate chains is critical to performance in QUIC as servers are 
>> limited to sending 3 bytes for every byte received prior to validating the 
>> client address; see Section 8.1 of [QUIC-TRANSPORT]. The size of a 
>> certificate chain can be managed by limiting the number of names or 
>> extensions; using keys with small public key representations, like ECDSA; or 
>> by using certificate compression [COMPRESS].¶
>> -
>> and a more detailed description in the blog “Does the QUIC handshake require 
>> compression to be 
>> fast?”(https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study
>>  
>> <https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study>).
>>I just copy part of the conclusion section of the bog here for your quick 
>> reference.
>> -
>> First, the TLS certificate compression extension has a very large impact on 
>> QUIC performance. Even though the extension is new and being introduced 
>> fairly late in the process when compared to overall QUIC deployment 
>> schedules, it seems quite important for both clients and servers to 
>> implement the new extension so that the QUIC handshake can live up to its 
>> billing. Without some help, 40% of QUIC full handshakes would be no better 
>> than TCP, but compression can repair most of that issue. I have heard of 
>> other non-standardized approaches to reducing the size of the certificate 
>> chain, and they seem reasonable, but this is a problem worth addressing 
>> immediately with the existing compression extension.
>> ...
>> Lastly, data from the real world again proves to be more insightful than 
>> intuition and is invaluable in making protocol design and implementation 
>> decisions. When I started this work I expected the impact of compression to 
>> be positive but marginally focused on a few edge cases. The data shows this 
>> optimization lands right on the sweet spot that ties configurations and the 
>> QUIC specification together and impacts a large portion of QUIC handshakes. 
>> My thanks to the authors of the compression extension.
>> -
>> Besides, reducing the amount of information exchanged during a TLS handshake 
>> to a minimum helps to improve performance in environments, for example 
>> Internet of Things, where devices are connected to a network with a low 
&g

Proposal for potential new feature: TLS Certificate Compression

2022-03-07 Thread xueleifan(XueleiFan)

Hi,

The TLS Certificate Compression standard was described in RFC 8879, and has
been enabled in browser Chrome and Safari. What’s TLS Certificate Compression
and what’s the benefits of this feature?

This feature is a part to improve the performance of TLS connections, and it is
also a part of the path towards QUIC standards.

Chrome support TLS certificate compression with Brotil compression algorithm,
and Safari support TLS certificate compression with Zlib compression algorithm.

In a summary, JDK could benefits from supporting RFC 8879 in the following
areas:

What do you think? Do you want it a part of OpenJDK? Please feel free to
share you comments.

Thanks,
Xuelei

Re: [Internet]Re: [External] : Re: Recent SSLSocket close() @apiNote Changes.

2022-03-05 Thread xueleifan(XueleiFan)

> http://cr.openjdk.java.net/~wetmore/8282529/webrev.00
I was wondering if the mixing of half-close and duplex-close could work as 
well, by adjusting the implementation code.  It could be easier for developers. 
 But your spec update looks good to me, even if we allow the three-lines 
closure.

Thanks,
Xuelei




On Mar 4, 2022, at 4:46 PM, Bradford Wetmore 
mailto:bradford.wetm...@oracle.com>> wrote:


On 3/2/2022 11:46 PM, xueleifan(XueleiFan) wrote:

I think you are right that this design is actually for TLSv1.3 half-close mode. 
 For TLS 1.3,  there is no duplex closure design.  The close() implementation 
in JDK is actually a workaround for compatibility.  Application can use either 
the half-close mode
  socket.shutdownOutput();
  socket.shutdownInput();
or duplex close mode for compatibilty:
  socket.close();
Unfortunately, in practice the half-close and duplex close are mixed with three 
lines:
  socket.shutdownOutput();
  socket.shutdownInput();
  socket.close();

Yeah, I've seen that in things like Apache HttpClient Core, which has 
subsequently been removed.

How about something like this:

http://cr.openjdk.java.net/~wetmore/8282529/webrev.00/

Thanks,

Brad



It was not something I expected when I designed the spec for half-close mode.  
It should be helpful if having another iteration for the @apiNote.
Thanks,
Xuelei
On Mar 2, 2022, at 5:14 PM, Bradford Wetmore  
wrote:


Hi Xuelei,

I am working on some close code including the recent PR[1] for:

   8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket

and ran into a change I hadn't noticed before.

* @apiNote
* When the connection is no longer needed, the client and server
* applications should each close both sides of their respective connection.
* For {@code SSLSocket} objects, for example, an application can call
* {@link Socket#shutdownOutput()} for output stream close and call
* {@link Socket#shutdownInput()} for input stream close.

It used to be that just a single SSLSocket.close() was sufficient to completely 
shutdown the SSLSocket, and under the hood it closed the output/input in the 
right order.

I believe this code still closes everything as before, but the updated @apiNote 
encourages the user to do a three-part shutdown instead.

  socket.shutdownOutput();
  socket.shutdownInput();
  socket.close();// mostly repeats of above.

This approach seems unnecessary unless the user is interested in the TLSv1.3 
half-close mode.

What is the rationale for recommending this way of doing closes in general?  Or 
does this @apiNote need another iteration?

Thanks,

Brad

[1] 
https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/7648__;!!ACWV5N9M2RV99hQ!cHw7i1wGs-eyCPUcrFXtAdFiUZL6aCPUGpGEQ9u56HHSuwew1j6YHapR8sSefEwr7TRXKQ$

Re: [Internet]Recent SSLSocket close() @apiNote Changes.

2022-03-02 Thread xueleifan(XueleiFan)

Hi Brad,

I think you are right that this design is actually for TLSv1.3 half-close mode. 
 For TLS 1.3,  there is no duplex closure design.  The close() implementation 
in JDK is actually a workaround for compatibility.  Application can use either 
the half-close mode
  socket.shutdownOutput();
  socket.shutdownInput();

or duplex close mode for compatibilty:
  socket.close();

Unfortunately, in practice the half-close and duplex close are mixed with three 
lines:
  socket.shutdownOutput();
  socket.shutdownInput();
  socket.close();

It was not something I expected when I designed the spec for half-close mode.  
It should be helpful if having another iteration for the @apiNote.

Thanks,
Xuelei


> On Mar 2, 2022, at 5:14 PM, Bradford Wetmore  
> wrote:
> 
> 
> Hi Xuelei,
> 
> I am working on some close code including the recent PR[1] for:
> 
>8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
> 
> and ran into a change I hadn't noticed before.
> 
> * @apiNote
> * When the connection is no longer needed, the client and server
> * applications should each close both sides of their respective connection.
> * For {@code SSLSocket} objects, for example, an application can call
> * {@link Socket#shutdownOutput()} for output stream close and call
> * {@link Socket#shutdownInput()} for input stream close.
> 
> It used to be that just a single SSLSocket.close() was sufficient to 
> completely shutdown the SSLSocket, and under the hood it closed the 
> output/input in the right order.
> 
> I believe this code still closes everything as before, but the updated 
> @apiNote encourages the user to do a three-part shutdown instead.
> 
>   socket.shutdownOutput();
>   socket.shutdownInput();
>   socket.close();// mostly repeats of above.
> 
> This approach seems unnecessary unless the user is interested in the TLSv1.3 
> half-close mode.
> 
> What is the rationale for recommending this way of doing closes in general?  
> Or does this @apiNote need another iteration?
> 
> Thanks,
> 
> Brad
> 
> [1] https://github.com/openjdk/jdk/pull/7648
>

Re: [Internet]Re: JEP Review Request: TLS Certificate Compression

2022-02-28 Thread xueleifan(XueleiFan)

Hi,

It may be better to have more detail here, rather than refer you to the draft
JEP. The first question maybe, if TLS Certificate Compression is something we
want it in OpenJDK?

The TLS Certificate Compression standard was described in RFC 8879, and has
been enabled in browser Chrome and Safari. But, what’s TLS Certificate
Compression and what’s the benefits of this feature?

...

Lastly, data from the real world again proves to be more insightful than
intuition and is invaluable in making protocol design and implementation
decisions. When I started this work I expected the impact of compression to be
positive but marginally focused on a few edge cases. The data shows this
optimization lands right on the sweet spot that ties configurations and the
QUIC specification together and impacts a large portion of QUIC handshakes. My
thanks to the authors of the compression extension.
-

This feature is a part to improve the performance of TLS connections, and it is
also a part of the path towards QUIC standards.

Chrome support TLS certificate compression with Brotil compression algorithm,
and Safari support TLS certificate compression with Zlib compression algorithm.

In a summary, JDK could benefits from support RFC 8879 in the following areas:

Please feel free to share you comments, if it is something we want in OpenJDK?

Thanks,
Xuelei

On Feb 28, 2022, at 10:57 AM, xueleifan(XueleiFan)
mailto:xuelei...@tencent.com>> wrote:

Hi,

Could I have this JEP reviewed? One or more qualified Committers review is
required to move it forward.

Here is the PR if you want to have a further look at the implementation and
test:
https://github.com/openjdk/jdk/pull/7599

Thanks,
Xuelei

On Feb 15, 2022, at 9:30 PM, xueleifan(XueleiFan)
mailto:xuelei...@tencent.com>> wrote:

Hi all,

The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for
community review. Detailed, please refer to the draft:

https://bugs.openjdk.java.net/browse/JDK-8281710

Feel free to make

Re: JEP Review Request: TLS Certificate Compression

2022-02-28 Thread xueleifan(XueleiFan)

Hi,

Could I have this JEP reviewed?  One or more qualified Committers review is 
required to move it forward.

Here is the PR if you want to have a further look at the implementation and 
test:
https://github.com/openjdk/jdk/pull/7599

Thanks,
Xuelei

On Feb 15, 2022, at 9:30 PM, xueleifan(XueleiFan) 
mailto:xuelei...@tencent.com>> wrote:

Hi all,

The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for 
community review.  Detailed, please refer to the draft:

https://bugs.openjdk.java.net/browse/JDK-8281710

Feel free to make comment and send your feedback to the alias.  I may submit 
this JEP in the beginning of next week if I hear no objections by the end of 
this week.

Thanks,
Xuelei

JEP Review Request: TLS Certificate Compression

2022-02-16 Thread xueleifan(XueleiFan)

Hi all,

The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for 
community review.  Detailed, please refer to the draft:

https://bugs.openjdk.java.net/browse/JDK-8281710

Feel free to make comment and send your feedback to the alias.  I may submit 
this JEP in the beginning of next week if I hear no objections by the end of 
this week.

Thanks,
Xuelei

Re: [Internet]Re: Re: JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16)

Re: [Internet]Re: JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16)

Re: [Internet]Re: Reproducer for JDK-8221218

Interesting in TLS Ticket Requests

Interesting in DTLS 1.3

Re: [Internet]Re: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4 [v2]

Re: [Internet]Re: JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16)

Re: [Internet]Reproducer for JDK-8221218

JDK-8221218 is not yet fixed

Re: [Internet]JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16)

Re: [Internet]Re: JEP Review Request: TLS Certificate Compression

Re: [Internet]Re: JEP Review Request: TLS Certificate Compression

Re: [Internet]Re: JEP Review Request: TLS Certificate Compression

Re: [Internet]Re: RFR: 8284415: Collapse identical catch branches in security libs

Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA

Re: [Internet]Re: Re: "Pluggable" key serialization in JCE/JCA

Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA

Re: [Internet]"Pluggable" key serialization in JCE/JCA

JEP Review Request: TLS Certificate Compression

Re: [Internet]Re: Proposal for potential new feature: TLS Certificate Compression

Re: [Internet]Need a reviewer for CSR: JDK-8282768

Proposal for potential new feature: TLS Certificate Compression

Re: [Internet]Re: Re: JEP Review Request: TLS Certificate Compression

Proposal for potential new feature: TLS Certificate Compression

Re: [Internet]Re: [External] : Re: Recent SSLSocket close() @apiNote Changes.

Re: [Internet]Recent SSLSocket close() @apiNote Changes.

Re: [Internet]Re: JEP Review Request: TLS Certificate Compression

Re: JEP Review Request: TLS Certificate Compression

JEP Review Request: TLS Certificate Compression

29 matches

Site Navigation

Mail list logo

Footer information