On Wed, Jul 12, 2023, 11:31 AM Tim Hollebeek <tim.hollebeek= 40digicert....@dmarc.ietf.org> wrote:
> 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. > I've always said SQI-Sign for this. > > -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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
