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 <tls-boun...@ietf.org> On Behalf Of Kampanakis, Panos > Sent: Wednesday, July 12, 2023 2:01 PM > To: Dennis Jackson <ietf=40dennis-jackson...@dmarc.ietf.org>; TLS List > <tls@ietf.org> > 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 <tls-boun...@ietf.org> On Behalf Of Dennis Jackson > Sent: Wednesday, July 12, 2023 1:16 PM > To: Kampanakis, Panos <kpanos=40amazon....@dmarc.ietf.org>; TLS List > <tls@ietf.org> > 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
