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

[xueleifan(XueleiFan)]

On Apr 13, 2022, at 2:07 PM, Bernd Eckenfels <ecki at zusammenkunft.net<mailto:ecki at 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 <security-dev-retn at openjdk.java.net<mailto:security-dev-retn at openjdk.java.net>> im Auftrag von Daniel Jeliński <djelinski1 at gmail.com<mailto:djelinski1 at gmail.com>>
Gesendet: Wednesday, April 13, 2022 10:01:29 PM
An: xueleifan(XueleiFan) <xueleifan at tencent.com<mailto:xueleifan at tencent.com>>
Cc: OpenJDK Dev list <security-dev at openjdk.java.net<mailto:security-dev at 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) <xueleifan at tencent.com<mailto:xueleifan at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220413/b2783718/attachment.htm>