Greetings, I have read the slides at https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-draft-abridged-certificate-compression-00
This proposal consists of two "passes". Pass 1 replaces the full root and intermediate certificates with a short identifier (three bytes, in the slide deck). The three byte identifier is currently sufficient to uniquely support 16 million root and intermediate certificates, and if that isn't enough, an extra byte is cheap. (It's also extensible if you, for example, "reserve" identifiers with bit zero equal to b'1', allowing you to transition to a variable length encoding down the line if it somehow becomes necessary, without any ambiguity.) It seems unlikely that there are enough CAs to exhaust this anytime soon? If there are enough CAs, then make it 6 bytes instead, you'll be good for a long while. Pass 2 creates a "compression dictionary" of common fields within a certificate, such as CRL URLs and other URLs and strings which are common to many certificates, but peculiar to a given CA. If this dictionary wishes to fully support the best possible compression for all publicly trusted certificates, then that dictionary would have to include the URLs and other peculiar strings which appear in any of those CA's certificates, making the dictionary longer and the "compressed" IDs longer due to the larger dictionary. This, I think, is the main reason why having fewer CAs would benefit the compression. However, I would offer a few counterpoints. First, these dictionaries are encoding information that is already specific to each CA. As hinted at in slide 16, multiple smaller dictionaries (i.e. one for each CA, or multiple options for clients to choose from) would improve compression quality. MDSP or CCADB (or whoever is standardizing these dictionaries) could choose to offer the service to specific CAs based on their market share, or could produce a few options - for example, they could produce one with only the CAs which support at least 1% of TLS connections, and call it dictionary 0x01, another with all CAs which support at least 0.1%, call it 0x02, and other which includes all publicly trusted CAs, and call it 0x04. Clients could use one byte to tell the server which dictionaries are available, and the server could use the best dictionary for their chosen CA, using one byte in the response to tell the client which dictionary it chose. Clients could choose which dictionaries to ship based on the application. Second, this is all being discussed in the light of post quantum certificates being significantly larger than current certificates. Slide 10 shows, based on certificates today, how the "green" section can be compressed with pass 2, whereas the "red" section would be difficult or impossible to compress. However, in a post quantum certificate, I believe the red area would be significantly larger than the green area. Accordingly, the "value" of the better compression should be evaluated based on the post-quantum certificates that we will all be using hopefully quite soon, and I think the compression ratios will not be as impressive in that case due to a much larger fraction of the certificate being cryptographic data (rather than plain text). In short, I urge caution for two reasons: * The compression ratio may not be worth the drastic action of distrusting small CAs, when calculated using certificates with post-quantum signatures and public keys. * If the compression ratio is worth implementing pass 2 of the proposal, it would still be less disruptive and controversial to keep the small CAs, but either decline to give them the compression benefit of this proposal, or, create multiple compression dictionaries and allow client software to choose which to ship with. There are some other arguments in support of reducing the number of trusted small CAs, but I think they are unrelated to the topic of this thread (being the proposed compression): * Larger post-quantum certificates will increase the size of browser/OS root certificate stores * As Watson says, the more CAs we have, the greater the overall risk of misbehavior, and smaller CAs are less equipped to implement best practices and respond to incidents However, I think these are separate discussions, which require their own data. Regards, Dan Collins On Sun, Jul 30, 2023 at 1:26 PM Phillip Hallam-Baker <ph...@hallambaker.com> wrote: > I can't see this is necessary and as a matter of policy, restricting > competition for the sake of saving a few bytes on the wire... The industry > has enough anti-Trust issues without people creating new ones. > > Anyone who proposes an OPTIMIZATION has to be 100% compatible with the > legacy. > > The solution in this case is pretty clear: Only use compression for the > CAs you expect it to provide a benefit for. Process the rest as normal. > > > On Sat, Jul 29, 2023 at 11:47 PM Watson Ladd <watsonbl...@gmail.com> > wrote: > >> On Sat, Jul 29, 2023 at 8:35 PM Phillip Hallam-Baker >> <ph...@hallambaker.com> wrote: >> > >> > Which compression scheme is this? >> >> Abridge certificate compression from >> https://datatracker.ietf.org/meeting/117/session/tls >> > >> > Why is this compression scheme likely to take off when there was no >> interest in pursuing my proposal or that of Rob Straddling ten years ago? >> > >> > I am not sure why the number of CAs would lead to issues either. Please >> explain. >> >> Each CA has a root that has to be identified and an intermediate that >> also needs identification. This increases the amount of data the >> clients have to ship with. >> >> Sincerely, >> Watson Ladd >> -- >> Astra mortemque praestare gradatim >> > -- > You received this message because you are subscribed to the Google Groups " > dev-security-policy@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@mozilla.org. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMm%2BLwhf1wt8Dy7fh6zcLRrNzu_VrCai88_zVEpFOgyfFjSEyw%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMm%2BLwhf1wt8Dy7fh6zcLRrNzu_VrCai88_zVEpFOgyfFjSEyw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2Btt54%2B5OR6KQ%3D05X5QiKSdvnA0cVF5vdu4o90W-ikvL4MoU%3DA%40mail.gmail.com.
