> It's also easy and quick to verify that the server *is* behaving correctly and thus is not exploitable. Could you please help me understand how you propose to verify this? For example, assuming an SMTP server that presents a (presumably) custom-generated safe prime. My understanding is that this would require two primality tests, for the modulus p and for (p-1)/2. Several folks here have argued that these primality tests would be prohibitively expensive for TLS clients to perform per-handshake (and this is also my general understanding of the cost of primality tests).
Could you please elaborate what client behavior you propose, and how you envision clients to bear the cost? (To concede a point in advance: It is obviously possible to _assume_ that if the server presents a modulus, then it "must" be a safe prime, or it meets some desired security notion that the server operator has deemed sufficient for the connection. However, experience shows that this is not necessarily the case in practice; see e.g. the "Small Subgroups" paper referenced in the draft. Since you used the word "verify", I'm assuming that's not what you meant?) best, Nimrod On Mon, 2 Jan 2023 at 15:52, Hubert Kario <hka...@redhat.com> wrote: > On Thursday, 22 December 2022 23:26:26 CET, Carrick Bartle wrote: > >> the latter is basically unexploitable with properly behaving > >> hosts in TLSv1.2 > > > > Well, right, that's the trick. The issue that people have > > pointed out with FFDHE is that it's very easy to have a host > > that is not properly behaving (see RFC 7919, which is referenced > > in our draft). > > It's also easy and quick to verify that the server *is* behaving correctly > and thus is not exploitable. > > > On Wed, Dec 21, 2022 at 5:14 AM Hubert Kario <hka...@redhat.com> wrote: > > On Tuesday, 20 December 2022 19:37:14 CET, Rob Sayre wrote: > >> On Tue, Dec 20, 2022 at 4:53 AM Hubert Kario <hka...@redhat.com> wrote: > >> Thus the deprecation of it is a matter of taste, not > >> cryptographic > >> necessity. > >> > >> I'm sorry if I'm being dense here, but isn't all of this a > >> SHOULD NOT in RFC 9325? > >> > >> > https://www.rfc-editor.org/rfc/rfc9325.html#name-recommendations-cipher-suit > >> > >> Maybe I'm misreading that RFC, but given that it's a BCP, it > >> seems like deprecation is a natural step that reflects IETF > >> consensus. > > > > that RFC marks both TLS_RSA_* and TLS_DHE_* as "SHOULD NOT". > > Given that the former is still being exploited close to 25 years after > the > > Bleichenbacher attack was discovered, while the latter is basically > > unexploitable with properly behaving hosts in TLSv1.2, I don't think it's > > correct to consider them at the same level. > > > > Yes, if you have ECDHE available, you SHOULD NOT use DHE in TLSv1.2. But > if > > everything you have is either TLS_RSA_* and TLS_DHE_*, then you're far > > better > > of with TLS_DHE_*. > > -- > 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
