Hi Dennis. I did read section 3.2.1 of the draft before posting, but I got the impression that the lexicographically ordered list of log identifiers produced in the "Secondly" step was only intended to be used as a reference in the "Finally" step, rather than emitted as "output".
I understand that "This dictionary is constructed in three stages, with the output of each stage being concatenated with the next", but the only explicit language regarding which artifacts should be emitted as "output" is "Concatenate the byte representation of each extension (including extension id and length) and copy it to the output". It's not clear to me if that explicit language is intended to be part of the "Finally" step only, or if it's intended to apply to all of the steps. My attempt to clarify things: https://github.com/dennisjackson/draft-jackson-tls-cert-abridge/pull/9. ________________________________ From: TLS <tls-boun...@ietf.org> on behalf of Dennis Jackson <ietf=40dennis-jackson...@dmarc.ietf.org> Sent: 14 July 2023 11:30 To: TLS List <tls@ietf.org> Subject: Re: [TLS] Abridged Certificate Compression CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 13/07/2023 10:13, Rob Stradling wrote: How about also including in the shared dictionary the SHA-256 hashes of the public keys of all the known CTv1 logs, so that the 32-byte LogID field of each SCT will be compressed? This is already step 2 of the shared dictionary construction :-) (link<https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.html#section-3.2.1-4>). Best, Dennis FWIW, RFC9162 (CTv2) tackles the same SCT bloat by changing the LogID type from a (32-byte) SHA-256 hash of the log's public key to a (minimum 4-byte) DER-encoded OID (excluding the tag and length octets). ________________________________ From: TLS <tls-boun...@ietf.org><mailto:tls-boun...@ietf.org> on behalf of Tim Hollebeek <tim.hollebeek=40digicert....@dmarc.ietf.org><mailto:tim.hollebeek=40digicert....@dmarc.ietf.org> Sent: 12 July 2023 19:29 To: Kampanakis, Panos <kpanos=40amazon....@dmarc.ietf.org><mailto:kpanos=40amazon....@dmarc.ietf.org>; Dennis Jackson <ietf=40dennis-jackson...@dmarc.ietf.org><mailto:ietf=40dennis-jackson...@dmarc.ietf.org>; TLS List <tls@ietf.org><mailto:tls@ietf.org> Subject: Re: [TLS] Abridged Certificate Compression CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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><mailto: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><mailto:ietf=40dennis-jackson...@dmarc.ietf.org>; > TLS List > <tls@ietf.org><mailto: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><mailto:ietf=40dennis-jackson...@dmarc.ietf.org> > Sent: Wednesday, July 12, 2023 12:39 PM > To: Kampanakis, Panos <kpa...@amazon.com><mailto:kpa...@amazon.com>; TLS List > <tls@ietf.org><mailto: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<mailto:TLS@ietf.org> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7Crob%40sectigo.com%7Cffa69ab58f5c468a8afc08db83062baf%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638247834774528857%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CKut5Ffrs8ytu%2BNt9zuLl47%2F1xv%2BhEEz0lxoAk812k8%3D&reserved=0<https://www.ietf.org/mailman/listinfo/tls> _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7Crob%40sectigo.com%7Cffa69ab58f5c468a8afc08db83062baf%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638247834774528857%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CKut5Ffrs8ytu%2BNt9zuLl47%2F1xv%2BhEEz0lxoAk812k8%3D&reserved=0<https://www.ietf.org/mailman/listinfo/tls> _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
