On Fri, Mar 01, 2024 at 12:48:54PM +0000, Dennis Jackson wrote: > > On 06/09/2023 17:46, Ilari Liusvaara wrote: > > Doing quick review: > > > > Section 3.1.2: > > > > - RFC 8879 does not allow ignoring unrecognized three-byte identifiers. > > Instead, the connection MUST be terminated with bad_certificate alert. > > > > This has consequence that any client that can ever add a custom trust > > anchor via any means must have the complete certificate list (whereas > > partial list would be enough if no custom trust anchors can ever be > > added). > > I hope that clarifies why transmitting the lengths is necessary. Regarding > the decompression errors, I've updated the draft to say that decompression > must fail and the correct alert sent if the length fields are incorrect as > you suggested. I've filed an issue to discuss the case of unrecognized > identifiers specifically [1].
The unrecognized identifier issue is a bit more subtle. Suppose that a client: - Has only partial list of certificates (enough to cover the built-in trust store). - Allows an admin to add a new trust anchor, or to override validation error. Then such client can get into situation where server sends chain that should be valid, but instead references a certificate the client does not have. Which is a hard error. > > Section 3.2.: > > > > - Using alternate scheme could result drastically reduced implementation > > complexity. > > > > Furthermore, one can't even use standard zstd decoder with this due to > > security reasons. One needs special one (but seems like reference zstd > > library ships that as alternative API). > > Can you clarify what you mean by this? The standard zstd decoder works fine. The standard zstd decoder can allocate very large amounts of memory. Thus, one has to use decoder that decodes in one shot to given buffer with a small bounded memory usage. Fortunately, standard zstd library does have such decoder. > > Section 3.2.1.: > > > > - I suspect that having CA-specific dictionaries would make it much > > easier to be equitable and improve compression. > > > > Then I don't think the dictionary construction method is good: > > * Using just one certificate is very dubious. > > * It is more optimal to consider byte substrings with no structure. > > This is tracked in [2] and [3]. Depending on the experimental data we get > when evaluating [3], we might omit pass 2 entirely. Regarding the dictionary construction, it is just that I think that using many certificates and choosing common unstructured substrings would lead to a better dictionary. It is not like this method uses certificate structure in any way. > > Section 3.2.1.1.: > > > > - Caching monolithic compression from startup does not work because of > > extension fields. > > > > For caching to work, one would have to compress the certificate > > entries independently and leave the extension fields in between > > uncompressed. > > The draft currently preserves the extension fields. Existing TLS Certificate > Compression APIs perform the caching at the level of the entire message and > so the cache is only used if the entire message, including extensions, is > bytewise identical. Can you think of an extension in a Certificate message > which changes frequently? Dealing with 1 variant is easy, dealing with up to N variants is much harder. And that N is exponential in number of supported extensions, and some extensions might do internal negotiation, making it grow even faster than 2^k. > > Section 5.1.: > > > > - I think the argument about adding roots taking time is flawed. Roots > > are usually not even included in the chain, but intermediates are, > > and can change much faster. > > > > I remember seeing one CA that judging from naming of the intermediate > > rotated it every 6 months. > > This draft definitely doesn't want to be a factor slowing rotation. I've > filed [4] to keep track of this. As discussed in Appendix B and in the IETF > 117 presentation, it might be that dynamic versioning is more suitable in > the long run. It seems to be very difficult for strategy like this to work well in very dynamic situations. Things like trust expressions seem to be much better designed for dealing with highly dynamic situations. And trust expressions can be leveraged for omitting intermediates (intermediates can be temporarily promoted into trust anchors). > > Section 5.4: > > > > - I think the current complexity as I understand the draft is just > > scary. > > > > I consider not being able to adjust extension fields in the fly to > > be a hard blocker (that is already a hard blocker for implementing > > RFC 8879 sending side). > > As discussed above, I think this is a misunderstanding of the draft and how > existing TLS Certificate Compression schemes work. I don't see any way around either forgoing caching or dealing with exponential complexity when combining TLS Certificate Compression and certificate extensions on server side. The way I deal with that: Don't support TLS certificate compression on server side. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
