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
