Re: [TLS] Abridged Certificate Compression
Document: draft-jackson-tls-cert-abridge-00.txt Hi Dennis, Thanks for sending this. This seems like great work and a big improvement. I have a number of comments below, mostly minor. S 1.1. The existing compression schemes used in [TLSCertCompress] have been shown to deliver a substantial improvement in QUIC handshake latency [FastlyStudy], [QUICStudy] by reducing the size of server's certificate chain and so fitting the server's initial messages within a single flight. However, in a post-quantum setting, the signatures and public keys used in a TLS certificate chain will be typically 10 to 40 times their current size and cannot be compressed with existing TLS Certificate Compression schemes. Perhaps "because most of the size of the certificate is in high entropy fields such as cryptographic keys and signatures". S 1.2. This draft introduces a new TLS certificate compression scheme [TLSCertCompress] which is intended specifically for WebPKI applications. It uses a predistributed dictionary consisting of all I would note specifically at this point that this fits into the existing compression scheme negotiation structure, as one otherwise needs to look to see what TLSCertCompress goes to. Note that as this is only a compression scheme, it does not impact any trust decisions in the TLS handshake. A client can offer this compression scheme whilst only trusting a subset of the certificates in the CCADB certificate listing, similarly a server can offer this compression scheme whilst using a certificate chain which does not chain back to a WebPKI root. Furthermore, new root certificates are typically included in the CCADB at the start of their application to a root store, a process which typically takes more than a year. Consequently, applicant root certificates can be added to new versions of this scheme ahead of any trust decisions, allowing new CAs to compete on equal terms with existing CAs. Perhaps add "as soon as they are approvedfor entry into the root program." S 1.3. CBOR Encoded X.509 (C509) [I-D.ietf-cose-cbor-encoded-cert-05] defines a concise alternative format for X.509 certificates. If this format were to become widely used on the WebPKI, defining an alternative version of this draft specifically for C509 certificates would be beneficial. Just for clarity "if C509 certificates" because I initially read "this format" as the scheme defined in this document. S 3.1.2. 7. Order the list by the date each certificate was included in the CCADB, breaking ties with the lexicographic ordering of the SHA256 certificate fingerprint. Would it be simpler to just sort by the hash? 1. If so, replace the opaque cert_data member of CertificateEntry with its adjusted three byte identifier and copy the CertificateEntry structure with corrected lengths to the output. It seems like this is not injective in the face of certificates whose length is greater than or equal to 0xff. That's probably not a problem, but I think you should make it clear and have some way to manage it. The decompression algorithm requires the above steps but in reverse, swapping any recognized three-byte identifier in a cert_data field with the DER representation of the associated certificate and updating the lengths. Unrecognized three-byte identifiers are ignored. If the compressed certificate chain cannot be parsed (e.g. due to incorrect length fields) the decompression algorithm SHOULD return the sentinel value 0xff. Note that the connection will fail regardless even if this step is not taken as neither certificate validation nor transcript validation can succeed. Instead of a sentinel, why not just return an error? 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. S 3.2.1.1. These parameters are recommended in order to achieve the best compression ratio however implementations MAY use their preferred parameters as these parameters are not used during decompression. Perhaps "as long as the value of those parameters does not influence decompression". S 5.1. ISTM that there are plenty of code points available. 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 ce
Re: [TLS] Abridged Certificate Compression
> I would love to get feedback from the working group on whether the draft is worth developing further. I read your document [1] and found it very interesting. I found the handling of extensions complicated, although I admit to reading that part very quickly. How much simpler would things be if the identifier were just a SHA256 hash of the CA, perhaps truncated? You send an array of (url, timestamp) as an extension, and then the server just sends the digest of its cert chain, perhaps even its own cert. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Abridged Certificate Compression
On 07/07/2023 17:42, Salz, Rich wrote: I would love to get feedback from the working group on whether the draft is worth developing further. I read your document [1] and found it very interesting. Thanks Rich! I found the handling of extensions complicated, although I admit to reading that part very quickly. How much simpler would things be if the identifier were just a SHA256 hash of the CA, perhaps truncated? You send an array of (url, timestamp) as an extension, and then the server just sends the digest of its cert chain, perhaps even its own cert. So this draft is doing two different things: building the dictionaries in a fair way and then specifying how to use them as part of the existing TLS Certificate Compression extension. Implementations only care about the second part which only involves a bit of string substitution and a call to ZStd. They don't have to know or care about how the dictionaries were built or do any new kind of negotiation. I don't follow your comment about the handling of extensions, the code doing the compression and decompression isn't aware of what an extension is or handling them specially, its just swapping strings. In order to compress the larger strings which issuers add to end entity certificates (e.g. OCSP & CRL URLs, practice statements), the dictionary does include some extensions made by each issuer, but these are just concatenated binary strings. 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
Re: [TLS] Abridged Certificate Compression
Thank you for the comments. I'll fix most of them - responses inline for the rest: On 07/07/2023 17:38, Eric Rescorla wrote: S 3.1.2. 7. Order the list by the date each certificate was included in the CCADB, breaking ties with the lexicographic ordering of the SHA256 certificate fingerprint. Would it be simpler to just sort by the hash? Possibly a premature optimization, but I was thinking that if a new version only included new certificates, it'd be nice to only have to append the new data to the existing dictionaries. I haven't yet worked out if that's actually going to deliver anything useful though. 1. If so, replace the opaque cert_data member of CertificateEntry with its adjusted three byte identifier and copy the CertificateEntry structure with corrected lengths to the output. It seems like this is not injective in the face of certificates whose length is greater than or equal to 0xff. That's probably not a problem, but I think you should make it clear and have some way to manage it. If the length is corrected, isn't the only risk a collision with a certificate which is exactly three bytes and starts with 0xff? 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. 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 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 a
Re: [TLS] Abridged Certificate Compression
> I don't follow your comment about the handling of extensions, the code doing the compression and decompression isn't aware of what an extension is or handling them specially, its just swapping strings. In order to compress the larger strings which issuers add to end entity certificates So, you're pulling out common substrings to make the dictionary more efficient. Thanks for the explanation. I still think it's interesting. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Abridged Certificate Compression
On Fri, Jul 7, 2023 at 1:21 PM Dennis Jackson wrote: > Thank you for the comments. I'll fix most of them - responses inline for > the rest: > > On 07/07/2023 17:38, Eric Rescorla wrote: > > S 3.1.2. > >7. Order the list by the date each certificate was included in the >CCADB, breaking ties with the lexicographic ordering of the >SHA256 certificate fingerprint. > > Would it be simpler to just sort by the hash? > > Possibly a premature optimization, but I was thinking that if a new > version only included new certificates, it'd be nice to only have to append > the new data to the existing dictionaries. I haven't yet worked out if > that's actually going to deliver anything useful though. > Fair enough. > >1. If so, replace the opaque cert_data member of >CertificateEntry with its adjusted three byte identifier and >copy the CertificateEntry structure with corrected lengths to >the output. > > It seems like this is not injective in the face of certificates > whose length is greater than or equal to 0xff. That's probably > not a problem, but I think you should make it clear and have some > way to manage it. > > If the length is corrected, isn't the only risk a collision with a > certificate which is exactly three bytes and starts with 0xff? > Ah yes, I had forgotten about the length value. This indeed seems fine. 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? 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/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 >> >
[TLS] I-D Action: draft-ietf-tls-rfc8446bis-08.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Transport Layer Security (TLS) WG of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename: draft-ietf-tls-rfc8446bis-08.txt Pages : 159 Date: 2023-07-07 Abstract: This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, and 8446. This document also specifies new requirements for TLS 1.2 implementations. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-08.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8446bis-08 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D Action: draft-ietf-tls-rfc8446bis-09.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Transport Layer Security (TLS) WG of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename: draft-ietf-tls-rfc8446bis-09.txt Pages : 159 Date: 2023-07-07 Abstract: This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, and 8446. This document also specifies new requirements for TLS 1.2 implementations. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-09.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8446bis-09 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Abridged Certificate Compression
Hi Dennis, This is an interesting draft. 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. As you point out in the draft, cTLS uses something similar as well. 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. 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. 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? 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. 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? Rgs, Panos [1] https://github.com/csosto-pk/tls-suppress-intermediates/issues/17#issue-1671378265 -Original Message- From: TLS On Behalf Of Dennis Jackson Sent: Thursday, July 6, 2023 6:18 PM To: TLS List 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 trus
