hannestschofenig
commented
3 years ago Here is proposed text:
Certificate Overhead
In a public key-based key exchange certificates and public keys exchanged are a major contributor to the size of the overall handshake. For example, in a regular TLS 1.3 exchange with minimalistic ECC certificates and no intermediate CA utilizing the NIST P256r1 curve with mutual authentication around 40 % for the entire handshake payload is consumed by the two exchanged certificates.
Hence, it is not surprising that there is a strong desire to reduce the size of certificates and certificate chains. This has lead to various standardization efforts. Here is a brief summary of what options an implementer has to reduce the bandwidth requirements of a public key-based key exchange:
- Use elliptic curve cryptography (ECC) instead of RSA-based certificate due to the smaller certificate size.
- Avoid deep and complex CA hierarchies to reduce the number of intermediate CA certificates that need to be transmitted.
- Pay attention to the amount of information conveyed inside certificates.
- Use session resumption to reduce the number of times a full handshake is needed. For DTLS 1.3 Connection IDs are available, which enables long-lasting connections.
- Use the TLS cached info {{RFC7924}} extension to avoid sending certificates with every full handshake.
- Use client certificate URLs {{RFC6066}} instead of full certificates for clients.
- Utilize certificate compression as defined in {{I-D.ietf-tls-certificate-compression}}.
- Use alternative certificate formats, where possible, such as raw public keys {{RFC7250}} or CBOR-encoded certificates {{I-D.ietf-cose-cbor-encoded-cert}}.
The use of certificate handles, as introduced in cTLS {{I-D.ietf-tls-ctls}}, is a form of caching or compressing certificates as well.
Whether to use any of the above extensions or a combination of them depends on the anticipated deployment environment, the availability of code, and the constraints imposed by already deployed infrastructure (e.g. CA infrastructure, tool support).
Should also we move the ASN.1 schema from Appendix B of {{?I-D.raza-ace-cbor-certificates}} here and let it have it by reference?
The compression methods defined in {{?I-D.ietf-tls-certificate-compression}} do not seem to deal effectively with {{!RFC7925}} profiled certificates: zlib compresses the example cert by 9%, but other certificates and compression algorithms do in many cases increase the overall size. On the other hand, {{I-D.raza-ace-cbor-certificates}} provides a more efficient scheme, yielding to compression rates higher than 50% (see Section 3 of {{?I-D.mattsson-cose-cbor-cert-compress}}).
Besides TLS certificate compression and CBOR-compressed certificates there are many other techniques for reducing the size of certificates in a TLS handshake. Which solution should we recommend?