> The performance benefit isn't purely in the ~1KB saved, its whether it brings > the chain under the QUIC amplification limit or shaves off an additional > packet and so avoids a loss+retry. There's essentially no difference in > implementation complexity, literally just a line of code, so the main > tradeoff is the required disk space on the client & server.
Fair. I would add one more tradeoff which is pulling the end-entity certs in the CT window for pass 2. This is an one time cost for each dictionary version, so maybe not that bad. Regardless, would compressing the leaf bring us below the QUIC 3.6KB threshold for Dilithium 2 or 3 certs whereas not suppressing would keep us above? I think it is not even close if we are talking WebPKI. Without SCTs, maybe compressing could keep us below 4KB for Dilithium 2 leaf certs. But even then, if we add the CertVerify signature size we will be well over 4KB. Additionally, would compressing the leaf bring us below the 9-10KB threshold that Bas had tested to be an important inflection point? For WebPKI, it may the 8-9KB cert below 9KB if we add the CertVerify signature size. Maybe not. It would need to tested. For Dilithium 3, maybe compression could render the 11-12KB cert below 9KB if we got lucky, maybe not, but if we add the CertVerify signature we won’t make it. For non-WebPKI, they will already be below 9-10KB. So, I am arguing that we can't remain below the QUIC threshold by compressing the leaf Dilithium cert. And we could remain below the 9-10KB only for Dilithium2 leaves. I could be proven wrong if you have implemented it. One more argument for making pass 2 optional or allowing for just pass 1 dictionaries is that if we are not talking about WebPKI we don't have the luxury of CT logs. But we would still want to option of compressing / omitting the ICAs by using CCADB. -----Original Message----- From: Dennis Jackson <ietf=40dennis-jackson...@dmarc.ietf.org> Sent: Wednesday, July 12, 2023 12:39 PM To: Kampanakis, Panos <kpa...@amazon.com>; TLS List <tls@ietf.org> Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On 12/07/2023 04:34, Kampanakis, Panos wrote: > Thanks Dennis. Your answers make sense. > > Digging a little deeper on the benefit of compressing (a la Abridged > Certs draft) the leaf cert or not. Definitely this draft improves vs > plain certificate compression, but I am trying to see if it is worth > the complexity of pass 2. So, section 4 shows a 2.5KB improvement over > plain compression which would be even more significant for Dilithium > certs, but I am trying to find if the diff between ICA > suppression/Compression vs ICA suppression/Compression+leaf > compression is significant. [/n] > > I am arguing that the table 4 numbers would be much different when > talking about Dilithium certs because all of these numbers would be > inflated and any compression would have a small impact. Replacing a CA > cert (no SCTs) with a dictionary index would save us ~4KB (Dilithium2) > or 5.5KB (Dilithium3). That is significant. [/n] > > Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB (Dilithium 3)) > using any mechanism would trim down ~0.5-1KB compared to not compressing. > That is because the PK and Sig can't be compressed and these account for most > of the PQ leaf cert size. So, I am trying to see if pass 2 and compression of > the leaf cert benefit us much. I think there's a fairly big difference between suppressing CA certs in SCA and compressing CA certs with pass 1 of this draft. But I do agree its fair to ask if pass 2 is worth the extra effort. The performance benefit isn't purely in the ~1KB saved, its whether it brings the chain under the QUIC amplification limit or shaves off an additional packet and so avoids a loss+retry. There's essentially no difference in implementation complexity, literally just a line of code, so the main tradeoff is the required disk space on the client & server. Best, Dennis _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
