> I agree we should measure carefully before deciding whether it be mandatory > for PQ certs.
I tested this further for Dilithium and wanted to share the results. The TL;DR; is that compressing the leaf cert on top of compressing/omitting the CAs vs just compressing/omitting the CAs may only drop us below 9KB for Dilithium3 (non WebPKI). And that may not always be the case. All other non WebPKI or WebPKI cases will not see any significant benefit. Also, there is no case where compressing the leaf cert will drop us below the QUIC amplification limit. That is one reason why I am suggesting to differentiate between the leaf cert and the CA certs compression. Another reason is that we should be able to use just compression of CA certs (pass 1) for non WebPKI cases where the CT leaf cert dictionary cannot be built (pass 2) More details on the experiments follow. (Sorry for the length. ) I tested with P256+Kyber512 with Dilithium2 certs and P256+Kyber512 with Dilithium3 certs in TLS 1.3. My Dilithium certs did not include any SCTs (no WebPKI). Also, the cert were minimalistic without basic fields, EKUs, Cert Policies, CRLS, SKI, AIA, complicated SANs etc. So my leaf cert was pretty slim other that the signature and public key and it was not "compressible" much. * P256_Kyber512 + Dilithium2: - ClientHello = 1137B - ServerHello + Server ChangeCipherSpec = 923+1=924B - Server Certificates, Certificate Verify + Server Finished = 7868+2450=10318 B DER encoded CA and Server certs are 3.9KB each. That basically adds up to 1.3KB (Dilithium2 public key)+2.4(Dilithium2 signatures) + a little more for the rest of the cert fields which are small anyway. So a total chain is 7.8KB. To confirm intuitively, the Server Certificates, Certificate Verify + Server Finished roughly adds up to 10.318=7.8 (cert chain DER formatted)+2.4(Dilithium2 signature)+miniscule size of Finished message and other fields. So, if we omitted the CA cert we would get 10.3-3.9=6.4KB. If we compressed the leaf cert fields further, we could save maximum another 0.5-1KB which is not even possible for these certs because they were really minimalistic. So we would definitely end up over 5KB which is way over 3xClientHello size. QUIC amplification would still kick in. Regarding the 9-10KB TLS 1.3 limit from Bas' blog post, at 6.4+1KB if we account for heavier certs, we would be way below 9KB by just omitting the CA certs even with heavier leaf certs than my minimalistic ones. So, leaf compression on top of CA omission would not make a difference for the QUIC limit or the 9-10KB TLS 1.3 limit. Now, for WebPKI, if we add 2 more Dilithium2 signatures 2*2.4=4.8KB, it would take us to 6.4+4.8=11.2KB by just omitting the CA certs. If we compress the leaf fields on top of that and we save 0.5-1KB more KB, we still stay over both the QUIC and the TLS limit. So for WebPKI, compressing the leaf fields does not buy us much. * P384_Kyber768 + Dilithium3: - ClientHello = 1554B - ServerHello + Server ChangeCipherSpec = 1271+1=1272B - Server Certificates, Certificate Verify + Server Finished = 10894+3323=14217B DER encoded CA and Server certs are 5.4KB each. That basically adds up to 1.9KB (Dilithium3 public key)+3.3(Dilithium3 signatures) + a little more for the rest of the cert fields which are small anyway. So a total chain is 10.8KB. To confirm intuitively, the Server Certificates, Certificate Verify + Server Finished roughly adds up to 14.217=10.8 (cert chain DER formatted)+3.3(Dilithium3 signature)+miniscule size of Finished message and other fields. So, if we omitted the CA cert we would get 8.8KB. If we compressed the leaf cert fields further, we could gain maximum another 0.5-1KB which is not even possible for these certs because they were really minimal. So we would end up around 8KB which is way over 3xClientHello size. QUIC amplification would kick in. Regarding the 9-10KB TLS 1.3 limit from Bas' blog post, compression could get us around 8KB although I think this would be a stretch. It is probably more realistic to say it would be around 9KB with real leaf certs heavier than my minimalistic ones. So, TLS 1.3 could see a benefit in some cases, not in others depending on the leaf cert bloat. So leaf compression on top of CA omission would not put us below the QUIC amplification limit. It could make a difference for the 9-10KB TLS 1.3 limit depending on the leaf cert bloat. Now, for WebPKI, if we add 2 more Dilithium3 signatures 2*3.3=6.6KB, it would take us to 8.8+6.6=16.4KB by just omitting the CA certs. If we compress the leaf fields on top of that and we save 0.5-1KB more KB, we still stay over both the QUIC and the TLS limit. So for WebPKI, compressing the leaf fields does not buy us anything. -----Original Message----- From: Dennis Jackson <ietf=40dennis-jackson...@dmarc.ietf.org> Sent: Friday, July 14, 2023 6:28 AM To: Kampanakis, Panos <kpa...@amazon.com>; TLS List <tls@ietf.org> Subject: RE: [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. On 12/07/2023 19:23, Kampanakis, Panos wrote: > One more argument for making pass 2 optional or allowing for just pass 1 > dictionaries is that if we are not talking about WebPKI we don't have the > luxury of CT logs. But we would still want to option of compressing / > omitting the ICAs by using CCADB. Using the CT logs to extract the end-entity extensions is a bit of a stop-gap measure. I think in the long run we'd like to add a field to the CCADB where CAs could provide their own compression data (up to some budget). Whilst I think pass 2 has a marked improvement for classical cert chains - in some cases fitting the entirety of the server's response in one packet - I agree we should measure carefully before deciding whether it be mandatory for PQ certs. Best, Dennis > > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
