JEP Review Request: TLS Certificate Compression

[Bernd Eckenfels]

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.

(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> im Auftrag von Daniel Jeliński <djelinski1 at gmail.com>
Gesendet: Wednesday, April 13, 2022 10:01:29 PM
An: xueleifan(XueleiFan) <xueleifan at tencent.com>
Cc: OpenJDK Dev list <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>
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/0c73a9fb/attachment.htm>