On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote: > Hi Ilari, > > On 10/07/2023 20:19, Ilari Liusvaara wrote: > > What does "Note that the connection will fail regardless even if this > > step is not taken as neither certificate validation nor transcript > > validation can succeed." mean? TLS certificate compression does not > > do anything special with transcript, so transcript validation should > > always succeed. > > TLS Certificate Compression influences the transcript for the decompressing > party, as the output is the Certificate message which is used in the > transcript. So if the Certificate message is incorrectly formatted, then the > the decompressing party will likely bail when passing it to the TLS library. > Even if they succeed and try to use it in a transcript calculation, the > compressing party's transcript includes the uncompressed certificate > directly and so will differ.
RFC 8879 does not alter how transcript is computed in any way. An extension altering computation of transcript would be truly extraordinary. > > And are there zstd decoders that can reuse output buffer in oneshot > > decompression for lookback? The zstd command line tool manual page > > mentions default 128MB memory limit for decompression. I presume > > mostly for lookback. Such limit is way too large. > Zstd is already supported without a dictionary for TLS Certificate > Compression so others with deployment experience may be able to give an > authoritative answer. That said, Facebook's Zstd implementation is > permissively licensed, used in the Linux Kernel and their discussion here > <https://github.com/facebook/zstd/issues/2093> suggests much smaller limits > are fine. Actually, that issue pointed to the API I was looking for. And looks like memory requirement is something like <300kB. > > And an alternative idea: > > > > [...] > > > > 1) Where if next certificate in chain is also not found, zstd uses > > empty dictionary. Otherwise it uses dictionary associated with the > > next certificate in chain. > > > > [...] > > > > This allows dictionaries to be specific to CA, avoiding tradeoffs > > between CAs. > > Interesting idea! Can you share more about the motivation for using many > small dictionaries rather than a single combined one? Is it purely for > supporting memory constrained devices? We can already ensure that each CA > contributes an equal number of bytes to the pass 2 dictionary. > > One drawback is that some of the data isn't unique to a particular issuer > (e.g. the CT log ids) and so would either have to be handled in its own pass > or be included as redundant data in each individual dictionary. I was assuming that including all the CA-specific stuff across all CAs would cause the dictionary to grow quite large. And I think smaller dictionaries that still have everything needed give slightly better compression. And it is possible to do constructions like dictionary = common_part || ca_specific_part. With possibly common_part being the dictionary used on next certificate not found. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
