Re: [TLS] Abridged Certificate Compression

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

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

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

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

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

[TLS] Minor RFC8446bis change

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

Re: [TLS] Minor RFC8446bis change

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

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

> 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

Re: [TLS] Minor RFC8446bis change

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 wan

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

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

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

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

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

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 applica

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

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