Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
On Sun, Aug 01, 2021 at 02:27:22PM +0300, Nimrod Aviram wrote: > Looks like we have consensus for the following: IIRC we're not looking for consensus on the substance of the draft at this point, this just a WG adoption call. So the issues below do not need to be resolved at this time... We just happen to be taking the opportunity to discuss them... > - Clients may choose to not support FFDHE, a la Chrome. I don't see > consensus for full deprecation of FFDHE, please correct me if I'm wrong. > - Clients must not connect when the server uses a group of less than 2048 > bits. > - Clients may connect when the server uses a well-known, safe prime group > of at least 2048 bits (well-known might mean "from RFC 7919 plus the > built-in Postfix group", or other reasonable definitions). > - Clients may connect when the server uses a custom safe prime group of at > least 2048 bits, if the client verifies that the prime is safe. > > The only point where we don't have consensus seems to be: > - For clients who choose to support FFDHE, when the server uses a custom > group of at least 2048 bits, and the client isn't willing to check > safe-primality, what should the client do? And so, with confirmation from Peter Gutmann below that any custom groups we're likely to encounter are almost certainly safe (given a sufficiently large prime), I see no need to do anything beyond: - Client should set a floor on the FFDHE group size that is appropriate for its application ecosystem. Typically 2048, in ecosystems where smaller groups are sufficiently rare to non-existent. - A few specific, previously recommended, "standard" groups might now be explicitly refused. - Given that neither of the above can be negotiated in TLS 1.2, some clients and servers might choose to drop support for FFDHE either in TLS 1.2 or across the board. I don't see a realistic scenario in which sufficiently large ad-hoc server DH parameters are a problem. Only some specific "standard" groups (from outdated informational RFCs, ...) of suspect provenance might reasonably be blacklisted. On Sun, Aug 01, 2021 at 11:42:22AM +, Peter Gutmann wrote: > Viktor Dukhovni writes: > > >OK, who goes around bothering to actually generate custom DH parameters, and > >with what tools, but then does not use a "strong" (Sophie Germain) prime? > > That's better :-). That was my thought too, every DH/DLP keygen I've seen > generates either Sophie Germain or FIPS 186 primes/parameters, so on the off > chance that your server feels like generating custom primes you'd need to go > out of your way to generate unsuitable ones, i.e. you'd probably need to write > custom code specifically for bad prime generation, and if you're going to do > that then all bets are off anyway. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Viktor Dukhovni writes: >OK, who goes around bothering to actually generate custom DH parameters, and >with what tools, but then does not use a "strong" (Sophie Germain) prime? That's better :-). That was my thought too, every DH/DLP keygen I've seen generates either Sophie Germain or FIPS 186 primes/parameters, so on the off chance that your server feels like generating custom primes you'd need to go out of your way to generate unsuitable ones, i.e. you'd probably need to write custom code specifically for bad prime generation, and if you're going to do that then all bets are off anyway. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Looks like we have consensus for the following: - Clients may choose to not support FFDHE, a la Chrome. I don't see consensus for full deprecation of FFDHE, please correct me if I'm wrong. - Clients must not connect when the server uses a group of less than 2048 bits. - Clients may connect when the server uses a well-known, safe prime group of at least 2048 bits (well-known might mean "from RFC 7919 plus the built-in Postfix group", or other reasonable definitions). - Clients may connect when the server uses a custom safe prime group of at least 2048 bits, if the client verifies that the prime is safe. The only point where we don't have consensus seems to be: - For clients who choose to support FFDHE, when the server uses a custom group of at least 2048 bits, and the client isn't willing to check safe-primality, what should the client do? (This only applies when FFDHE is chosen in practice, rather than ECDHE.) My personal opinion is that both options - either allowing or forbidding the client to connect - would be reasonable here. Perhaps it'd be best to leave this specific point to the next WG meeting? We can still make progress on the document in the meanwhile. I'll also ask around if we can get some metrics, in general and specifically pertaining to that last point. thanks again everyone, Nimrod -- Forwarded message - From: Viktor Dukhovni Date: Sat, 31 Jul 2021 at 19:12 Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS To: On Sat, Jul 31, 2021 at 12:57:39PM +, Peter Gutmann wrote: > Viktor Dukhovni writes: > > >I strongly doubt there's a non-negligible server population with weak locally > >generated groups. > > Would you care to rephrase that so we can make sure you're saying what we > think you're saying in order to disagree with it? OK, who goes around bothering to actually generate custom DH parameters, and with what tools, but then does not use a "strong" (Sophie Germain) prime? The only weakness I expect to encounter is a deprecated size of e.g. 512, 768 or 1024 bits. Clients can easily detect that and enforce a floor, but of course still don't get to negotiate a minimum. Clients also don't get to negotiate the size of the server's RSA public key, or as you mentioned various other ways for the server to not screw up. -- Viktor. ___ 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] Weekly github digest (TLS Working Group Drafts)
Issues -- * tlswg/draft-ietf-tls-md5-sha1-deprecate (+5/-0/0) 5 issues created: - Remove 7525 text now the 7525bis is underway (by seanturner) https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/17 - Update title (by seanturner) https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/16 - Update references (by seanturner) https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/15 - Update Kathleen's Affiliation (by seanturner) https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/14 - s6: Final IoT Directorate comment (by seanturner) https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/13 * tlswg/draft-ietf-tls-esni (+0/-1/0) 1 issues closed: - Clarification of section 8.2. Middleboxes https://github.com/tlswg/draft-ietf-tls-esni/issues/474 * tlswg/tls13-spec (+0/-1/0) 1 issues closed: - Timing of sending NST from the server https://github.com/tlswg/tls13-spec/issues/1226 * tlswg/dtls13-spec (+0/-0/3) 2 issues received 3 new comments: - #253 Rekeying in (D)TLS 1.3 does not update the exporter_secret (2 by emanjon) https://github.com/tlswg/dtls13-spec/issues/253 - #249 DTLS 1.3 limits the number of packets that can be encrypted with AES-GCM to 2^40.5 (1 by emanjon) https://github.com/tlswg/dtls13-spec/issues/249 * tlswg/draft-ietf-tls-ctls (+1/-0/0) 1 issues created: - Remove varint encoding (by chris-wood) https://github.com/tlswg/draft-ietf-tls-ctls/issues/35 Pull requests - * tlswg/draft-ietf-tls-esni (+3/-5/0) 3 pull requests submitted: - Allow the client-facing server to GREASE the extension. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/481 - Tidy up client ECH accept and GREASE sections (by davidben) https://github.com/tlswg/draft-ietf-tls-esni/pull/480 - Cite the correct section for the retry flow. (by davidben) https://github.com/tlswg/draft-ietf-tls-esni/pull/479 5 pull requests merged: - Tidy up client ECH accept and GREASE sections https://github.com/tlswg/draft-ietf-tls-esni/pull/480 - Cite the correct section for the retry flow. https://github.com/tlswg/draft-ietf-tls-esni/pull/479 - Rephrase the overview https://github.com/tlswg/draft-ietf-tls-esni/pull/478 - Trim the introduction section https://github.com/tlswg/draft-ietf-tls-esni/pull/477 - Revise middlebox section. https://github.com/tlswg/draft-ietf-tls-esni/pull/475 * tlswg/tls-flags (+1/-0/0) 1 pull requests submitted: - Editorial WGLC comment by Victor Dukhovni (by yoavnir) https://github.com/tlswg/tls-flags/pull/7 Repositories tracked by this digest: --- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls13-spec * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-ctls * https://github.com/tlswg/external-psk-design-team ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
