Hi Dennis, Spinning up a new thread since this is a different topic.
Section 5.1 talks about the dictionary versioning approach and suggests an annual cadence is enough. The issue of an up-to-date cache was a big concern for the ICA Suppression draft, and rightfully so. A stale dictionary does not cause an outage in the abridged case, but it does eliminate the benefit. Appendix B.1 talks about 100-200 new ICA and 10 Root certs per year. In the past I had looked at fluctuations of CCADB and there are daily changes. When checking in the past, I did not generate the ordered list as per pass 1 on a daily basis to confirm it, but I confirmed the fluctuations. The commits in https://github.com/FiloSottile/intermediates/commits/main show it too. Given that, I am wondering if CCADB is not that stable. Are you confident that ICA dictionaries (based on CCADB) won't materially change often? -----Original Message----- From: TLS <tls-boun...@ietf.org> On Behalf Of Kampanakis, Panos Sent: Tuesday, July 11, 2023 11:34 PM To: Dennis Jackson <ietf=40dennis-jackson...@dmarc.ietf.org>; Dennis Jackson <i...@dennis-jackson.uk>; 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. 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. 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. 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. Where I am going with this is that if the benefit of leaf compression from the Abridged Mechanism is not significant, I would like to use your abridged dictionary for ICA suppression only because it does not suffer from outages. So, am I wrong in claiming that compressing a Dilithium leaf cert compared to sending it as-is saves us a lot of data? If MTCs came to fruition I think they would do pretty well without the abridged certs, but the abridged certs have the advantage that they can be implemented for WebPKI or elsewhere which is important. -----Original Message----- From: Dennis Jackson <ietf=40dennis-jackson...@dmarc.ietf.org> Sent: Monday, July 10, 2023 7:23 AM To: Kampanakis, Panos <kpa...@amazon.com>; Dennis Jackson <i...@dennis-jackson.uk>; 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. Hi Panos, On 08/07/2023 02:49, Kampanakis, Panos wrote: > Hi Dennis, > > This is an interesting draft. Thanks! > The versioned dictionary idea for ICA and Root CAs especially was something I > was considering for the ICA Suppression draft [1] given the challenges > brought up before about outages with stale dictionary caches. > > Btw, if we isolated the ICA and Root CA dictionary, I don't think you need > pass 1, assuming the parties can agree on a dictionary version. They could > just agree on the dictionary and be able to build the cert chain, but > providing the identifiers probably simplifies the process. This could be > simplified further I think. Ah I hadn't seen, thank you for the link to [1]. I thought a bit about suppressing pass 1 as well but I don't think its desirable. A key selling point of the current Abridged Certs draft is that it can be enabled by default without the risk of connection failures or requiring retries, even if the server / client fall out of date. This keeps the deployment story very simple as you can just turn it on knowing it can only make things better and never make things worse. Suppressing Pass 1 could be used to reduce the storage requirements on the server but then the server wouldn't know whether a particular ICA was in the dictionary and so the operator would have to configure that, leading to the same kind of error handling flows as in the CA Cert Suppression draft. Similarly, the bytes on the wire saving isn't significant and it would make it harder to use Abridged Certs in other contexts as it would no longer be a lossless compression scheme. > I also think one thing missing from the draft is how the client negotiates > this compression with the server as the CertificateCompressionAlgorithms from > RFC8879 will not be the same. Sorry I'm afraid I don't follow. Abridged Certs would negotiated just the same as any other certificate compression algorithm. The client indicates support by including the Abridged Certs identifier in its Certificate Compression extension in the ClientHello (along with the existing algorithms like plain Zstd). The server has the choice of whether to use it in its CompressedCertificate message. If a new version of Abridged Certs were minted in a few years with newer dictionaries then it would have its own algorithm identifier and would coexist with or replace the existing one. > About the end-entity compression, I wonder if compression, decompression > overhead is significant and unbalanced. RFC8879 did not want to introduce a > DoS threat by offering a cumbersome compression/decompression. Any data on > that? Abridged Certs is just a thin wrapper around Zstd which is already deployed as TLS Certificate Compression algorithm, so the same considerations apply. According to Facebook's numbers [ZSTD], decompression is more than 4x faster than Brotli and insensitive to the compression level used. TLS Certificate Compression schemes aren't sensitive to compression speed as it can be done once and cached at startup, but I ran a benchmark [COMPARE] using both the maximum and minimal Zstd compression levels and the outcome was within 100 bytes, so servers wanting to do just-in-time compression can use a minimal level without difficulty. I hope to have some proper benchmarks using a Rust implementation by the end of the week. > About your data in section 4, I think these are classical cert chains and it > looks to be they improve 0.5-1KB from RFC8879 compression. They are classical cert chains but I think you might be misreading the table. The improvement over regular TLS Certificate Compression is 1KB at the 5th percentile, 2.2 KB at the 50th percentile and 2.5 KB at the 95th percentile. > In a WebPKI Dilithium2 cert with 2 SCTs the end-entity cert size will amount > to ~7-8KB. 85% of that will be the "random" Dilithium public key and > signatures which will not get much compression. So, do we get any benefit > from compressing 7-8KB certs to 6-7KB? Is it worth the > compression/decompression effort? A 2.5 KB saving gives back a whole Dilithium2 signature, which I think is fair to say is substantial. The overall size of a PQ end-entity cert is still uncertain and may not be as large as your calculation. If proofs of inclusion were used instead of SCTs, as suggested in Merkle Tree Certs [MTC], then each SCT-equivalent would be under 1 KB. Abridged Certs would then be saving around 2.5 KB of a 6 KB certificate, fitting the entire chain in roughly 4KB. So we'd be shipping a full PQ cert chain without any size inflation on today's uncompressed classical chains. Best, Dennis [ZSTD] https://github.com/facebook/zstd [COMPARE] https://gist.github.com/dennisjackson/e1dccfef104cabc1e4151c47338bc9b2 [MTC] https://davidben.github.io/merkle-tree-certs/draft-davidben-tls-merkle-tree-certs.html > > -----Original Message----- > From: TLS <tls-boun...@ietf.org> On Behalf Of Dennis Jackson > Sent: Thursday, July 6, 2023 6:18 PM > To: TLS List <tls@ietf.org> > Subject: [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. > > > > Hi all, > > I've submitted the draft below that describes a new TLS certificate > compression scheme that I'm calling 'Abridged Certs' for now. The aim is to > deliver excellent compression for existing classical certificate chains and > smooth the transition to PQ certificate chains by eliminating the root and > intermediate certificates from the bytes on the wire. It uses a shared > dictionary constructed from the CA certificates listed in the CCADB [1] and > the associated extensions used in end entity certificates. > > Abridged Certs compresses the median certificate chain from ~4000 to > ~1000 bytes based on a sample from the Tranco Top 100k. This beats > traditional TLS certificate compression which produces a median of ~3200 > bytes when used alone and ~1400 bytes when combined with the outright removal > of CA certificates from the certificate chain. The draft includes a more > detailed evaluation. > > There were a few other key considerations. This draft doesn't impact trust > decisions, require trust in the certificates in the shared dictionary or > involve extra error handling. Nor does the draft favor popular CAs or > websites due to the construction of the shared dictionary. Finally, most > browsers already ship with a complete list of trusted intermediate and root > certificates that this draft reuses to reduce the client storage footprint to > a few kilobytes. > > I would love to get feedback from the working group on whether the draft is > worth developing further. > > For those interested, a few issues are tagged DISCUSS in the body of the > draft, including arrangements for deploying new versions with updated > dictionaries and the tradeoff between equitable CA treatment and the disk > space required on servers (currently 3MB). > > Best, > Dennis > > [1] Mozilla operates the Common CA Database on behalf of Apple, Microsoft, > Google and other members. > > On 06/07/2023 23:11, internet-dra...@ietf.org wrote: >> A new version of I-D, draft-jackson-tls-cert-abridge-00.txt >> has been successfully submitted by Dennis Jackson and posted to the >> IETF repository. >> >> Name: draft-jackson-tls-cert-abridge >> Revision: 00 >> Title: Abridged Compression for WebPKI Certificates >> Document date: 2023-07-06 >> Group: Individual Submission >> Pages: 19 >> URL: >> https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/ >> Html: >> https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.html >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-jackson-tls-cert-abridge >> >> >> Abstract: >> This draft defines a new TLS Certificate Compression scheme which >> uses a shared dictionary of root and intermediate WebPKI >> certificates. The scheme smooths the transition to post-quantum >> certificates by eliminating the root and intermediate certificates >> from the TLS certificate chain without impacting trust negotiation. >> It also delivers better compression than alternative proposals whilst >> ensuring fair treatment for both CAs and website operators. It may >> also be useful in other applications which store certificate chains, >> e.g. Certificate Transparency logs. >> >> >> >> >> The IETF Secretariat >> >> > _______________________________________________ > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
