SCTs have always seemed surprisingly large to me, and it has always seemed like there should be a more compact representation that has the same security properties, but I've never found the time to look more closely at it. If someone does have the time, figuring out how to reduce the size of SCTs would be quite helpful.
-Tim > -----Original Message----- > From: TLS <tls-boun...@ietf.org> On Behalf Of Kampanakis, Panos > Sent: Wednesday, July 12, 2023 2:23 PM > To: Dennis Jackson <ietf=40dennis-jackson...@dmarc.ietf.org>; TLS List > <tls@ietf.org> > Subject: Re: [TLS] Abridged Certificate Compression > > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
