Document: draft-jackson-tls-cert-abridge-00.txt
Hi Dennis,
Thanks for sending this. This seems like great work and
a big improvement. I have a number of comments below,
mostly minor.
S 1.1.
The existing compression schemes used in [TLSCertCompress] have been
shown to deliver a substantial improvement in QUIC handshake latency
[FastlyStudy], [QUICStudy] by reducing the size of server's
certificate chain and so fitting the server's initial messages within
a single flight. However, in a post-quantum setting, the signatures
and public keys used in a TLS certificate chain will be typically 10
to 40 times their current size and cannot be compressed with existing
TLS Certificate Compression schemes.
Perhaps "because most of the size of the certificate is in high
entropy fields such as cryptographic keys and signatures".
S 1.2.
This draft introduces a new TLS certificate compression scheme
[TLSCertCompress] which is intended specifically for WebPKI
applications. It uses a predistributed dictionary consisting of all
I would note specifically at this point that this fits into the existing
compression scheme negotiation structure, as one otherwise needs
to look to see what TLSCertCompress goes to.
Note that as this is only a compression scheme, it does not impact
any trust decisions in the TLS handshake. A client can offer this
compression scheme whilst only trusting a subset of the certificates
in the CCADB certificate listing, similarly a server can offer this
compression scheme whilst using a certificate chain which does not
chain back to a WebPKI root. Furthermore, new root certificates are
typically included in the CCADB at the start of their application to
a root store, a process which typically takes more than a year.
Consequently, applicant root certificates can be added to new
versions of this scheme ahead of any trust decisions, allowing new
CAs to compete on equal terms with existing CAs.
Perhaps add "as soon as they are approvedfor entry into the root
program."
S 1.3.
CBOR Encoded X.509 (C509) [I-D.ietf-cose-cbor-encoded-cert-05]
defines a concise alternative format for X.509 certificates. If this
format were to become widely used on the WebPKI, defining an
alternative version of this draft specifically for C509 certificates
would be beneficial.
Just for clarity "if C509 certificates" because I initially
read "this format" as the scheme defined in this document.
S 3.1.2.
7. Order the list by the date each certificate was included in the
CCADB, breaking ties with the lexicographic ordering of the
SHA256 certificate fingerprint.
Would it be simpler to just sort by the hash?
1. If so, replace the opaque cert_data member of
CertificateEntry with its adjusted three byte identifier and
copy the CertificateEntry structure with corrected lengths to
the output.
It seems like this is not injective in the face of certificates
whose length is greater than or equal to 0xff0000. That's probably
not a problem, but I think you should make it clear and have some
way to manage it.
The decompression algorithm requires the above steps but in reverse,
swapping any recognized three-byte identifier in a cert_data field
with the DER representation of the associated certificate and
updating the lengths. Unrecognized three-byte identifiers are
ignored. If the compressed certificate chain cannot be parsed (e.g.
due to incorrect length fields) the decompression algorithm SHOULD
return the sentinel value 0xff. Note that the connection will fail
regardless even if this step is not taken as neither certificate
validation nor transcript validation can succeed.
Instead of a sentinel, why not just return an error?
S 3.2.1
How much value are you getting from the CT logs? It seems like
additional complexity. I agree with your comment about having
this submitted to CCADB.
S 3.2.1.1.
These parameters are recommended in order to achieve the best
compression ratio however implementations MAY use their preferred
parameters as these parameters are not used during decompression.
Perhaps "as long as the value of those parameters does not influence
decompression".
S 5.1.
ISTM that there are plenty of code points available.
On Thu, Jul 6, 2023 at 3:18 PM Dennis Jackson <ietf=
40dennis-jackson...@dmarc.ietf.org> wrote:
> 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
