Hi Panos,
On 08/07/2023 02:49, Kampanakis, Panos wrote:
Hi Dennis,
This is an interesting draft.
Thanks!
The versioned dictionary idea for ICA and Root CAs especially was something I
was considering for the ICA Suppression draft [1] given the challenges brought
up before about outages with stale dictionary caches.
Btw, if we isolated the ICA and Root CA dictionary, I don't think you need pass
1, assuming the parties can agree on a dictionary version. They could just
agree on the dictionary and be able to build the cert chain, but providing the
identifiers probably simplifies the process. This could be simplified further I
think.
Ah I hadn't seen, thank you for the link to [1].
I thought a bit about suppressing pass 1 as well but I don't think its
desirable.
A key selling point of the current Abridged Certs draft is that it can
be enabled by default without the risk of connection failures or
requiring retries, even if the server / client fall out of date. This
keeps the deployment story very simple as you can just turn it on
knowing it can only make things better and never make things worse.
Suppressing Pass 1 could be used to reduce the storage requirements on
the server but then the server wouldn't know whether a particular ICA
was in the dictionary and so the operator would have to configure that,
leading to the same kind of error handling flows as in the CA Cert
Suppression draft. Similarly, the bytes on the wire saving isn't
significant and it would make it harder to use Abridged Certs in other
contexts as it would no longer be a lossless compression scheme.
I also think one thing missing from the draft is how the client negotiates this
compression with the server as the CertificateCompressionAlgorithms from
RFC8879 will not be the same.
Sorry I'm afraid I don't follow.
Abridged Certs would negotiated just the same as any other certificate
compression algorithm. The client indicates support by including the
Abridged Certs identifier in its Certificate Compression extension in
the ClientHello (along with the existing algorithms like plain Zstd).
The server has the choice of whether to use it in its
CompressedCertificate message. If a new version of Abridged Certs were
minted in a few years with newer dictionaries then it would have its own
algorithm identifier and would coexist with or replace the existing one.
About the end-entity compression, I wonder if compression, decompression
overhead is significant and unbalanced. RFC8879 did not want to introduce a DoS
threat by offering a cumbersome compression/decompression. Any data on that?
Abridged Certs is just a thin wrapper around Zstd which is already
deployed as TLS Certificate Compression algorithm, so the same
considerations apply. According to Facebook's numbers [ZSTD],
decompression is more than 4x faster than Brotli and insensitive to the
compression level used. TLS Certificate Compression schemes aren't
sensitive to compression speed as it can be done once and cached at
startup, but I ran a benchmark [COMPARE] using both the maximum and
minimal Zstd compression levels and the outcome was within 100 bytes, so
servers wanting to do just-in-time compression can use a minimal level
without difficulty. I hope to have some proper benchmarks using a Rust
implementation by the end of the week.
About your data in section 4, I think these are classical cert chains and it
looks to be they improve 0.5-1KB from RFC8879 compression.
They are classical cert chains but I think you might be misreading the
table. The improvement over regular TLS Certificate Compression is 1KB
at the 5th percentile, 2.2 KB at the 50th percentile and 2.5 KB at the
95th percentile.
In a WebPKI Dilithium2 cert with 2 SCTs the end-entity cert size will amount to ~7-8KB.
85% of that will be the "random" Dilithium public key and signatures which will
not get much compression. So, do we get any benefit from compressing 7-8KB certs to
6-7KB? Is it worth the compression/decompression effort?
A 2.5 KB saving gives back a whole Dilithium2 signature, which I think
is fair to say is substantial.
The overall size of a PQ end-entity cert is still uncertain and may not
be as large as your calculation. If proofs of inclusion were used
instead of SCTs, as suggested in Merkle Tree Certs [MTC], then each
SCT-equivalent would be under 1 KB. Abridged Certs would then be saving
around 2.5 KB of a 6 KB certificate, fitting the entire chain in roughly
4KB. So we'd be shipping a full PQ cert chain without any size inflation
on today's uncompressed classical chains.
Best,
Dennis
[ZSTD] https://github.com/facebook/zstd
[COMPARE]
https://gist.github.com/dennisjackson/e1dccfef104cabc1e4151c47338bc9b2
[MTC]
https://davidben.github.io/merkle-tree-certs/draft-davidben-tls-merkle-tree-certs.html
-----Original Message-----
From: TLS <tls-boun...@ietf.org> On Behalf Of Dennis Jackson
Sent: Thursday, July 6, 2023 6:18 PM
To: TLS List <tls@ietf.org>
Subject: [EXTERNAL] [TLS] Abridged Certificate Compression
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
Hi all,
I've submitted the draft below that describes a new TLS certificate compression
scheme that I'm calling 'Abridged Certs' for now. The aim is to deliver
excellent compression for existing classical certificate chains and smooth the
transition to PQ certificate chains by eliminating the root and intermediate
certificates from the bytes on the wire. It uses a shared dictionary
constructed from the CA certificates listed in the CCADB [1] and the associated
extensions used in end entity certificates.
Abridged Certs compresses the median certificate chain from ~4000 to
~1000 bytes based on a sample from the Tranco Top 100k. This beats traditional
TLS certificate compression which produces a median of ~3200 bytes when used
alone and ~1400 bytes when combined with the outright removal of CA
certificates from the certificate chain. The draft includes a more detailed
evaluation.
There were a few other key considerations. This draft doesn't impact trust
decisions, require trust in the certificates in the shared dictionary or
involve extra error handling. Nor does the draft favor popular CAs or websites
due to the construction of the shared dictionary. Finally, most browsers
already ship with a complete list of trusted intermediate and root certificates
that this draft reuses to reduce the client storage footprint to a few
kilobytes.
I would love to get feedback from the working group on whether the draft is
worth developing further.
For those interested, a few issues are tagged DISCUSS in the body of the draft,
including arrangements for deploying new versions with updated dictionaries and
the tradeoff between equitable CA treatment and the disk space required on
servers (currently 3MB).
Best,
Dennis
[1] Mozilla operates the Common CA Database on behalf of Apple, Microsoft,
Google and other members.
On 06/07/2023 23:11, internet-dra...@ietf.org wrote:
A new version of I-D, draft-jackson-tls-cert-abridge-00.txt
has been successfully submitted by Dennis Jackson and posted to the
IETF repository.
Name: draft-jackson-tls-cert-abridge
Revision: 00
Title: Abridged Compression for WebPKI Certificates
Document date: 2023-07-06
Group: Individual Submission
Pages: 19
URL:
https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.txt
Status: https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
Html:
https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-jackson-tls-cert-abridge
Abstract:
This draft defines a new TLS Certificate Compression scheme which
uses a shared dictionary of root and intermediate WebPKI
certificates. The scheme smooths the transition to post-quantum
certificates by eliminating the root and intermediate certificates
from the TLS certificate chain without impacting trust negotiation.
It also delivers better compression than alternative proposals whilst
ensuring fair treatment for both CAs and website operators. It may
also be useful in other applications which store certificate chains,
e.g. Certificate Transparency logs.
The IETF Secretariat
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
