Re: [TLS] Abridged Certificate Compression
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 On Behalf Of Dennis Jackson Sent: Thursday, July 6, 2023 6:18 PM To: TLS List Subject
Re: [TLS] Abridged Certificate Compression
On 07/07/2023 21:28, Eric Rescorla wrote: S 3.2.1 How much value are you getting from the CT logs? It seems like additional complexity. I agree with your comment about having this submitted to CCADB. It seemed the fairest repeatable way to check whether a CA was offering certificates to WebPKI clients without having to write a lot of emails. I agree its not desirable to keep as a dependency in the long run. Can you elaborate on the concern here? I.e., is it that we will overinclude or underinclude if we just use CCADB? Sorry, this answer came out garbled. Using CT gives two things: 1) There are large extensions in end-entity certs which are specific to the issuer and change little between certs. For example, the URLs for OCSP, CRL and the practice statement are typically the same. Using CT logs lets me pull out an example of each extension for that CA without having to write a bunch of mails to ask them to produce them in the right format. 2) I don't personally have concerns about the dictionary size and would prefer to include every CA. However, if someone were to have strong feelings about this then using CT to measure popularity is much fairer than say scanning popular domains from the Tranco list or whatever. In the long term, I hope this could just be removed and ideally the CA's themselves provide a fixed size binary blob via CCADB that they'd like compressed out of their certs. Best, Dennis Thanks, -Ekr S 5.1. ISTM that there are plenty of code points available. Thanks! Best, Dennis On Thu, Jul 6, 2023 at 3:18 PM Dennis Jackson wrote: 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 dic
Re: [TLS] Abridged Certificate Compression
On Thu, Jul 06, 2023 at 11:18:01PM +0100, Dennis Jackson wrote: > 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. What does "Note that the connection will fail regardless even if this step is not taken as neither certificate validation nor transcript validation can succeed." mean? TLS certificate compression does not do anything special with transcript, so transcript validation should always succeed. And are there zstd decoders that can reuse output buffer in oneshot decompression for lookback? The zstd command line tool manual page mentions default 128MB memory limit for decompression. I presume mostly for lookback. Such limit is way too large. And an alternative idea: The compressed stream is concatenation of two kinds of certificate entries: 1) If certificate is not found in dictionary: opaque zstd_compressed_cert<1..16711679>; opaque extensions<0..65535>; Where if next certificate in chain is also not found, zstd uses empty dictionary. Otherwise it uses dictionary associated with the next certificate in chain. 2) If certificate is found in dictionary: uint8 always_0xff = 255; uint16 dictionary_index; opaque extensions<0..65535>; The overall length is not compressed, because compressed_certificate message already has it. This allows dictionaries to be specific to CA, avoiding tradeoffs between CAs. As illustration, minimal compressed certificate message for certificate issued by Let's Encrypt E1: - 4 byte message header. - 2 byte compression algorithm. - 3 byte uncompressed length. - 3 byte length of EE certificate. - X byte zstd compressed certificate using dictionary for Let's Encrypt E1. - 2 byte extension block length. - 0 byte extension block. - 3 byte entry for Let's Encrypt E1. - 2 byte extension block length. - 0 byte extension block. - 3 byte entry for ISRG Root X2. - 2 byte extension block length. - 0 byte extension block. Total: 24 + X bytes. > 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 -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Abridged Certificate Compression
On Mon, Jul 10, 2023 at 10:54 AM Dennis Jackson wrote: > > On 07/07/2023 21:28, Eric Rescorla wrote: > > S 3.2.1 >> How much value are you getting from the CT logs? It seems like >> additional complexity. I agree with your comment about having >> this submitted to CCADB. >> >> It seemed the fairest repeatable way to check whether a CA was offering >> certificates to WebPKI clients without having to write a lot of emails. I >> agree its not desirable to keep as a dependency in the long run. >> > Can you elaborate on the concern here? I.e., is it that we will > overinclude or underinclude if we just use CCADB? > > Sorry, this answer came out garbled. Using CT gives two things: > > 1) There are large extensions in end-entity certs which are specific to > the issuer and change little between certs. For example, the URLs for OCSP, > CRL and the practice statement are typically the same. Using CT logs lets > me pull out an example of each extension for that CA without having to > write a bunch of mails to ask them to produce them in the right format. > > 2) I don't personally have concerns about the dictionary size and would > prefer to include every CA. However, if someone were to have strong > feelings about this then using CT to measure popularity is much fairer than > say scanning popular domains from the Tranco list or whatever. > > In the long term, I hope this could just be removed and ideally the CA's > themselves provide a fixed size binary blob via CCADB that they'd like > compressed out of their certs. > Thanks for the explanation. It sounds like we agree that it would be best not to have this piece and we just have different assessments of how hard it will be to get CCADB populated with this data. My sense is that we would be better off getting the data from CCADB, as CAs will have a clear incentive to populate it, as their customers will get better performance. However, I think this is a question the WG is well suited to resolve and that we could adopt the document as-is and sort this out later. -Ekr Best, > Dennis > > > Thanks, > -Ekr > > S 5.1. >> ISTM that there are plenty of code points available. >> >> Thanks! >> >> Best, >> Dennis >> >> >> >> >> >> >> >> >> On Thu, Jul 6, 2023 at 3:18 PM Dennis Jackson > 40dennis-jackson...@dmarc.ietf.org> wrote: >> >>> 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/archiv
[TLS] Hybrid Key Exchange in TLS 1.3 section 5
Hi folks, Nice work on the draft by all so far. I had some comments/questions on section 5: * A very minor issue: Section 5.1 has 3 instances of the misspelling "varient". * Section 5.2: The last sentence: "Both sides uses their copy of the shared secret as a component within the hybrid shared secret. where the client's key share is the Kyber public key, and the server's key share is the" has a few issues: o We never find out what the server's key share is. o (Minor) "Both sides uses" should be "Both sides use". o The period after "secret" should probably be either a comma or colon. Regards, Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
