Re: [TLS] Abridged Certificate Compression

[Bas Westerbaan]

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

If clients cache intermediates as they go, then reporting that list to a
server is an obvious privacy issue. When you restrict to a fixed set,
updated in unison, we essentially return to reach Dennis' proposal.

Best,

 Bas
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Phillip Hallam-Baker]

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

Re: [TLS] Abridged Certificate Compression

[Ilari Liusvaara]

On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote:
> Hi Ilari,
> 
> On 10/07/2023 20:19, Ilari Liusvaara wrote:
> >
> > And an alternative idea:
> > 
> > [...]
> > 
> > 1) Where if next certificate in chain is also not found, zstd uses
> > empty dictionary. Otherwise it uses dictionary associated with the
> > next certificate in chain.
> > 
> > [...]
> > 
> > This allows dictionaries to be specific to CA, avoiding tradeoffs
> > between CAs.
> 
> Interesting idea! Can you share more about the motivation for using many
> small dictionaries rather than a single combined one? Is it purely for
> supporting memory constrained devices? We can already ensure that each CA
> contributes an equal number of bytes to the pass 2 dictionary.
> 
> One drawback is that some of the data isn't unique to a particular issuer
> (e.g. the CT log ids) and so would either have to be handled in its own pass
> or be included as redundant data in each individual dictionary.

Actually, I don't think this idea would work well: Clients would still
need at least all the dictionaries for end-entity certificates, for the
case where server certificate is from unknown CA and certificate
validation is overridden.

Because to comply with TLS 1.3 requirements (CV validation is required),
the client needs the server signature key, which is embedded in server
certificate, which in turn needs dictionary to decompress.

Altough I think it is technically possible to just skip CV validation,
allowing the decompression to be skipped. However, this breaks the
TLS 1.3 specification.




-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression (discussion of leaf cert compression discussion)

[Kampanakis, Panos]

> 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  
Sent: Friday, July 14, 2023 6:28 AM
To: Kampanakis, Panos ; TLS List 
Subject: RE: [EXTERNAL][TLS] Abri

Re: [TLS] Abridged Certificate Compression

[Rob Stradling]

Hi Dennis.  I did read section 3.2.1 of the draft before posting, but I got the 
impression that the lexicographically ordered list of log identifiers produced 
in the "Secondly" step was only intended to be used as a reference in the 
"Finally" step, rather than emitted as "output".

I understand that "This dictionary is constructed in three stages, with the 
output of each stage being concatenated with the next", but the only explicit 
language regarding which artifacts should be emitted as "output" is 
"Concatenate the byte representation of each extension (including extension id 
and length) and copy it to the output".  It's not clear to me if that explicit 
language is intended to be part of the "Finally" step only, or if it's intended 
to apply to all of the steps.

My attempt to clarify things: 
https://github.com/dennisjackson/draft-jackson-tls-cert-abridge/pull/9.


From: TLS  on behalf of Dennis Jackson 

Sent: 14 July 2023 11:30
To: TLS List 
Subject: Re: [TLS] Abridged Certificate Compression


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


On 13/07/2023 10:13, Rob Stradling wrote:

How about also including in the shared dictionary the SHA-256 hashes of the 
public keys of all the known CTv1 logs, so that the 32-byte LogID field of each 
SCT will be compressed?

This is already step 2 of the shared dictionary construction :-) 
(link<https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.html#section-3.2.1-4>).


Best,
Dennis

FWIW, RFC9162 (CTv2) tackles the same SCT bloat by changing the LogID type from 
a (32-byte) SHA-256 hash of the log's public key to a (minimum 4-byte) 
DER-encoded OID (excluding the tag and length octets).


From: TLS <mailto:tls-boun...@ietf.org> on behalf of Tim 
Hollebeek 
<mailto:tim.hollebeek=40digicert@dmarc.ietf.org>
Sent: 12 July 2023 19:29
To: Kampanakis, Panos 
<mailto:kpanos=40amazon@dmarc.ietf.org>;
 Dennis Jackson 
<mailto:ietf=40dennis-jackson...@dmarc.ietf.org>;
 TLS List <mailto:tls@ietf.org>
Subject: Re: [TLS] Abridged Certificate Compression

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


SCTs have always seemed surprisingly large to me, and it has always seemed
like there should be a more compact representation that has the same security
properties, but I've never found the time to look more closely at it.  If 
someone
does have the time, figuring out how to reduce the size of SCTs would be quite
helpful.

-Tim

> -Original Message-
> From: TLS <mailto:tls-boun...@ietf.org> On Behalf Of 
> Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:23 PM
> To: Dennis Jackson 
> <mailto:ietf=40dennis-jackson...@dmarc.ietf.org>;
>  TLS List
> <mailto:tls@ietf.org>
> Subject: Re: [TLS] Abridged Certificate Compression
>
> > The performance benefit isn't purely in the ~1KB saved, its whether it 
> > brings
> the chain under the QUIC amplification limit or shaves off an additional 
> packet
> and so avoids a loss+retry. There's essentially no difference in 
> implementation
> complexity, literally just a line of code, so the main tradeoff is the 
> required disk
> space on the client & server.
>
> Fair. I would add one more tradeoff which is pulling the end-entity certs in 
> the
> CT window for pass 2. This is an one time cost for each dictionary version, so
> maybe not that bad.
>
> Regardless, would compressing the leaf bring us below the QUIC 3.6KB
> threshold for Dilithium 2 or 3 certs whereas not suppressing would keep us
> above? I think it is not even close if we are talking WebPKI. Without SCTs,
> maybe compressing could keep us below 4KB for Dilithium 2 leaf certs. But
> even then, if we add the CertVerify signature size we will be well over 4KB.
>
> Additionally, would compressing the leaf bring us below the 9-10KB threshold
> that Bas had tested to be an important inflection point? For WebPKI, it may
> the 8-9KB cert below 9KB if we add the CertVerify signature size. Maybe not. 
> It
> would need to tested. For Dilithium 3, maybe compression could render the
> 11-12KB cert below 9KB if we got lucky, maybe not, but if we add the
> CertVerify signature we won’t make it. For non-WebPKI, they will already be
> below 9-10KB.
>
> So, I am arguing that we can't remain below the QUIC threshold by
> compressing the leaf Dilithium cert. And we could remain below the 9-10KB
> only for Dilithium2 leaves.  I could be proven wrong if you have implemented
&g

Re: [TLS] Abridged Certificate Compression (dictionary versioning)

[Dennis Jackson]

On 13/07/2023 02:31, Kampanakis, Panos wrote:


Btw, in 3.1.1 I noticed
- "Remove all intermediate certificates which are not signed by root certificates 
still in the listing."

That could eliminate some 2+ ICA cert chains. Any reason why?
Whoops, that's a good spot. The intent here was just to remove any 
intermediates which no longer chained back to trusted roots, so I'll fix 
the wording.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

On 13/07/2023 10:13, Rob Stradling wrote:

How about also including in the shared dictionary the SHA-256 hashes 
of the public keys of all the known CTv1 logs, so that the 32-byte 
LogID field of each SCT will be compressed?


This is already step 2 of the shared dictionary construction :-) (link 
<https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.html#section-3.2.1-4>). 




Best,
Dennis



FWIW, RFC9162 (CTv2) tackles the same SCT bloat by changing the LogID 
type from a (32-byte) SHA-256 hash of the log's public key to a 
(minimum 4-byte) DER-encoded OID (excluding the tag and length octets).



*From:* TLS  on behalf of Tim Hollebeek 


*Sent:* 12 July 2023 19:29
*To:* Kampanakis, Panos ; Dennis 
Jackson ; TLS List 

*Subject:* Re: [TLS] Abridged Certificate Compression
CAUTION: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender 
and know the content is safe.



SCTs have always seemed surprisingly large to me, and it has always seemed
like there should be a more compact representation that has the same 
security
properties, but I've never found the time to look more closely at it.  
If someone
does have the time, figuring out how to reduce the size of SCTs would 
be quite

helpful.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:23 PM
> To: Dennis Jackson ; TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression
>
> > The performance benefit isn't purely in the ~1KB saved, its 
whether it brings
> the chain under the QUIC amplification limit or shaves off an 
additional packet
> and so avoids a loss+retry. There's essentially no difference in 
implementation
> complexity, literally just a line of code, so the main tradeoff is 
the required disk

> space on the client & server.
>
> Fair. I would add one more tradeoff which is pulling the end-entity 
certs in the
> CT window for pass 2. This is an one time cost for each dictionary 
version, so

> maybe not that bad.
>
> Regardless, would compressing the leaf bring us below the QUIC 3.6KB
> threshold for Dilithium 2 or 3 certs whereas not suppressing would 
keep us
> above? I think it is not even close if we are talking WebPKI. 
Without SCTs,
> maybe compressing could keep us below 4KB for Dilithium 2 leaf 
certs. But
> even then, if we add the CertVerify signature size we will be well 
over 4KB.

>
> Additionally, would compressing the leaf bring us below the 9-10KB 
threshold
> that Bas had tested to be an important inflection point? For WebPKI, 
it may
> the 8-9KB cert below 9KB if we add the CertVerify signature size. 
Maybe not. It
> would need to tested. For Dilithium 3, maybe compression could 
render the

> 11-12KB cert below 9KB if we got lucky, maybe not, but if we add the
> CertVerify signature we won’t make it. For non-WebPKI, they will 
already be

> below 9-10KB.
>
> So, I am arguing that we can't remain below the QUIC threshold by
> compressing the leaf Dilithium cert. And we could remain below the 
9-10KB
> only for Dilithium2 leaves.  I could be proven wrong if you have 
implemented

> it.
>
> 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.
>
>
>
>
> -Original Message-
> From: Dennis Jackson 
> Sent: Wednesday, July 12, 2023 12:39 PM
> To: Kampanakis, Panos ; TLS List 
> 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 04:34, Kampanakis, Panos wrote:
>
> > Thanks Dennis. Your answers make sense.
> >
> > Digging a little deeper on the benefit of compressing (a la Abridged
> > Certs draft) the leaf cert or not. Definitely this draft improves vs
> > plain certificate compression, but I am trying to see if it is worth
> > the complexity of pass 2. So, section 4 shows a 2.5KB improvement over
> > plain compression which would be even more significant for Dilithium
> > certs, but I am trying to find if the diff between ICA
> > suppression/Compression vs ICA suppression/Compression+leaf
> > compression is significant. [/n]
> >
> > I am arguing that the table 4 numbers would be much different when
> > talking about Dilithium certs because all of these numbers would be
> > inflated and any compression would have a

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

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






-Original Message-
From: Dennis Jackson 
Sent: Wednesday, July 12, 2023 12:39 PM
To: Kampanakis, Panos ; TLS List 
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 04:34, Kampanakis, Panos wrote:


Thanks Dennis. Your answers make sense.

Digging a little deeper on the benefit of compressing (a la Abridged
Certs draft) the leaf cert or not. Definitely this draft improves vs
plain certificate compression, but I am trying to see if it is worth
the complexity of pass 2. So, section 4 shows a 2.5KB improvement over
plain compression which would be even more significant for Dilithium
certs, but I am trying to find if the diff between ICA
suppression/Compression vs ICA suppression/Compression+leaf
compression is significant. [/n]

I am arguing that the table 4 numbers would be much different when
talking about Dilithium certs because all of these numbers would be
inflated and any compression would have a small impact. Replacing a CA
cert (no SCTs) with a dictionary index would save us ~4KB (Dilithium2)
or 5.5KB (Dilithium3). That is significant. [/n]

Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB (Dilithium 3)) 
using any mechanism would trim down ~0.5-1KB compared to not compressing. That 
is because the PK and Sig can't be compressed and these account for most of the 
PQ leaf cert size. So, I am trying to see if pass 2 and compression of the leaf 
cert benefit us much.

I think there's a fairly big difference between suppressing CA certs in SCA and 
compressing CA certs with pass 1 of this draft. But I do agree its fair to ask 
if pass 2 is worth the extra effort.

The performance benefit isn't purely in the ~1KB saved, its whether it brings the 
chain under the QUIC amplification limit or shaves off an additional packet and so 
avoids a loss+retry. There's essentially no difference in implementation 
complexity, literally just a line of code, so the main tradeoff is the required 
disk space on the client & server.

Best,
Dennis



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression (dictionary versioning)

[Tim Hollebeek]

I wish root programs accepted roots from new CAs at a speed where a one year
old dictionary would be a problem.  Cross-certificates are already generally 
required 
for several years, on average.  However, cross-certificates are not ideal, as 
they increase 
server configuration problems and chain length, which as we've been discussing 
sometimes has performance impacts.

It's something I wish the industry would fix, and I'm glad that improvements in 
this 
area are getting discussed again at CABF.

But yes, we should be careful that we do not introduce a new mechanism that
would potentially add a new bottleneck to root ubiquity, even if it isn't and 
won't
be the long pole today.  Because we don't want it to become the long pole in the
future as the ecosystem continues to improve.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 9:31 PM
> To: Dennis Jackson ; TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression (dictionary versioning)
> 
> I wish there was a study of the certs issued by newly introduced CAs in CCADB
> and how quickly they ramp up. I am concerned that a 1 year old dictionary
> could end up slowing down a good amount of destinations. But again, that
> slowdown does not mean an outage. And servers could ensure they get their
> certs issued or cross-issued by relatively mature CAs if they do not want PQ 
> Sig
> related slowdowns.
> 
> Btw, in 3.1.1 I noticed
> - "Remove all intermediate certificates which are not signed by root 
> certificates
> still in the listing."
> 
> That could eliminate some 2+ ICA cert chains. Any reason why?
> 
> 
> 
> -Original Message-
> From: Dennis Jackson 
> Sent: Wednesday, July 12, 2023 1:01 PM
> To: Kampanakis, Panos ; TLS List 
> Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (dictionary
> versioning)
> 
> 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 04:54, Kampanakis, Panos wrote:
> 
> > Hi Dennis,
> >
> > Appendix B.1 talks about 100-200 new ICA and 10 Root certs per year. In
> the past I had looked at fluctuations of CCADB and there are daily changes.
> When checking in the past, I did not generate the ordered list as per pass 1 
> on
> a daily basis to confirm it, but I confirmed the fluctuations. The commits in
> https://github.com/FiloSottile/intermediates/commits/main  show it too.
> Given that, I am wondering if CCADB is not that stable. Are you confident that
> ICA dictionaries (based on CCADB) won't materially change often?
> 
> I checked the historical data for the last few years to ballpark a rate of 
> 100-200
> new intermediates per year. A uniform distribution of arrivals would mean 2 to
> 4 changes a week, which matches Filippo's commit frequency [1]. In practice
> Filippo's commits include removals (which we don't care about) and batched
> additions (which we do), but the numbers seem about right.
> 
> In terms of impact, the question is how much usage do those new ICAs see in
> their first year. If we expect websites to adopt them equally likely as 
> existing
> ICAs then they should make up <5% of the population. I think in practice they
> see much slower adoption and so the impact is even lower, for example a
> reasonable proportion are vanity certificates with limited applicability or
> intended to replace an existing cert in the future. If we wanted to confirm 
> this
> we could build the abridged cert dictionaries for '22 and then use CT to 
> sample
> the cert chains used by websites that year. I'll see if I can find the time 
> to put
> that together.
> 
> If there was an appetite for a faster moving dictionary, we could use the
> scheme I sketched in the appendix to the draft. But I think we should try to
> avoid that complexity if we can.
> 
> Best,
> Dennis
> 
> [1] https://github.com/FiloSottile/intermediates/graphs/commit-activity
> 
> ___
> 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

Re: [TLS] Abridged Certificate Compression

[Rob Stradling]

How about also including in the shared dictionary the SHA-256 hashes of the 
public keys of all the known CTv1 logs, so that the 32-byte LogID field of each 
SCT will be compressed?

FWIW, RFC9162 (CTv2) tackles the same SCT bloat by changing the LogID type from 
a (32-byte) SHA-256 hash of the log's public key to a (minimum 4-byte) 
DER-encoded OID (excluding the tag and length octets).


From: TLS  on behalf of Tim Hollebeek 

Sent: 12 July 2023 19:29
To: Kampanakis, Panos ; Dennis Jackson 
; TLS List 
Subject: Re: [TLS] Abridged Certificate Compression

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


SCTs have always seemed surprisingly large to me, and it has always seemed
like there should be a more compact representation that has the same security
properties, but I've never found the time to look more closely at it.  If 
someone
does have the time, figuring out how to reduce the size of SCTs would be quite
helpful.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:23 PM
> To: Dennis Jackson ; TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression
>
> > The performance benefit isn't purely in the ~1KB saved, its whether it 
> > brings
> the chain under the QUIC amplification limit or shaves off an additional 
> packet
> and so avoids a loss+retry. There's essentially no difference in 
> implementation
> complexity, literally just a line of code, so the main tradeoff is the 
> required disk
> space on the client & server.
>
> Fair. I would add one more tradeoff which is pulling the end-entity certs in 
> the
> CT window for pass 2. This is an one time cost for each dictionary version, so
> maybe not that bad.
>
> Regardless, would compressing the leaf bring us below the QUIC 3.6KB
> threshold for Dilithium 2 or 3 certs whereas not suppressing would keep us
> above? I think it is not even close if we are talking WebPKI. Without SCTs,
> maybe compressing could keep us below 4KB for Dilithium 2 leaf certs. But
> even then, if we add the CertVerify signature size we will be well over 4KB.
>
> Additionally, would compressing the leaf bring us below the 9-10KB threshold
> that Bas had tested to be an important inflection point? For WebPKI, it may
> the 8-9KB cert below 9KB if we add the CertVerify signature size. Maybe not. 
> It
> would need to tested. For Dilithium 3, maybe compression could render the
> 11-12KB cert below 9KB if we got lucky, maybe not, but if we add the
> CertVerify signature we won’t make it. For non-WebPKI, they will already be
> below 9-10KB.
>
> So, I am arguing that we can't remain below the QUIC threshold by
> compressing the leaf Dilithium cert. And we could remain below the 9-10KB
> only for Dilithium2 leaves.  I could be proven wrong if you have implemented
> it.
>
> 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.
>
>
>
>
> -Original Message-
> From: Dennis Jackson 
> Sent: Wednesday, July 12, 2023 12:39 PM
> To: Kampanakis, Panos ; TLS List 
> 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 04:34, Kampanakis, Panos wrote:
>
> > Thanks Dennis. Your answers make sense.
> >
> > Digging a little deeper on the benefit of compressing (a la Abridged
> > Certs draft) the leaf cert or not. Definitely this draft improves vs
> > plain certificate compression, but I am trying to see if it is worth
> > the complexity of pass 2. So, section 4 shows a 2.5KB improvement over
> > plain compression which would be even more significant for Dilithium
> > certs, but I am trying to find if the diff between ICA
> > suppression/Compression vs ICA suppression/Compression+leaf
> > compression is significant. [/n]
> >
> > I am arguing that the table 4 numbers would be much different when
> > talking about Dilithium certs because all of these numbers would be
> > inflated and any compression would have a small impact. Replacing a CA
> > cert (no SCTs) with a dictionary index would save us ~4KB (Dilithium2)
> > or 5.5KB (Dilithium3). That is significant. [/n]
> >
> > Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB (Dilithium 3))
> using an

Re: [TLS] Abridged Certificate Compression (dictionary versioning)

[Kampanakis, Panos]

I wish there was a study of the certs issued by newly introduced CAs in CCADB 
and how quickly they ramp up. I am concerned that a 1 year old dictionary could 
end up slowing down a good amount of destinations. But again, that slowdown 
does not mean an outage. And servers could ensure they get their certs issued 
or cross-issued by relatively mature CAs if they do not want PQ Sig related 
slowdowns. 

Btw, in 3.1.1 I noticed 
- "Remove all intermediate certificates which are not signed by root 
certificates still in the listing."

That could eliminate some 2+ ICA cert chains. Any reason why?



-Original Message-
From: Dennis Jackson  
Sent: Wednesday, July 12, 2023 1:01 PM
To: Kampanakis, Panos ; TLS List 
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (dictionary 
versioning)

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 04:54, Kampanakis, Panos wrote:

> Hi Dennis,
>
> Appendix B.1 talks about 100-200 new ICA and 10 Root certs per year. In the 
> past I had looked at fluctuations of CCADB and there are daily changes. When 
> checking in the past, I did not generate the ordered list as per pass 1 on a 
> daily basis to confirm it, but I confirmed the fluctuations. The commits in 
> https://github.com/FiloSottile/intermediates/commits/main  show it too. Given 
> that, I am wondering if CCADB is not that stable. Are you confident that ICA 
> dictionaries (based on CCADB) won't materially change often?

I checked the historical data for the last few years to ballpark a rate of 
100-200 new intermediates per year. A uniform distribution of arrivals would 
mean 2 to 4 changes a week, which matches Filippo's commit frequency [1]. In 
practice Filippo's commits include removals (which we don't care about) and 
batched additions (which we do), but the numbers seem about right.

In terms of impact, the question is how much usage do those new ICAs see in 
their first year. If we expect websites to adopt them equally likely as 
existing ICAs then they should make up <5% of the population. I think in 
practice they see much slower adoption and so the impact is even lower, for 
example a reasonable proportion are vanity certificates with limited 
applicability or intended to replace an existing cert in the future. If we 
wanted to confirm this we could build the abridged cert dictionaries for '22 
and then use CT to sample the cert chains used by websites that year. I'll see 
if I can find the time to put that together.

If there was an appetite for a faster moving dictionary, we could use the 
scheme I sketched in the appendix to the draft. But I think we should try to 
avoid that complexity if we can.

Best,
Dennis

[1] https://github.com/FiloSottile/intermediates/graphs/commit-activity

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Bas Westerbaan]

>
> On Wed, Jul 12, 2023, 11:31 AM Tim Hollebeek  40digicert@dmarc.ietf.org> wrote:
>
>> SCTs have always seemed surprisingly large to me, and it has always seemed
>> like there should be a more compact representation that has the same
>> security
>> properties, but I've never found the time to look more closely at it.  If
>> someone
>> does have the time, figuring out how to reduce the size of SCTs would be
>> quite
>> helpful.
>>
>
> I've always said SQI-Sign for this.
>

The 40ms verification time per SCT makes it a non-starter.

Best,

 Bas
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Watson Ladd]

On Wed, Jul 12, 2023, 11:31 AM Tim Hollebeek  wrote:

> SCTs have always seemed surprisingly large to me, and it has always seemed
> like there should be a more compact representation that has the same
> security
> properties, but I've never found the time to look more closely at it.  If
> someone
> does have the time, figuring out how to reduce the size of SCTs would be
> quite
> helpful.
>

I've always said SQI-Sign for this.

>
> -Tim
>
> > -Original Message-
> > From: TLS  On Behalf Of Kampanakis, Panos
> > Sent: Wednesday, July 12, 2023 2:23 PM
> > To: Dennis Jackson ; TLS List
> > 
> > Subject: Re: [TLS] Abridged Certificate Compression
> >
> > > The performance benefit isn't purely in the ~1KB saved, its whether it
> brings
> > the chain under the QUIC amplification limit or shaves off an additional
> packet
> > and so avoids a loss+retry. There's essentially no difference in
> implementation
> > complexity, literally just a line of code, so the main tradeoff is the
> required disk
> > space on the client & server.
> >
> > Fair. I would add one more tradeoff which is pulling the end-entity
> certs in the
> > CT window for pass 2. This is an one time cost for each dictionary
> version, so
> > maybe not that bad.
> >
> > Regardless, would compressing the leaf bring us below the QUIC 3.6KB
> > threshold for Dilithium 2 or 3 certs whereas not suppressing would keep
> us
> > above? I think it is not even close if we are talking WebPKI. Without
> SCTs,
> > maybe compressing could keep us below 4KB for Dilithium 2 leaf certs. But
> > even then, if we add the CertVerify signature size we will be well over
> 4KB.
> >
> > Additionally, would compressing the leaf bring us below the 9-10KB
> threshold
> > that Bas had tested to be an important inflection point? For WebPKI, it
> may
> > the 8-9KB cert below 9KB if we add the CertVerify signature size. Maybe
> not. It
> > would need to tested. For Dilithium 3, maybe compression could render the
> > 11-12KB cert below 9KB if we got lucky, maybe not, but if we add the
> > CertVerify signature we won’t make it. For non-WebPKI, they will already
> be
> > below 9-10KB.
> >
> > So, I am arguing that we can't remain below the QUIC threshold by
> > compressing the leaf Dilithium cert. And we could remain below the 9-10KB
> > only for Dilithium2 leaves.  I could be proven wrong if you have
> implemented
> > it.
> >
> > 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.
> >
> >
> >
> >
> > -Original Message-
> > From: Dennis Jackson 
> > Sent: Wednesday, July 12, 2023 12:39 PM
> > To: Kampanakis, Panos ; TLS List 
> > 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 04:34, Kampanakis, Panos wrote:
> >
> > > Thanks Dennis. Your answers make sense.
> > >
> > > Digging a little deeper on the benefit of compressing (a la Abridged
> > > Certs draft) the leaf cert or not. Definitely this draft improves vs
> > > plain certificate compression, but I am trying to see if it is worth
> > > the complexity of pass 2. So, section 4 shows a 2.5KB improvement over
> > > plain compression which would be even more significant for Dilithium
> > > certs, but I am trying to find if the diff between ICA
> > > suppression/Compression vs ICA suppression/Compression+leaf
> > > compression is significant. [/n]
> > >
> > > I am arguing that the table 4 numbers would be much different when
> > > talking about Dilithium certs because all of these numbers would be
> > > inflated and any compression would have a small impact. Replacing a CA
> > > cert (no SCTs) with a dictionary index would save us ~4KB (Dilithium2)
> > > or 5.5KB (Dilithium3). That is significant. [/n]
> > >
> > > Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB
> (Dilithium 3))
> > using any mechanism would trim down ~0.5-1KB compared to not
> > compressing. That is because the PK and Sig can't be compressed and these
> > account for most of the PQ leaf cer

Re: [TLS] Abridged Certificate Compression

[Tim Hollebeek]

SCTs have always seemed surprisingly large to me, and it has always seemed
like there should be a more compact representation that has the same security
properties, but I've never found the time to look more closely at it.  If 
someone
does have the time, figuring out how to reduce the size of SCTs would be quite 
helpful.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:23 PM
> To: Dennis Jackson ; TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression
> 
> > The performance benefit isn't purely in the ~1KB saved, its whether it 
> > brings
> the chain under the QUIC amplification limit or shaves off an additional 
> packet
> and so avoids a loss+retry. There's essentially no difference in 
> implementation
> complexity, literally just a line of code, so the main tradeoff is the 
> required disk
> space on the client & server.
> 
> Fair. I would add one more tradeoff which is pulling the end-entity certs in 
> the
> CT window for pass 2. This is an one time cost for each dictionary version, so
> maybe not that bad.
> 
> Regardless, would compressing the leaf bring us below the QUIC 3.6KB
> threshold for Dilithium 2 or 3 certs whereas not suppressing would keep us
> above? I think it is not even close if we are talking WebPKI. Without SCTs,
> maybe compressing could keep us below 4KB for Dilithium 2 leaf certs. But
> even then, if we add the CertVerify signature size we will be well over 4KB.
> 
> Additionally, would compressing the leaf bring us below the 9-10KB threshold
> that Bas had tested to be an important inflection point? For WebPKI, it may
> the 8-9KB cert below 9KB if we add the CertVerify signature size. Maybe not. 
> It
> would need to tested. For Dilithium 3, maybe compression could render the
> 11-12KB cert below 9KB if we got lucky, maybe not, but if we add the
> CertVerify signature we won’t make it. For non-WebPKI, they will already be
> below 9-10KB.
> 
> So, I am arguing that we can't remain below the QUIC threshold by
> compressing the leaf Dilithium cert. And we could remain below the 9-10KB
> only for Dilithium2 leaves.  I could be proven wrong if you have implemented
> it.
> 
> 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.
> 
> 
> 
> 
> -Original Message-
> From: Dennis Jackson 
> Sent: Wednesday, July 12, 2023 12:39 PM
> To: Kampanakis, Panos ; TLS List 
> 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 04:34, Kampanakis, Panos wrote:
> 
> > Thanks Dennis. Your answers make sense.
> >
> > Digging a little deeper on the benefit of compressing (a la Abridged
> > Certs draft) the leaf cert or not. Definitely this draft improves vs
> > plain certificate compression, but I am trying to see if it is worth
> > the complexity of pass 2. So, section 4 shows a 2.5KB improvement over
> > plain compression which would be even more significant for Dilithium
> > certs, but I am trying to find if the diff between ICA
> > suppression/Compression vs ICA suppression/Compression+leaf
> > compression is significant. [/n]
> >
> > I am arguing that the table 4 numbers would be much different when
> > talking about Dilithium certs because all of these numbers would be
> > inflated and any compression would have a small impact. Replacing a CA
> > cert (no SCTs) with a dictionary index would save us ~4KB (Dilithium2)
> > or 5.5KB (Dilithium3). That is significant. [/n]
> >
> > Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB (Dilithium 3))
> using any mechanism would trim down ~0.5-1KB compared to not
> compressing. That is because the PK and Sig can't be compressed and these
> account for most of the PQ leaf cert size. So, I am trying to see if pass 2 
> and
> compression of the leaf cert benefit us much.
> 
> I think there's a fairly big difference between suppressing CA certs in SCA 
> and
> compressing CA certs with pass 1 of this draft. But I do agree its fair to 
> ask if
> pass 2 is worth the extra effort.
> 
> The performance benefit isn't purely in the ~1KB saved, its whether it brings
> the chain under the QUIC amplification limit or shaves off an additional 
> packet
> and so avoids a loss+retry. There's essentially no differ

Re: [TLS] Abridged Certificate Compression (server participation)

[Tim Hollebeek]

Honestly, people can blame all sorts of things for the OCSP stapling problems,
but there was nothing inherently wrong with the approach.  The implementations
were just pretty poor due to issues Hubert Kario correctly outlined.  In 
general,
the needs of server operators and maintainers of server software and the
challenges they face are not always taken into account as well as they should 
be.

I think the best way to avoid those problems in this case would be to get up 
front
buy-in from one or two major server software implementors, to make sure they
agree with the approach and would be willing to implement it.

I'm also very happy with the recent efforts in the ecosystem to increase 
transparency around all the existing intermediate CAs, and the fact that this 
enables this sort of technology going forward.  There are a bunch of 
interesting 
points in this thread that I look forward to thinking more about and discussing 
in a few weeks.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:01 PM
> To: Dennis Jackson ; TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression (server participation)
> 
> Imo, the dictionary approach a simple way of trimming down the PQ auth
> data. And your argument for the frequency of synching OCSP staples vs these
> certs is a good one. I hope TLS termination points will agree if this moves
> forward, but personally I don't find the approach too bad.
> 
> -Original Message-
> From: TLS  On Behalf Of Dennis Jackson
> Sent: Wednesday, July 12, 2023 1:16 PM
> To: Kampanakis, Panos ; TLS List
> 
> Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (server
> participation)
> 
> 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 05:02, Kampanakis, Panos wrote:
> 
> > The abridged certs draft requires a server who participates and fetches
> dictionaries in order to make client connections faster. As Bas has pointed 
> out
> before, this paradigm did not work well with OSCP staples in the past. Servers
> did not chose to actively participate and go fetch them.
> >
> > Are we confident that servers would deploy the dictionary fetching
> mechanism to benefit their connecting clients?
> 
> I think OCSP staples is quite a bit different from this draft. OCSP Staples
> requires the server to fetch new data from the CA every day or week. It's
> inherently hard to do this reliably, especially with the large number of poor
> quality or poorly maintained OCSP servers and the large fraction of operators
> who do not want their servers making outbound connections. Besides these
> barriers I don't think the benefit was huge as clients already cached OCSP
> responses for up to a week so at most it was speeding up one connection per
> client per week (this was before network partitioning in browsers) and at
> worst it was breaking your website entirely.
> 
> In contrast, this draft aims to speed up every connection that isn't using
> session tickets, cause no harm if its misconfigured or out of date and be slow
> moving enough that the dictionaries can be shipped as part of a regular
> software release and so suitable for anyone willing to update their server
> software once a year (or less). Similarly, these updates aren't going to 
> involve
> code changes, just changes to the static dictionaries, so they are suitable 
> for
> backporting or ESR releases.
> 
> It would definitely be good to hear from maintainers or smaller operators if
> they have concerns though!
> 
> ___
> 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

Re: [TLS] Abridged Certificate Compression

[Kampanakis, Panos]

> The performance benefit isn't purely in the ~1KB saved, its whether it brings 
> the chain under the QUIC amplification limit or shaves off an additional 
> packet and so avoids a loss+retry. There's essentially no difference in 
> implementation complexity, literally just a line of code, so the main 
> tradeoff is the required disk space on the client & server.

Fair. I would add one more tradeoff which is pulling the end-entity certs in 
the CT window for pass 2. This is an one time cost for each dictionary version, 
so maybe not that bad. 

Regardless, would compressing the leaf bring us below the QUIC 3.6KB threshold 
for Dilithium 2 or 3 certs whereas not suppressing would keep us above? I think 
it is not even close if we are talking WebPKI. Without SCTs, maybe compressing 
could keep us below 4KB for Dilithium 2 leaf certs. But even then, if we add 
the CertVerify signature size we will be well over 4KB. 

Additionally, would compressing the leaf bring us below the 9-10KB threshold 
that Bas had tested to be an important inflection point? For WebPKI, it may the 
8-9KB cert below 9KB if we add the CertVerify signature size. Maybe not. It 
would need to tested. For Dilithium 3, maybe compression could render the 
11-12KB cert below 9KB if we got lucky, maybe not, but if we add the CertVerify 
signature we won’t make it. For non-WebPKI, they will already be below 9-10KB.

So, I am arguing that we can't remain below the QUIC threshold by compressing 
the leaf Dilithium cert. And we could remain below the 9-10KB only for 
Dilithium2 leaves.  I could be proven wrong if you have implemented it. 

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. 




-Original Message-
From: Dennis Jackson  
Sent: Wednesday, July 12, 2023 12:39 PM
To: Kampanakis, Panos ; TLS List 
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 04:34, Kampanakis, Panos wrote:

> Thanks Dennis. Your answers make sense.
>
> Digging a little deeper on the benefit of compressing (a la Abridged 
> Certs draft) the leaf cert or not. Definitely this draft improves vs 
> plain certificate compression, but I am trying to see if it is worth 
> the complexity of pass 2. So, section 4 shows a 2.5KB improvement over 
> plain compression which would be even more significant for Dilithium 
> certs, but I am trying to find if the diff between ICA 
> suppression/Compression vs ICA suppression/Compression+leaf 
> compression is significant. [/n]
>
> I am arguing that the table 4 numbers would be much different when 
> talking about Dilithium certs because all of these numbers would be 
> inflated and any compression would have a small impact. Replacing a CA 
> cert (no SCTs) with a dictionary index would save us ~4KB (Dilithium2) 
> or 5.5KB (Dilithium3). That is significant. [/n]
>
> Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB (Dilithium 3)) 
> using any mechanism would trim down ~0.5-1KB compared to not compressing. 
> That is because the PK and Sig can't be compressed and these account for most 
> of the PQ leaf cert size. So, I am trying to see if pass 2 and compression of 
> the leaf cert benefit us much.

I think there's a fairly big difference between suppressing CA certs in SCA and 
compressing CA certs with pass 1 of this draft. But I do agree its fair to ask 
if pass 2 is worth the extra effort.

The performance benefit isn't purely in the ~1KB saved, its whether it brings 
the chain under the QUIC amplification limit or shaves off an additional packet 
and so avoids a loss+retry. There's essentially no difference in implementation 
complexity, literally just a line of code, so the main tradeoff is the required 
disk space on the client & server.

Best,
Dennis

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression (server participation)

[Kampanakis, Panos]

Imo, the dictionary approach a simple way of trimming down the PQ auth data. 
And your argument for the frequency of synching OCSP staples vs these certs is 
a good one. I hope TLS termination points will agree if this moves forward, but 
personally I don't find the approach too bad. 

-Original Message-
From: TLS  On Behalf Of Dennis Jackson
Sent: Wednesday, July 12, 2023 1:16 PM
To: Kampanakis, Panos ; TLS List 

Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (server 
participation)

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 05:02, Kampanakis, Panos wrote:

> The abridged certs draft requires a server who participates and fetches 
> dictionaries in order to make client connections faster. As Bas has pointed 
> out before, this paradigm did not work well with OSCP staples in the past. 
> Servers did not chose to actively participate and go fetch them.
>
> Are we confident that servers would deploy the dictionary fetching mechanism 
> to benefit their connecting clients?

I think OCSP staples is quite a bit different from this draft. OCSP Staples 
requires the server to fetch new data from the CA every day or week. It's 
inherently hard to do this reliably, especially with the large number of poor 
quality or poorly maintained OCSP servers and the large fraction of operators 
who do not want their servers making outbound connections. Besides these 
barriers I don't think the benefit was huge as clients already cached OCSP 
responses for up to a week so at most it was speeding up one connection per 
client per week (this was before network partitioning in browsers) and at worst 
it was breaking your website entirely.

In contrast, this draft aims to speed up every connection that isn't using 
session tickets, cause no harm if its misconfigured or out of date and be slow 
moving enough that the dictionaries can be shipped as part of a regular 
software release and so suitable for anyone willing to update their server 
software once a year (or less). Similarly, these updates aren't going to 
involve code changes, just changes to the static dictionaries, so they are 
suitable for backporting or ESR releases.

It would definitely be good to hear from maintainers or smaller operators if 
they have concerns though!

___
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

Re: [TLS] Abridged Certificate Compression (server participation)

[Dennis Jackson]

On 12/07/2023 05:02, Kampanakis, Panos wrote:


The abridged certs draft requires a server who participates and fetches 
dictionaries in order to make client connections faster. As Bas has pointed out 
before, this paradigm did not work well with OSCP staples in the past. Servers 
did not chose to actively participate and go fetch them.

Are we confident that servers would deploy the dictionary fetching mechanism to 
benefit their connecting clients?


I think OCSP staples is quite a bit different from this draft. OCSP 
Staples requires the server to fetch new data from the CA every day or 
week. It's inherently hard to do this reliably, especially with the 
large number of poor quality or poorly maintained OCSP servers and the 
large fraction of operators who do not want their servers making 
outbound connections. Besides these barriers I don't think the benefit 
was huge as clients already cached OCSP responses for up to a week so at 
most it was speeding up one connection per client per week (this was 
before network partitioning in browsers) and at worst it was breaking 
your website entirely.


In contrast, this draft aims to speed up every connection that isn't 
using session tickets, cause no harm if its misconfigured or out of date 
and be slow moving enough that the dictionaries can be shipped as part 
of a regular software release and so suitable for anyone willing to 
update their server software once a year (or less). Similarly, these 
updates aren't going to involve code changes, just changes to the static 
dictionaries, so they are suitable for backporting or ESR releases.


It would definitely be good to hear from maintainers or smaller 
operators if they have concerns though!


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression (dictionary versioning)

[Dennis Jackson]

On 12/07/2023 04:54, Kampanakis, Panos wrote:


Hi Dennis,

Appendix B.1 talks about 100-200 new ICA and 10 Root certs per year. In the 
past I had looked at fluctuations of CCADB and there are daily changes. When 
checking in the past, I did not generate the ordered list as per pass 1 on a 
daily basis to confirm it, but I confirmed the fluctuations. The commits in 
https://github.com/FiloSottile/intermediates/commits/main  show it too. Given 
that, I am wondering if CCADB is not that stable. Are you confident that ICA 
dictionaries (based on CCADB) won't materially change often?


I checked the historical data for the last few years to ballpark a rate 
of 100-200 new intermediates per year. A uniform distribution of 
arrivals would mean 2 to 4 changes a week, which matches Filippo's 
commit frequency [1]. In practice Filippo's commits include removals 
(which we don't care about) and batched additions (which we do), but the 
numbers seem about right.


In terms of impact, the question is how much usage do those new ICAs see 
in their first year. If we expect websites to adopt them equally likely 
as existing ICAs then they should make up <5% of the population. I think 
in practice they see much slower adoption and so the impact is even 
lower, for example a reasonable proportion are vanity certificates with 
limited applicability or intended to replace an existing cert in the 
future. If we wanted to confirm this we could build the abridged cert 
dictionaries for '22 and then use CT to sample the cert chains used by 
websites that year. I'll see if I can find the time to put that together.


If there was an appetite for a faster moving dictionary, we could use 
the scheme I sketched in the appendix to the draft. But I think we 
should try to avoid that complexity if we can.


Best,
Dennis

[1] https://github.com/FiloSottile/intermediates/graphs/commit-activity

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

On 12/07/2023 04:34, Kampanakis, Panos wrote:


Thanks Dennis. Your answers make sense.

Digging a little deeper on the benefit of compressing (a la Abridged Certs 
draft) the leaf cert or not. Definitely this draft improves vs plain 
certificate compression, but I am trying to see if it is worth the complexity 
of pass 2. So, section 4 shows a 2.5KB improvement over plain compression which 
would be even more significant for Dilithium certs, but I am trying to find if 
the diff between ICA suppression/Compression vs ICA 
suppression/Compression+leaf compression is significant. [/n]

I am arguing that the table 4 numbers would be much different when talking 
about Dilithium certs because all of these numbers would be inflated and any 
compression would have a small impact. Replacing a CA cert (no SCTs) with a 
dictionary index would save us ~4KB (Dilithium2) or 5.5KB (Dilithium3). That is 
significant. [/n]

Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB (Dilithium 3)) 
using any mechanism would trim down ~0.5-1KB compared to not compressing. That 
is because the PK and Sig can't be compressed and these account for most of the 
PQ leaf cert size. So, I am trying to see if pass 2 and compression of the leaf 
cert benefit us much.


I think there's a fairly big difference between suppressing CA certs in 
SCA and compressing CA certs with pass 1 of this draft. But I do agree 
its fair to ask if pass 2 is worth the extra effort.


The performance benefit isn't purely in the ~1KB saved, its whether it 
brings the chain under the QUIC amplification limit or shaves off an 
additional packet and so avoids a loss+retry. There's essentially no 
difference in implementation complexity, literally just a line of code, 
so the main tradeoff is the required disk space on the client & server.


Best,
Dennis

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression (server participation)

[Hubert Kario]

On Wednesday, 12 July 2023 06:02:09 CEST, Kampanakis, Panos wrote:

Hi Dennis,

One more topic for general discussion.

The abridged certs draft requires a server who participates and 
fetches dictionaries in order to make client connections faster. 
As Bas has pointed out before, this paradigm did not work well 
with OSCP staples in the past. Servers did not chose to actively 
participate and go fetch them. 


The problem with OCSP staples is that it has little immediate benefit for 
the

server operator, so there was no strong push to:

1. get it implemented in the TLS libraries
2. have it implemented in the web servers
3. backport those changes to stable branches (of both libraries and web 
servers)

4. either rebase or backport the changes to long-term support Linux
  distributions

It takes years for such changes to trickle down.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

On 12/07/2023 11:01, Ilari Liusvaara wrote:


On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote:

TLS Certificate Compression influences the transcript for the decompressing
party, as the output is the Certificate message which is used in the
transcript.

RFC 8879 does not alter how transcript is computed in any way.


Firstly, all extensions added to the ClientHello influence the 
transcript as the body of the CH message is included in the transcript.


Secondly, RFC 8879 specifies a CompressedCertificate message which is 
the result of applying the negotiated compression algorithm to the 
original Certificate message. The receiver of the CompressedCertificate 
message will decompress it and include the resulting Certificate message 
in their transcript. Consequently, for one party use of RFC 8879 will 
influence the transcript.



An extension altering computation of transcript would be truly
extraordinary.


You might find 6.1.5 and 7.2 of 
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ an interesting 
read :-).


Best, Dennis
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Ilari Liusvaara]

On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote:
> Hi Ilari,
> 
> On 10/07/2023 20:19, Ilari Liusvaara wrote:
> > What does "Note that the connection will fail regardless even if this
> > step is not taken as neither certificate validation nor transcript
> > validation can succeed." mean? TLS certificate compression does not
> > do anything special with transcript, so transcript validation should
> > always succeed.
> 
> TLS Certificate Compression influences the transcript for the decompressing
> party, as the output is the Certificate message which is used in the
> transcript. So if the Certificate message is incorrectly formatted, then the
> the decompressing party will likely bail when passing it to the TLS library.
> Even if they succeed and try to use it in a transcript calculation, the
> compressing party's transcript includes the uncompressed certificate
> directly and so will differ.

RFC 8879 does not alter how transcript is computed in any way.

An extension altering computation of transcript would be truly
extraordinary.

 
> > And are there zstd decoders that can reuse output buffer in oneshot
> > decompression for lookback? The zstd command line tool manual page
> > mentions default 128MB memory limit for decompression. I presume
> > mostly for lookback. Such limit is way too large.
> Zstd is already supported without a dictionary for TLS Certificate
> Compression so others with deployment experience may be able to give an
> authoritative answer. That said, Facebook's Zstd implementation is
> permissively licensed, used in the Linux Kernel and their discussion here
>  suggests much smaller limits
> are fine.

Actually, that issue pointed to the API I was looking for. And looks
like memory requirement is something like <300kB.


> > And an alternative idea:
> > 
> > [...]
> > 
> > 1) Where if next certificate in chain is also not found, zstd uses
> > empty dictionary. Otherwise it uses dictionary associated with the
> > next certificate in chain.
> > 
> > [...]
> > 
> > This allows dictionaries to be specific to CA, avoiding tradeoffs
> > between CAs.
> 
> Interesting idea! Can you share more about the motivation for using many
> small dictionaries rather than a single combined one? Is it purely for
> supporting memory constrained devices? We can already ensure that each CA
> contributes an equal number of bytes to the pass 2 dictionary.
> 
> One drawback is that some of the data isn't unique to a particular issuer
> (e.g. the CT log ids) and so would either have to be handled in its own pass
> or be included as redundant data in each individual dictionary.

I was assuming that including all the CA-specific stuff across all CAs
would cause the dictionary to grow quite large. And I think smaller
dictionaries that still have everything needed give slightly better
compression.

And it is possible to do constructions like dictionary = common_part ||
ca_specific_part. With possibly common_part being the dictionary used on
next certificate not found.





-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Abridged Certificate Compression (server participation)

[Kampanakis, Panos]

Hi Dennis,

One more topic for general discussion.

The abridged certs draft requires a server who participates and fetches 
dictionaries in order to make client connections faster. As Bas has pointed out 
before, this paradigm did not work well with OSCP staples in the past. Servers 
did not chose to actively participate and go fetch them. 

Are we confident that servers would deploy the dictionary fetching mechanism to 
benefit their connecting clients?



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Abridged Certificate Compression (dictionary versioning)

[Kampanakis, Panos]

Hi Dennis, 

Spinning up a new thread since this is a different topic. 

Section 5.1 talks about the dictionary versioning approach and suggests an 
annual cadence is enough. The issue of an up-to-date cache was a big concern 
for the ICA Suppression draft, and rightfully so. A stale dictionary does not 
cause an outage in the abridged case, but it does eliminate the benefit. 

Appendix B.1 talks about 100-200 new ICA and 10 Root certs per year. In the 
past I had looked at fluctuations of CCADB and there are daily changes. When 
checking in the past, I did not generate the ordered list as per pass 1 on a 
daily basis to confirm it, but I confirmed the fluctuations. The commits in 
https://github.com/FiloSottile/intermediates/commits/main  show it too. Given 
that, I am wondering if CCADB is not that stable. Are you confident that ICA 
dictionaries (based on CCADB) won't materially change often? 


-Original Message-
From: TLS  On Behalf Of Kampanakis, Panos
Sent: Tuesday, July 11, 2023 11:34 PM
To: Dennis Jackson ; Dennis Jackson 
; TLS List 
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.



Thanks Dennis. Your answers make sense.

Digging a little deeper on the benefit of compressing (a la Abridged Certs 
draft) the leaf cert or not. Definitely this draft improves vs plain 
certificate compression, but I am trying to see if it is worth the complexity 
of pass 2. So, section 4 shows a 2.5KB improvement over plain compression which 
would be even more significant for Dilithium certs, but I am trying to find if 
the diff between ICA suppression/Compression vs ICA 
suppression/Compression+leaf compression is significant. I am arguing that the 
table 4 numbers would be much different when talking about Dilithium certs 
because all of these numbers would be inflated and any compression would have a 
small impact. Replacing a CA cert (no SCTs) with a dictionary index would save 
us ~4KB (Dilithium2) or 5.5KB (Dilithium3). That is significant. Compressing 
the leaf (of size 8-9KB (Dilithium2) or 11-12 KB (Dilithium 3)) using any 
mechanism would trim down ~0.5-1KB compared to not compressing. That is because 
the PK and Sig can't 
  be compressed and these account for most of the PQ leaf cert size. So, I am 
trying to see if pass 2 and compression of the leaf cert benefit us much.

Where I am going with this is that if the benefit of leaf compression from the 
Abridged Mechanism is not significant, I would like to use your abridged 
dictionary for ICA suppression only because it does not suffer from outages. 
So, am I wrong in claiming that compressing a Dilithium leaf cert compared to 
sending it as-is saves us a lot of data?

If MTCs came to fruition I think they would do pretty well without the abridged 
certs, but the abridged certs have the advantage that they can be implemented 
for WebPKI or elsewhere which is important.


-Original Message-
From: Dennis Jackson 
Sent: Monday, July 10, 2023 7:23 AM
To: Kampanakis, Panos ; Dennis Jackson 
; TLS List 
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.



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 w

Re: [TLS] Abridged Certificate Compression

[Eric Rescorla]

On Tue, Jul 11, 2023 at 2:09 PM Dennis Jackson 
wrote:

> On 11/07/2023 21:17, Eric Rescorla wrote:
>
> I wouldn't want to 'permanently' encode the root programs, CT
> trusted log lists or end entity compressed extensions for example.
>
>
> Arguably it will be necessary to encode the database in the final RFC.
> Otherwise, you have what is effectively a normative reference to the
> contents of the CCADB.
>
> I haven't thought through this completely, but I mention it because it
> may affect the rest of the design decisions if we end up with the
> WG having to produce the database.
>
> To clarify: I'm fine with encoding things permanently in an RFC for use
> with a specific code point. I just wouldn't want to do that for multiple
> future code points to be used in future years since predicting developments
> is inherently hard.
>

That seems sensible.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

On 11/07/2023 21:17, Eric Rescorla wrote:


I wouldn't want to 'permanently' encode the root programs, CT
trusted log lists or end entity compressed extensions for example.


Arguably it will be necessary to encode the database in the final RFC.
Otherwise, you have what is effectively a normative reference to the
contents of the CCADB.

I haven't thought through this completely, but I mention it because it
may affect the rest of the design decisions if we end up with the
WG having to produce the database.


To clarify: I'm fine with encoding things permanently in an RFC for use 
with a specific code point. I just wouldn't want to do that for multiple 
future code points to be used in future years since predicting 
developments is inherently hard.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

Hi Ilari,

On 10/07/2023 20:19, Ilari Liusvaara wrote:

What does "Note that the connection will fail regardless even if this
step is not taken as neither certificate validation nor transcript
validation can succeed." mean? TLS certificate compression does not
do anything special with transcript, so transcript validation should
always succeed.


TLS Certificate Compression influences the transcript for the 
decompressing party, as the output is the Certificate message which is 
used in the transcript. So if the Certificate message is incorrectly 
formatted, then the the decompressing party will likely bail when 
passing it to the TLS library. Even if they succeed and try to use it in 
a transcript calculation, the compressing party's transcript includes 
the uncompressed certificate directly and so will differ.



And are there zstd decoders that can reuse output buffer in oneshot
decompression for lookback? The zstd command line tool manual page
mentions default 128MB memory limit for decompression. I presume
mostly for lookback. Such limit is way too large.
Zstd is already supported without a dictionary for TLS Certificate 
Compression so others with deployment experience may be able to give an 
authoritative answer. That said, Facebook's Zstd implementation is 
permissively licensed, used in the Linux Kernel and their discussion 
here  suggests much 
smaller limits are fine.

And an alternative idea:

[...]

1) Where if next certificate in chain is also not found, zstd uses
empty dictionary. Otherwise it uses dictionary associated with the
next certificate in chain.

[...]

This allows dictionaries to be specific to CA, avoiding tradeoffs
between CAs.


Interesting idea! Can you share more about the motivation for using many 
small dictionaries rather than a single combined one? Is it purely for 
supporting memory constrained devices? We can already ensure that each 
CA contributes an equal number of bytes to the pass 2 dictionary.


One drawback is that some of the data isn't unique to a particular 
issuer (e.g. the CT log ids) and so would either have to be handled in 
its own pass or be included as redundant data in each individual 
dictionary.


Best,
Dennis
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Eric Rescorla]

On Tue, Jul 11, 2023 at 12:45 PM Dennis Jackson  wrote:

> On 11/07/2023 15:48, Thom Wiggers wrote:
>
> > I enjoyed reading this draft. I think it is well-written. Aside from
> > some to-be-figured-out details that have already been pointed out, it
> > seems very practical, which is rather nice.
> Thanks!
> >
> > The one thing that makes me frown a bit is the intended versioning
> > scheme. I don't think consuming identifiers is a problem, but perhaps
> > we can pre-define the code points and variables for the next, say,
> > N=0xff years? Then the versioning mechanism is set for the foreseeable
> > future.
>
> I like the reduction of bookkeeping but I think we would need to work
> out which parts of the construction to make dynamic with an IANA
> registry. I wouldn't want to 'permanently' encode the root programs, CT
> trusted log lists or end entity compressed extensions for example.
>
> I don't really have a sense of what the idiomatic IETF solution is for
> this problem, so I settled for seemed like the least commitment method
> in the draft.
>

Arguably it will be necessary to encode the database in the final RFC.
Otherwise, you have what is effectively a normative reference to the
contents of the CCADB.

I haven't thought through this completely, but I mention it because it
may affect the rest of the design decisions if we end up with the
WG having to produce the database.

> (You could even say that we wrap the code points after N years).
>
> I don't know whether there'll be interest in using this scheme outside
> TLS (e.g. reducing storage / bandwidth costs in CT) but if there is then
> we'll probably want identifiers which are unambiguous over long timescales.
>

I'm not worried about code point exhaustion. Say we issued a new version
every 3 months and allocated a block of 256 code points, we would be
able to go without changes for 64 years.

-Ekr


>
> Best,
> Dennis
>
> ___
> 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

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

On 11/07/2023 15:48, Thom Wiggers wrote:

I enjoyed reading this draft. I think it is well-written. Aside from 
some to-be-figured-out details that have already been pointed out, it 
seems very practical, which is rather nice.

Thanks!


The one thing that makes me frown a bit is the intended versioning 
scheme. I don't think consuming identifiers is a problem, but perhaps 
we can pre-define the code points and variables for the next, say, 
N=0xff years? Then the versioning mechanism is set for the foreseeable 
future.


I like the reduction of bookkeeping but I think we would need to work 
out which parts of the construction to make dynamic with an IANA 
registry. I wouldn't want to 'permanently' encode the root programs, CT 
trusted log lists or end entity compressed extensions for example.


I don't really have a sense of what the idiomatic IETF solution is for 
this problem, so I settled for seemed like the least commitment method 
in the draft.



(You could even say that we wrap the code points after N years).


I don't know whether there'll be interest in using this scheme outside 
TLS (e.g. reducing storage / bandwidth costs in CT) but if there is then 
we'll probably want identifiers which are unambiguous over long timescales.


Best,
Dennis

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

On 11/07/2023 01:00, Eric Rescorla wrote:

My sense is that we would be better off getting the data from CCADB, 
as CAs will have a clear incentive to populate it, as their customers 
will get better performance.


However, I think this is a question the WG is well suited to resolve 
and that we could adopt the document as-is and sort this out later.


Thanks, I filed #7 
 
to keep track of this.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Thom Wiggers]

Hi Dennis,

I enjoyed reading this draft. I think it is well-written. Aside from some
to-be-figured-out details that have already been pointed out, it seems very
practical, which is rather nice.

The one thing that makes me frown a bit is the intended versioning scheme.
I don't think consuming identifiers is a problem, but perhaps we can
pre-define the code points and variables for the next, say, N=0xff years?
Then the versioning mechanism is set for the foreseeable future. (You could
even say that we wrap the code points after N years).

Cheers,

Thom

Op vr 7 jul 2023 om 00:18 schreef Dennis Jackson :

> 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

Re: [TLS] Abridged Certificate Compression

[Eric Rescorla]

On Mon, Jul 10, 2023 at 10:54 AM Dennis Jackson 
wrote:

>
> On 07/07/2023 21:28, Eric Rescorla wrote:
>
> 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.
>>
>> It seemed the fairest repeatable way to check whether a CA was offering
>> certificates to WebPKI clients without having to write a lot of emails. I
>> agree its not desirable to keep as a dependency in the long run.
>>
> Can you elaborate on the concern here? I.e., is it that we will
> overinclude or underinclude if we just use CCADB?
>
> Sorry, this answer came out garbled. Using CT gives two things:
>
> 1) There are large extensions in end-entity certs which are specific to
> the issuer and change little between certs. For example, the URLs for OCSP,
> CRL and the practice statement are typically the same. Using CT logs lets
> me pull out an example of each extension for that CA without having to
> write a bunch of mails to ask them to produce them in the right format.
>
> 2) I don't personally have concerns about the dictionary size and would
> prefer to include every CA. However, if someone were to have strong
> feelings about this then using CT to measure popularity is much fairer than
> say scanning popular domains from the Tranco list or whatever.
>
> In the long term, I hope this could just be removed and ideally the CA's
> themselves provide a fixed size binary blob via CCADB that they'd like
> compressed out of their certs.
>
Thanks for the explanation. It sounds like we agree that it would be best
not to have this piece and we just have different assessments of how hard
it will be to get CCADB populated with this data. My sense is that we would
be better off getting the data from CCADB, as CAs will have a clear
incentive to populate it, as their customers will get better performance.
However, I think this is a question the WG is well suited to resolve and
that we could adopt the document as-is and sort this out later.

-Ekr

Best,
> Dennis
>
>
> Thanks,
> -Ekr
>
> S 5.1.
>> ISTM that there are plenty of code points available.
>>
>> Thanks!
>>
>> Best,
>> Dennis
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jul 6, 2023 at 3:18 PM Dennis Jackson > 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:
>>> 

Re: [TLS] Abridged Certificate Compression

[Ilari Liusvaara]

On Thu, Jul 06, 2023 at 11:18:01PM +0100, 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.

What does "Note that the connection will fail regardless even if this
step is not taken as neither certificate validation nor transcript
validation can succeed." mean? TLS certificate compression does not
do anything special with transcript, so transcript validation should
always succeed.


And are there zstd decoders that can reuse output buffer in oneshot
decompression for lookback? The zstd command line tool manual page
mentions default 128MB memory limit for decompression. I presume
mostly for lookback. Such limit is way too large. 


And an alternative idea:

The compressed stream is concatenation of two kinds of certificate
entries:

1) If certificate is not found in dictionary:

   opaque zstd_compressed_cert<1..16711679>;
   opaque extensions<0..65535>;

   Where if next certificate in chain is also not found, zstd uses
   empty dictionary. Otherwise it uses dictionary associated with the
   next certificate in chain.

2) If certificate is found in dictionary:

   uint8 always_0xff = 255;
   uint16 dictionary_index;
   opaque extensions<0..65535>;
  
The overall length is not compressed, because compressed_certificate
message already has it.

This allows dictionaries to be specific to CA, avoiding tradeoffs
between CAs.


As illustration, minimal compressed certificate message for certificate
issued by Let's Encrypt E1:

- 4 byte message header.
- 2 byte compression algorithm.
- 3 byte uncompressed length.
- 3 byte length of EE certificate.
- X byte zstd compressed certificate using dictionary for Let's Encrypt
  E1.
- 2 byte extension block length.
- 0 byte extension block.
- 3 byte entry for Let's Encrypt E1.
- 2 byte extension block length.
- 0 byte extension block.
- 3 byte entry for ISRG Root X2.
- 2 byte extension block length.
- 0 byte extension block.

Total: 24 + X bytes.



> 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




-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

On 07/07/2023 21:28, Eric Rescorla wrote:



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.


It seemed the fairest repeatable way to check whether a CA was
offering certificates to WebPKI clients without having to write a
lot of emails. I agree its not desirable to keep as a dependency
in the long run.

Can you elaborate on the concern here? I.e., is it that we will 
overinclude or underinclude if we just use CCADB?


Sorry, this answer came out garbled. Using CT gives two things:

1) There are large extensions in end-entity certs which are specific to 
the issuer and change little between certs. For example, the URLs for 
OCSP, CRL and the practice statement are typically the same. Using CT 
logs lets me pull out an example of each extension for that CA without 
having to write a bunch of mails to ask them to produce them in the 
right format.


2) I don't personally have concerns about the dictionary size and would 
prefer to include every CA. However, if someone were to have strong 
feelings about this then using CT to measure popularity is much fairer 
than say scanning popular domains from the Tranco list or whatever.


In the long term, I hope this could just be removed and ideally the CA's 
themselves provide a fixed size binary blob via CCADB that they'd like 
compressed out of their certs.


Best,
Dennis



Thanks,
-Ekr


S 5.1.
ISTM that there are plenty of code points available.


Thanks!

Best,
Dennis









On Thu, Jul 6, 2023 at 3: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:
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 

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

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

Re: [TLS] Abridged Certificate Compression

[Kampanakis, Panos]

Hi Dennis, 

This is an interesting draft. 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. As you point out in the draft, cTLS uses something similar as well. 
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. 

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. 

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?

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. 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?

Rgs,
Panos

[1] 
https://github.com/csosto-pk/tls-suppress-intermediates/issues/17#issue-1671378265
 



-Original Message-
From: TLS  On Behalf Of Dennis Jackson
Sent: Thursday, July 6, 2023 6:18 PM
To: TLS List 
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

Re: [TLS] Abridged Certificate Compression

[Eric Rescorla]

On Fri, Jul 7, 2023 at 1:21 PM Dennis Jackson 
wrote:

> Thank you for the comments. I'll fix most of them - responses inline for
> the rest:
>
> On 07/07/2023 17:38, Eric Rescorla wrote:
>
> 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?
>
> Possibly a premature optimization, but I was thinking that if a new
> version only included new certificates, it'd be nice to only have to append
> the new data to the existing dictionaries. I haven't yet worked out if
> that's actually going to deliver anything useful though.
>

Fair enough.


>
>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 0xff. That's probably
> not a problem, but I think you should make it clear and have some
> way to manage it.
>
> If the length is corrected, isn't the only risk a collision with a
> certificate which is exactly three bytes and starts with 0xff?
>
Ah yes, I had forgotten about the length value. This indeed seems fine.

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.
>
> It seemed the fairest repeatable way to check whether a CA was offering
> certificates to WebPKI clients without having to write a lot of emails. I
> agree its not desirable to keep as a dependency in the long run.
>
Can you elaborate on the concern here? I.e., is it that we will overinclude
or underinclude if we just use CCADB?

Thanks,
-Ekr

S 5.1.
> ISTM that there are plenty of code points available.
>
> Thanks!
>
> Best,
> Dennis
>
>
>
>
>
>
>
>
> On Thu, Jul 6, 2023 at 3:18 PM Dennis Jackson  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
>> > 

Re: [TLS] Abridged Certificate Compression

[Salz, Rich]

> I don't follow your comment about the handling of extensions, the code 
doing the compression and decompression isn't aware of what an extension 
is or handling them specially, its just swapping strings. In order to 
compress the larger strings which issuers add to end entity certificates

So, you're pulling out common substrings to make the dictionary more efficient. 
 Thanks for the explanation.

I still think it's interesting.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

Thank you for the comments. I'll fix most of them - responses inline for 
the rest:


On 07/07/2023 17:38, Eric Rescorla wrote:


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?
Possibly a premature optimization, but I was thinking that if a new 
version only included new certificates, it'd be nice to only have to 
append the new data to the existing dictionaries. I haven't yet worked 
out if that's actually going to deliver anything useful though.


       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 0xff. That's probably
not a problem, but I think you should make it clear and have some
way to manage it.


If the length is corrected, isn't the only risk a collision with a 
certificate which is exactly three bytes and starts with 0xff?



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.


It seemed the fairest repeatable way to check whether a CA was offering 
certificates to WebPKI clients without having to write a lot of emails. 
I agree its not desirable to keep as a dependency in the long run.



S 5.1.
ISTM that there are plenty of code points available.


Thanks!

Best,
Dennis









On Thu, Jul 6, 2023 at 3: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:
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 

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

On 07/07/2023 17:42, Salz, Rich wrote:

I would love to get feedback from the working group on whether the draft is 
worth developing further.

I read your document [1] and found it very interesting.


Thanks Rich!


I found the handling of extensions complicated, although I admit to reading 
that part very quickly.

How much simpler would things be if the identifier were just a SHA256 hash of 
the CA, perhaps truncated?  You send an array of (url, timestamp) as an 
extension, and then the server just sends the digest of its cert chain, perhaps 
even its own cert.


So this draft is doing two different things: building the dictionaries 
in a fair way and then specifying how to use them as part of the 
existing TLS Certificate Compression extension. Implementations only 
care about the second part which only involves a bit of string 
substitution and a call to ZStd. They don't have to know or care about 
how the dictionaries were built or do any new kind of negotiation.


I don't follow your comment about the handling of extensions, the code 
doing the compression and decompression isn't aware of what an extension 
is or handling them specially, its just swapping strings.  In order to 
compress the larger strings which issuers add to end entity certificates 
(e.g. OCSP & CRL URLs, practice statements), the dictionary does include 
some extensions made by each issuer, but these are just concatenated 
binary strings.


Best,
Dennis



___
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

Re: [TLS] Abridged Certificate Compression

[Salz, Rich]

> I would love to get feedback from the working group on whether the draft 
is worth developing further.

I read your document [1] and found it very interesting.  I found the handling 
of extensions complicated, although I admit to reading that part very quickly. 

How much simpler would things be if the identifier were just a SHA256 hash of 
the CA, perhaps truncated?  You send an array of (url, timestamp) as an 
extension, and then the server just sends the digest of its cert chain, perhaps 
even its own cert.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Eric Rescorla]

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 0xff. 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  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 

[TLS] Abridged Certificate Compression

[Dennis Jackson]

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