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 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:
>
