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

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 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
___
TLS mailing list

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Salz, Rich]

>This appears in s2:
>Note that TLS 1.0 and 1.1 are deprecated by [RFC8996]
>and TLS 1.3 does not support FFDH [RFC8446].
>You’re suggesting that this be moved to s1?

My main point is say it once, not repeat it in each section.

> If that’s the case then maybe make Appendix B normative (and resort the 
> Appendices), list the Y->N changes above in s5, and leave the rest 
> informative (since they’re already or will be N)?

That's a good idea.

> And, we should probably change the name of the Appendices from “XXX Cipher 
> Suites Deprecated by This Document” to “Deprecated XXX Cipher Suites” to not 
> mislead readers that this document did all the deprecation. But, I do like 
> the idea of adding a reference to this document for all the registry entries 
> listed in Appendices - kind of like a tombstone.

And two more good ideas.  In one email: an IETF record perhaps.

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

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] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Viktor Dukhovni]

On Wed, Jul 12, 2023 at 12:40:13PM -0400, Sean Turner wrote:

> > On Jul 11, 2023, at 13:52, Salz, Rich  wrote:
> > 
> >> This email starts the working group last call for "Deprecating Obsolete 
> >> Key Exchange Methods in TLS 1.2” I-D, located here:
> > 
> >> .  https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex
> > 
> > Three minor issues and a question.
> > 
> > Consider saying once, early.in the document, that this does not
> > address TLS 1.0 and TLS 1.1 as they were already deprecated.
> 
> This appears in s2:
> 
> Note that TLS 1.0 and 1.1 are deprecated by [RFC8996]
> and TLS 1.3 does not support FFDH [RFC8446].

And section 3:


https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-02.html#section-3

Clients MUST NOT offer and servers MUST NOT select FFDHE cipher
suites in TLS 1.2 connections. This includes all cipher suites
listed in the table in Appendix C. (Note that TLS 1.0 and 1.1 are
deprecated by [RFC8996].) FFDHE cipher suites in TLS 1.3 do not
suffer from the problems presented in Section 1; see [RFC8446].
Therefore, clients and servers MAY offer FFDHE cipher suites in TLS
1.3 connections.

Note that at least in Postfix (opportunistic STARTTLS), this advice will
be ignored.  FFDHE will remain supported in TLS 1.2, with ECDHE
preferred when offered by the client:

https://tools.ietf.org/html/rfc7435

The default group used by the server is either a compiled-in 2048-bit
group or one of the groups from appendix of RFC7919 built-in to OpenSSL.
There are zero reports of clients that can't handle 2048-bit groups (as
opposed to 1024).  Point "3" in the introduction may be outdated w.r.t.
to current practice.

-- 
Viktor.

___
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] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Sean Turner]

> On Jul 11, 2023, at 13:52, Salz, Rich  wrote:
> 
>> This email starts the working group last call for "Deprecating Obsolete Key 
>> Exchange Methods in TLS 1.2” I-D, located here:
> 
>> .  https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex
> 
> Three minor issues and a question.
> 
> Consider saying once, early.in the document, that this does not address TLS 
> 1.0 and TLS 1.1 as they were already deprecated.

This appears in s2:

Note that TLS 1.0 and 1.1 are deprecated by [RFC8996]
and TLS 1.3 does not support FFDH [RFC8446].

You’re suggesting that this be moved to s1?

> Are the appendices normative?  I think so. That should be explicitly stated 
> in each appendix.

Maybe … if the the IANA considerations section stays as is they probably should 
be. But, see below.

> I would shuffle the appendices so that the order is B first (since it 
> contains NEW information not in the registry) and then A C D. The rationale 
> is that it puts all registry changes (mark as "not recommended" in one spot).
> 
> The question might be more appropriate for the TLS chairs.  About sync'ing 
> this with the registry changes draft [1].  That document adds a DISCOURAGED 
> value. Can we put this doc and [1] in the same cluster, so that the 
> "discourage" use (currently in appendix B) gets reflected into the registries 
> right away?
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

This I-D doesn’t refer to -rfc8447bis so if we wanted to put them in the same 
cluster we’d need to get PaulW to add some kind of instruction for the RFC 
editor.  But, we could “fix” that by tweaking the IANA considerations to just 
provide IANA instructions to IANA for those cipher suites that we are changing 
in s5 and reference -rfc8447bis.  The thing is that some of the suites listed 
in Appendix C are already “N" so we need to be clearer about what IANA needs to 
do.  Sorting the IANA registry based on the Recommended column Y” and comparing 
it to what’s in Appendix C, the new changes are:

Y-> N

0xCC,0xAA   TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
0xCC,0xAD   TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256
0xC0,0xA7   TLS_DHE_PSK_WITH_AES_256_CCM
0xC0,0xA6   TLS_DHE_PSK_WITH_AES_128_CCM
0xC0,0x9F   TLS_DHE_RSA_WITH_AES_256_CCM
0xC0,0x9E   TLS_DHE_RSA_WITH_AES_128_CCM
0x00,0xAB   TLS_DHE_PSK_WITH_AES_256_GCM_SHA384
0x00,0xAA   TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
0x00,0x9F   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
0x00,0x9E   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

N->D

All in Appendix B.

Did I get that right? 

If that’s the case then maybe make Appendix B normative (and resort the 
Appendices), list the Y->N changes above in s5, and leave the rest informative 
(since they’re already or will be N)?

And, we should probably change the name of the Appendices from “XXX Cipher 
Suites Deprecated by This Document” to “Deprecated XXX Cipher Suites” to not 
mislead readers that this document did all the deprecation.  But, I do like the 
idea of adding a reference to this document for all the registry entries listed 
in Appendices - kind of like a tombstone.

spt
___
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