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.
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.
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.
Best,
Dennis
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
