On Monday, 2 January 2023 17:32:26 CET, Nimrod Aviram wrote:
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).
For every connection? Yes, it would probably be prohibitively expensive.
As part of an audit of networking infrastructure, at the same time as you
test which ciphersuites the server has actually enabled, if the
certificates
don't expire soon, etc.? No, it would be a simple test and just another
checkbox or two on the report ("uses safe primes",
"doesn't reuse public key shares").
That being said, NIST has required for FIPS mode that only well known
groups
have to be supported, and the USA didn't stop. So having deployments where
the clients actually do verify that the group used by the server is
actually
secure aren't just possible, but actual day to day reality.
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?)
At the end of the day the client has to trust the server to some degree.
There's nothing in the protocol that will stop the server from sending
the master secret straight to KGB^W GRU in Moscow. Irrespective of the
TLS version and key exchange parameters used.
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
