Re: [TLS] tls@ietf117

[Sean Turner]

Now that the submission deadline has passed … here’s a gentle reminder!

Cheers,
spt

> On Jun 18, 2023, at 19:25, Sean Turner  wrote:
> 
> The TLS WG is planning to meet at IETF 117. A 2 hour slot has been requested, 
> but not yet scheduled. The chairs would like to solicit input from the WG for 
> agenda topics. Please send your agenda topics request and an estimate for how 
> much time you will need to tls-cha...@ietf.org. Please note that we will 
> prioritize existing WG items. Please also review the guidance for TLS WG 
> presenters that can be found at [1].
> 
> Cheers,
> Chris, Joe, and Sean
> 
> [1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md

___
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

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

[Sean Turner]

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/

The WG Last Call will end 25 July 2023 @ 2359 UTC.

Please review the I-D and submit issues and pull requests via the GitHub 
repository that can be found at:

https://github.com/tlswg/draft-deprecate-obsolete-kex

Alternatively, you can also send your comments to tls@ietf.org.

Thanks,
Chris, Joe, & Sean
___
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

[Salz, Rich]

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

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

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/

___
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

[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

[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]

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

[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

[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

[Kampanakis, Panos]

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 would make it 
harder to use Abridged Certs in other contexts as it would no longer be a 
lossless compression scheme.

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

Sorry I'm afraid I don't follow.

Abridged Certs would negotiated just the same as any other certificate 
compression algorithm. The client indicates support by including the Abridged 
Certs identifier in its Certificate Compression extension in the ClientHello 
(along with the existing algorithms like plain Zstd).
The server has the choice of whether to use it in its CompressedCertificate 
message. If a new version of Abridged Certs were minted in a few years with 
newer dictionaries then it would have its own algorithm identifier and would 
coexist with or replace the existing one.

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

Abridged Certs is just a thin wrapper around Zstd which is already deployed as 
TLS Certificate Compression algorithm, so the same considerations apply. 
According to Facebook's numbers [ZSTD]

[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 would make it 
harder to use Abridged C

[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