Looks like a slippery slope to me. Hang on, I will get my skis. If you are going to do this, you might as well go the whole hog and provide a mechanism that allows the client to say if it already has a cert on file for that particular host, e.g. by means of a digest.
Another approach to consider is one in which there are two certs, an ECDH cert that is updated very frequently (e.g. daily) and a longer expiry PQC cert). So the big cert only needs to be transmitted infrequently. Security has different dimensions, we made a lot of compromises in the 1990s because work factor and administrative convenience were at odds. We knew RSA1024 was marginal for a start. With modern machines and ECC, most of those limits have been erased and we started to think differently. PQC forces us to rethink some of that because the certs are not going to fit into a packet. Systems with low work factors are insecure but the same is true of systems that are too difficult to maintain. ACME assists of course. But we have to be aware that achieving an acceptable quantum work factor may result in designs that are compromised relative to where we were headed with ECC/ACME/etc. Bottom line is that we should not reject hybrid solutions. While we have PQC algorithms that provide a work factor we are fairly confident of, the constraints they impose on architecture are significant. So a long lived (1 year) Kyber key paired with a short lived (24 hr) cert for an X.448 key. I think we should also be open to architectures in which we publish an X25519/X448 key in the DNS which is ot the HOST, not the service and use that to provide confidentiality for the service key exchange which is PQC. At the end of the day, the risk someone builds a quantum computer in the next 10 years is real but rather small, these are physics experiments, not computing devices. The risk that we screw up the Internet cryptographic infrastructure by insisting on crypto-perfectionism is probably much higher. When public key arrived, a lot of people got the mistaken idea symmetric crypto was obsolete. It took Dorothy Demming pointing out that the use of a session key/digest in RSA is actually for security and not just an efficiency hack. Perhaps we should approach PQC in the same spirit. On Thu, Jul 6, 2023 at 6: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
