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

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

[Hubert Kario]

On Wednesday, 12 July 2023 19:13:02 CEST, Viktor Dukhovni wrote:

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


On Jul 11, 2023, at 13:52, Salz, Rich  wrote:
 ...


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.



And in general, it's far better to use FFDHE kex with legacy client than 
RSA.
Getting RSA right is very hard, using ephemeral secrets for FFDHE is 
trivial

and recommended practice already.

also


 Therefore, clients and servers MAY offer FFDHE cipher suites in TLS
   1.3 connections.


There are no ECDHE or FFDHE cipher suites in TLS 1.3. Cipher suites specify
just the bulk encryption, PRF, and integrity protection mechanism. The key
exchange is fully controlled by supported_groups and key_share extensions.
--
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 (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

[TLS] Minor RFC8446bis change

[Christopher Wood]

This final PR introduces some normative language, so we wanted to flag it on 
the list before merging:

   https://github.com/tlswg/tls13-spec/pull/1325

If there are no objections to the change by the IETF 117 meeting, we’ll merge 
it and then move this forward to AD review.

Best,
Chris, for the chairs
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Minor RFC8446bis change

[Russ Housley]

The proposed addition looks like excellent advice.

Russ


> On Jul 13, 2023, at 11:36 AM, Christopher Wood  wrote:
> 
> This final PR introduces some normative language, so we wanted to flag it on 
> the list before merging:
> 
>   https://github.com/tlswg/tls13-spec/pull/1325
> 
> If there are no objections to the change by the IETF 117 meeting, we’ll merge 
> it and then move this forward to AD review.
> 
> Best,
> Chris, for the chairs

___
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

[Nimrod Aviram]

> My main point is say it once, not repeat it in each section.
I think that language was added for fear that readers will only glimpse the
document, and somehow conclude that RSA/FFDH is fine with TLS 1.1.
(The document is mostly aimed at late adopters of best practices anyway...)
So my preference is to keep repeating that, if that's OK.

> Y-> N
I'm confused, probably because I'm not familiar enough with RFC8447bis and
friends :-)
N "Indicates that the item has not been evaluated by the IETF and that the
IETF has made no statement about the suitability of the associated
mechanism."
So why would we have cipher suites with FFDHE as N? I thought we'd mark
them all as Discouraged.
I guess this impacts whether the appendices are normative, so let's first
try to help me get unconfused :-)

> 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.
Yep, SGTM. I'll make that change.


On Wed, 12 Jul 2023 at 21:31, Salz, Rich 
wrote:

> >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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Minor RFC8446bis change

[Salz, Rich]

Ditto.

On 7/13/23, 11:40 AM, "Russ Housley" mailto:hous...@vigilsec.com>> wrote:


The proposed addition looks like excellent advice.


Russ




> On Jul 13, 2023, at 11:36 AM, Christopher Wood  > wrote:
> 
> This final PR introduces some normative language, so we wanted to flag it on 
> the list before merging:
> 
> https://github.com/tlswg/tls13-spec/pull/1325
> 
> If there are no objections to the change by the IETF 117 meeting, we’ll merge 
> it and then move this forward to AD review.
> 
> Best,
> Chris, for the chairs


___
TLS mailing list
TLS@ietf.org 
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!XLKA_ZA6MvVz4YxsAaInn6L94g4wPBx_KBjD9xfMHRU1qHYwfqHPRkFszb6J14t0bBugjlKd7bBRHxo$
 

 



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

> My main point is say it once, not repeat it in each section.
I think that language was added for fear that readers will only glimpse the 
document, and somehow conclude that RSA/FFDH is fine with TLS 1.1.
(The document is mostly aimed at late adopters of best practices anyway...)
So my preference is to keep repeating that, if that's OK.

Okay, fine.

___
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

[Nimrod Aviram]

> There are no ECDHE or FFDHE cipher suites in TLS 1.3. Cipher suites
specify
> just the bulk encryption, PRF, and integrity protection mechanism. The key
> exchange is fully controlled by .
Ah, good point :-)
Maybe go with this text instead?
In TLS 1.3 connections, clients and servers MAY offer supported_groups and
key_share extensions corresponding to FFDHE (note that in TLS 1.3, the key
exchange is not determined by the cipher suite, but rather by these
extensions).


On Thu, 13 Jul 2023 at 16:04, Hubert Kario  wrote:

> On Wednesday, 12 July 2023 19:13:02 CEST, Viktor Dukhovni wrote:
> > On Wed, Jul 12, 2023 at 12:40:13PM -0400, Sean Turner wrote:
> >
> >>> On Jul 11, 2023, at 13:52, Salz, Rich  wrote:
> >>>  ...
> >>
> >> 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.
> >
>
> And in general, it's far better to use FFDHE kex with legacy client than
> RSA.
> Getting RSA right is very hard, using ephemeral secrets for FFDHE is
> trivial
> and recommended practice already.
>
> also
>
> >  Therefore, clients and servers MAY offer FFDHE cipher suites in TLS
> >1.3 connections.
>
> There are no ECDHE or FFDHE cipher suites in TLS 1.3. Cipher suites specify
> just the bulk encryption, PRF, and integrity protection mechanism. The key
> exchange is fully controlled by supported_groups and key_share extensions.
> --
> 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
>
___
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 Thu, Jul 13, 2023 at 03:03:15PM +0200, Hubert Kario wrote:

> And in general, it's far better to use FFDHE kex with legacy client
> than RSA.  Getting RSA right is very hard, using ephemeral secrets for
> FFDHE is trivial and recommended practice already.

Indeed, though I agree that TLS applications should prefer ECDHE key
exchange over FFDHE key exchange, I hold that requiring non-support
is counterproductive.

As a data point, here's a negotiated cipher suite breakdown from SMTP
servers that have DANE TLSA records:

  30746 TLS 1.3 with AES256GCM-SHA384
   2192 TLS 1.2 with ECDHE-RSA-AES256GCM-SHA384
426 TLS 1.2 with ECDHE-ECDSA-AES256GCM-SHA384
153 TLS 1.2 with ECDHE-RSA-AES128GCM-SHA256
115 TLS 1.2 with ECDHE-ECDSA-AES128GCM-SHA256
 96 TLS 1.3 with AES128GCM-SHA256
 71 TLS 1.3 with CHACHA20POLY1305-SHA256
 71 TLS 1.2 with DHE-RSA-AES256GCM-SHA384
 25 TLS 1.2 with DHE-RSA-CHACHA20POLY1305-SHA256
 15 TLS 1.2 with ECDHE-RSA-AES256CBC-SHA384
  5 TLS 1.0 with DHE-RSA-AES256-SHA1
  4 TLS 1.2 with ECDHE-RSA-AES256CBC-SHA
  3 TLS 1.2 with RSA-AES256GCM-SHA384
  3 TLS 1.2 with DHE-RSA-AES128GCM-SHA256
  2 TLS 1.2 with ECDHE-RSA-CHACHA20POLY1305-SHA256
  1 TLS 1.2 with DHE-RSA-AES256-SHA1

Without any "MUST NOT"s, already TLS 1.3 dominates, and by far the bulk
of TLS 1.2 connections are using ECDHE.

What benefit do we expect from forcing weaker security (RSA key exchange
or cleartext in the case of SMTP) on the residual servers that don't do
either TLS 1.3 or ECDHE?

So long as we "raise the ceiling" we reap most of the benefit, and if
the handshake is downgrade resistant, raising the floor isn't always a
win.

-- 
Viktor.

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

[TLS] RFC 9345 on Delegated Credentials for TLS and DTLS

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 9345

Title:  Delegated Credentials for TLS and DTLS 
Author: R. Barnes,
S. Iyengar,
N. Sullivan,
E. Rescorla
Status: Standards Track
Stream: IETF
Date:   July 2023
Mailbox:r...@ipv.sx,
sub...@fb.com,
n...@cloudflare.com,
e...@rtfm.com
Pages:  17
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-tls-subcerts-15.txt

URL:https://www.rfc-editor.org/info/rfc9345

DOI:10.17487/RFC9345

The organizational separation between operators of TLS and DTLS
endpoints and the certification authority can create limitations. 
For example, the lifetime of certificates, how they may be used, and
the algorithms they support are ultimately determined by the
Certification Authority (CA).  This document describes a mechanism to
overcome some of these limitations by enabling operators to delegate
their own credentials for use in TLS and DTLS without breaking
compatibility with peers that do not support this specification.

This document is a product of the Transport Layer Security Working Group of the 
IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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