On Wed, Sep 06, 2023 at 07:39:12AM -0700, internet-dra...@ietf.org wrote: > Internet-Draft draft-ietf-tls-cert-abridge-00.txt is now available. It is a > work item of the Transport Layer Security (TLS) WG of the IETF. > > Title: Abridged Compression for WebPKI Certificates > Author: Dennis Jackson > Name: draft-ietf-tls-cert-abridge-00.txt > Pages: 19 > Dates: 2023-09-06
Doing quick review: Section 3.1.2: - It is not clear what exactly is replaced if cert_data is known. Obviously overriding the length field would be more compact, but it also can be interpreted as replacing the value, wasting 3 bytes. (Reminds me of RFC 8879, which is not clear about similar things.) - CertificateEntry and Certificate length fields are just waste of space, since both can be recovered in other ways when decoding. - 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). And I find the last comment about transcript validation failing very scary. 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). 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. 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. 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. 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). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
