Re: [TLS] Abridged Certificate Compression (server participation)
Honestly, people can blame all sorts of things for the OCSP stapling problems, but there was nothing inherently wrong with the approach. The implementations were just pretty poor due to issues Hubert Kario correctly outlined. In general, the needs of server operators and maintainers of server software and the challenges they face are not always taken into account as well as they should be. I think the best way to avoid those problems in this case would be to get up front buy-in from one or two major server software implementors, to make sure they agree with the approach and would be willing to implement it. I'm also very happy with the recent efforts in the ecosystem to increase transparency around all the existing intermediate CAs, and the fact that this enables this sort of technology going forward. There are a bunch of interesting points in this thread that I look forward to thinking more about and discussing in a few weeks. -Tim > -Original Message- > From: TLS On Behalf Of Kampanakis, Panos > Sent: Wednesday, July 12, 2023 2:01 PM > To: Dennis Jackson ; TLS List > > Subject: Re: [TLS] Abridged Certificate Compression (server participation) > > Imo, the dictionary approach a simple way of trimming down the PQ auth > data. And your argument for the frequency of synching OCSP staples vs these > certs is a good one. I hope TLS termination points will agree if this moves > forward, but personally I don't find the approach too bad. > > -Original Message- > From: TLS On Behalf Of Dennis Jackson > Sent: Wednesday, July 12, 2023 1:16 PM > To: Kampanakis, Panos ; TLS List > > Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (server > participation) > > 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 05:02, Kampanakis, Panos wrote: > > > The abridged certs draft requires a server who participates and fetches > dictionaries in order to make client connections faster. As Bas has pointed > out > before, this paradigm did not work well with OSCP staples in the past. Servers > did not chose to actively participate and go fetch them. > > > > Are we confident that servers would deploy the dictionary fetching > mechanism to benefit their connecting clients? > > I think OCSP staples is quite a bit different from this draft. OCSP Staples > requires the server to fetch new data from the CA every day or week. It's > inherently hard to do this reliably, especially with the large number of poor > quality or poorly maintained OCSP servers and the large fraction of operators > who do not want their servers making outbound connections. Besides these > barriers I don't think the benefit was huge as clients already cached OCSP > responses for up to a week so at most it was speeding up one connection per > client per week (this was before network partitioning in browsers) and at > worst it was breaking your website entirely. > > In contrast, this draft aims to speed up every connection that isn't using > session tickets, cause no harm if its misconfigured or out of date and be slow > moving enough that the dictionaries can be shipped as part of a regular > software release and so suitable for anyone willing to update their server > software once a year (or less). Similarly, these updates aren't going to > involve > code changes, just changes to the static dictionaries, so they are suitable > for > backporting or ESR releases. > > It would definitely be good to hear from maintainers or smaller operators if > they have concerns though! > > ___ > 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
Re: [TLS] Abridged Certificate Compression (server participation)
Imo, the dictionary approach a simple way of trimming down the PQ auth data. And your argument for the frequency of synching OCSP staples vs these certs is a good one. I hope TLS termination points will agree if this moves forward, but personally I don't find the approach too bad. -Original Message- From: TLS On Behalf Of Dennis Jackson Sent: Wednesday, July 12, 2023 1:16 PM To: Kampanakis, Panos ; TLS List Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (server participation) 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 05:02, Kampanakis, Panos wrote: > The abridged certs draft requires a server who participates and fetches > dictionaries in order to make client connections faster. As Bas has pointed > out before, this paradigm did not work well with OSCP staples in the past. > Servers did not chose to actively participate and go fetch them. > > Are we confident that servers would deploy the dictionary fetching mechanism > to benefit their connecting clients? I think OCSP staples is quite a bit different from this draft. OCSP Staples requires the server to fetch new data from the CA every day or week. It's inherently hard to do this reliably, especially with the large number of poor quality or poorly maintained OCSP servers and the large fraction of operators who do not want their servers making outbound connections. Besides these barriers I don't think the benefit was huge as clients already cached OCSP responses for up to a week so at most it was speeding up one connection per client per week (this was before network partitioning in browsers) and at worst it was breaking your website entirely. In contrast, this draft aims to speed up every connection that isn't using session tickets, cause no harm if its misconfigured or out of date and be slow moving enough that the dictionaries can be shipped as part of a regular software release and so suitable for anyone willing to update their server software once a year (or less). Similarly, these updates aren't going to involve code changes, just changes to the static dictionaries, so they are suitable for backporting or ESR releases. It would definitely be good to hear from maintainers or smaller operators if they have concerns though! ___ 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 (server participation)
On 12/07/2023 05:02, Kampanakis, Panos wrote: The abridged certs draft requires a server who participates and fetches dictionaries in order to make client connections faster. As Bas has pointed out before, this paradigm did not work well with OSCP staples in the past. Servers did not chose to actively participate and go fetch them. Are we confident that servers would deploy the dictionary fetching mechanism to benefit their connecting clients? I think OCSP staples is quite a bit different from this draft. OCSP Staples requires the server to fetch new data from the CA every day or week. It's inherently hard to do this reliably, especially with the large number of poor quality or poorly maintained OCSP servers and the large fraction of operators who do not want their servers making outbound connections. Besides these barriers I don't think the benefit was huge as clients already cached OCSP responses for up to a week so at most it was speeding up one connection per client per week (this was before network partitioning in browsers) and at worst it was breaking your website entirely. In contrast, this draft aims to speed up every connection that isn't using session tickets, cause no harm if its misconfigured or out of date and be slow moving enough that the dictionaries can be shipped as part of a regular software release and so suitable for anyone willing to update their server software once a year (or less). Similarly, these updates aren't going to involve code changes, just changes to the static dictionaries, so they are suitable for backporting or ESR releases. It would definitely be good to hear from maintainers or smaller operators if they have concerns though! ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Abridged Certificate Compression (server participation)
On Wednesday, 12 July 2023 06:02:09 CEST, Kampanakis, Panos wrote: Hi Dennis, One more topic for general discussion. The abridged certs draft requires a server who participates and fetches dictionaries in order to make client connections faster. As Bas has pointed out before, this paradigm did not work well with OSCP staples in the past. Servers did not chose to actively participate and go fetch them. The problem with OCSP staples is that it has little immediate benefit for the server operator, so there was no strong push to: 1. get it implemented in the TLS libraries 2. have it implemented in the web servers 3. backport those changes to stable branches (of both libraries and web servers) 4. either rebase or backport the changes to long-term support Linux distributions It takes years for such changes to trickle down. -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
