An additional comment on this, a pretty straightforward solution is to use the
TLS-LTS one:
TLS-LTS sends the full set of DH parameters, X9.42/FIPS 186 style,
not p and g only, PKCS #3 style. This allows verification of the DH
parameters, which the current format doesn't allow:
o TLS-LTS implementations MUST send the DH domain parameters as { p,
q, g } rather than { p, g }. This makes the ServerDHParams field:
struct {
opaque dh_p<1..2^16-1>;
opaque dh_q<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */
Note that this uses the standard DLP parameter order { p, q, g },
not the erroneous { p, g, q } order from the X9.42 DH
specification.
o The domain parameters MUST either be compared for equivalence to a
set of known-good parameters provided by an appropriate standards
body or they MUST be verified as specified in FIPS 186 [9].
Examples of the former may be found in RFC 3526 [32].
That pretty much solves the problem once and for all without needing
magic-number groups or similar.
Peter.
________________________________________
From: TLS <tls-boun...@ietf.org> on behalf of Nimrod Aviram
<nimrod.avi...@gmail.com>
Sent: Friday, 29 July 2022 02:41
To: <tls@ietf.org>
Subject: [TLS] draft-deprecate-obsolete-kex - Comments from WG Meeting
Hi Everyone,
Thank you for chiming in with comments and suggestions regarding
draft-deprecate-obsolete-kex :-)
I've tried to summarize everyone's comments below, hopefully grouped by subject.
Apologies in advance if I missed anything (or misspelled names...), please do
reply to this thread :-)
My intent here is only to make sure we have a good record of the comments made.
I hope to follow up soon with a suggested way forward for the draft.
thanks,
Nimrod
===============
Scott Fluhrer: We can only check for group structure if it's a safe prime, and
even for a safe prime it's too expensive. Suggest limiting groups to a safelist.
Mike Ounsworth: Automated scanning tools routinely flag standardized FFDHE
groups.
Daniel Kahn Gillmor and Thom Wiggers: This is because of the Logjam paper and
precomputation. But they missed that the advice to generate your own DH params
was for 1024 bit parameters for sofware that didn't support anything else.
Daniel Kahn Gillmor: Would be good to discourage non-standard groups, while
acknowledging the original argument for non-standard groups and explaining why
it doesn't motivate non-standard groups today.
Viktor Dukhovni: Postfix is far from the only one with non-standardized,
built-in default groups. Even for Postfix there are several groups, depending
on the version. Would be hard to build a list of widespread groups.
Ben Kaduk: Can we start a registry for safe, widespread groups?
Martin Thomson: We tried using a safelist (that included only 7919 groups? -
Nimrod) but people use weird groups, and we couldn't turn that on.
David Benjamin: Agree, better to turn off FFDHE entirely.
The deployability issue with 7919 is also documented in
https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo/
https://mailarchive.ietf.org/arch/msg/tls/DzazUXCUZDUpVgBPVHOwatb65dA/
Uri Blumenthal: We should neither recommend or discourage non-standard groups.
Leave it to each operator to decide for themselves, they likely know what
they're doing.
Jonathan Hoyland and Martin Thomson: The pen-testing comment provides a
counterargument.
Uri Blumenthal: The draft is unnecessarily strict, from both deployment and
security points of view. Examples of stuff that should be retained: RSA, FFDHE.
PQ implications: all the NIST PQC winners and finalists are KEMs, not KA - aka,
similar to RSA rather than DH.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
