Stop recommending DHE, because of "dheater" vulnerability

[patrakov]

These guys found a way to saturate the server CPU core to 100% using as little as 5 KB/s of incoming traffic. The pre-requisite is that the server supports DHE as the key exchange. Therefore, to avoid creating such a vulnerable configuration, I propose removing DHE from all levels of SSL config.

[tomato42]

1. It's a well known property of DHE that it's more computationally intensive than RSA and ECDHE key exchanges.
2. Not every named vulnerability is important or requires an action

[Gunni]

CVE-2002-20001 has been assigned for DHE.

[ghen2]

It's a well known property of DHE that it's more computationally intensive than RSA and ECDHE key exchanges.

This is not about the (well known) performance difference under normal usage. This novel technique lets an SSL client trivially occupy 100% CPU on the SSL server by sending rogue data, ie. without requiring a corresponding computational effort from the client. This is an easy DoS attack, which can be mitigated by disabling DHE, or by rate limiting new connections per client (which not all SSL servers can do).

[tomato42]

It's a well known property of DHE that it's more computationally intensive than RSA and ECDHE key exchanges.

This is not about the (well known) performance difference under normal usage. This novel technique lets an SSL client trivially occupy 100% CPU on the SSL server by sending rogue data, ie. without requiring a corresponding computational effort from the client. This is an easy DoS attack, which can be mitigated by disabling DHE, or by rate limiting new connections per client (which not all SSL servers can do).

That's the case for all DH requests from the client, be it FFDHE or ECDHE, no ClientHello (not even in TLS 1.3) includes proof of work or proof of freshness of the key share, at the same time the server has to generate a fresh key share and calculate the shared keys (the processes that use up the CPU time).

Even on a very fast CPU, you can't expect more than ~2k ECDH key exchanges per second per core with a P-384 curve. With the massive 379 byte large TLS 1.3 Client Hello from OpenSSL 1.1.1 that translates to something like 1MiB/s of traffic (after including connection establishment) to fully saturate a core. That's residential broadband levels of upload.

Does that qualify as a DoS too? At what point we can't add support for a stronger, but slower algorithm because that would make the server vulnerable?

[patrakov]

There is a huge difference between 5 KiB/s (that's what dheater generates) and 1 MiB/s mentioned in the previous comment.

[tomato42]

Read my answer again:

1. 1 MiB/s is unoptimised, those are not minimal ClientHello's
2. those are values for different CPUs, I got an example from a top of the line desktop CPU, on a virtualized host on a hosting provider you can easily get performance few times worse, maybe even 10 times worse

So I wouldn't be surprised if to perform the same kind of attack against the same machine as they did but with ECDH you wouldn't need more than 30KiB/s of traffic, and I'm quite sure it wouldn't be more than 100KiB/s

So again, at what point is a cryptographic algorithm a vulnerability?

[watchingdogs]

There is a huge difference between 5 KiB/s (that's what dheater generates) and 1 MiB/s mentioned in the previous comment.

Don't trust what the tool says for bandwidth, make you own measurement because it can be inaccurate.

So again, at what point is a cryptographic algorithm a vulnerability?

Solving this issue isn't done removing support for DHE, but rather making people aware of it and they'll be able to act up on their knowledge, by maybe setting up a firewall. At least a notice for this vulnerability would be beneficial.

[c0r0n3r]

IMHO it would be an appropriate compromise to add an option to the generated configurations to control the used named groups whenever possible. It would be necessary because, in the case of TLS 1.3 (and TLS 1.2 with RFC 7919 support), the clients are allowed to negotiate FFDHE parameters with any key sizes which enabled in the server's configuration. It means that an attacker can exploit that mechanism to force to use the largest allowed key size to overload the server, as the proof-of-concept code (DHEater) of CVE-2002-20001 demonstrate. The default value of named groups may contain the large FFDHE groups (e.g., OpenSSL 3.0, GnuTLS), meaning that the server is highly vulnerable to the DHEat attack using the default. Setting the named groups to contain only the smaller FFDHE groups would solve the problem without security concerns.

[domdom82]

I agree with @c0r0n3r making the named groups configurable is a fair option. I was working on hardening my HAProxy config and quite frankly, the current recommendation by the mozilla ssl generator makes TLS 1.3 more vulnerable than TLS 1.2 to this attack. The dh-param option allows me to limit the key size to 2048 bit but it only works for TLS 1.2.
For TLS 1.3, I needed to add the "ssl-default-bind-curves x25519:secp256r1" option, because OpenSSL 3.x re-introduced DHE again.
So, it would have helped me save a lot of time if the ssl-generator at least had the option to configure named groups / curves.

[c0r0n3r]

The related technical paper (D(HE)at: A Practical Denial-of-Service Attack on the Finite Field Diffie–Hellman Key Exchange) may help your decision.

[gstrauss]

TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 is one of the ciphers recommended by RFC 7905 (published June 2016), and was added to the ssl-config-generator Intermediate configuration in 2023 after discussion in mozilla/server-side-tls#285

I personally agree that DHE ciphers (non-ECDHE) should no longer be recommended for Modern and Intermediate and am also pushing for this change, which as @ghen2 noted above has also been discussed in mozilla/server-side-tls#268 (which was opened in 2020, prior to mozilla/server-side-tls#285 from 2023)

[c0r0n3r]

There is another issue (CVE-2024-41996) which should also be considered. This one and the other two issues (CVE-2002-20001, CVE-2022-40735) are discussed in my article.

[janbrasna]

When the DHE suites are included, we also explicitly set the param to be equal to the ffdhe2048 group (which is the current size for intermediate) — that's why I'm a bit concerned about #256 changing that to RFC 7919 without any restriction allowing unnecessarily large group negotiations.

I consider the more specific issues actually implementation bugs (mostly regressions from 1.1.1x) that are being addressed over time: openssl/openssl#18480 (3.1.0), openssl/openssl#18793 (3.0.6), openssl/openssl#25088 (future 3.4.x release and a backport perhaps?) — silently expecting when the efficiency is being added for safe primes, it means not only for named groups, but also for provided params equal to the groups.

(All the relevant CVEs refer to this issue here, so I'm linking the OpenSSL fixes for posterity.)

[gstrauss]

IANA TLS Supported Groups (see "Recommended" column in the table)
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8

The recommended groups are currently X25519:P-256:P-384:X448.
(P-256 is also known as secp256r1 and as prime256v1)
(P-384 is also known as secp384r1)

The ssl-config-generator guidelines currently contain groups X25519:prime256v1:secp384r1, though this is not currently exposed in the configs generated by ssl-config-generator. (See #270 for that discussion)

@polarathene is there any good reason why a future version of the ssl-config-generator guidelines should be modified to recommend ffdhe groups for key exchange with TLSv1.3?

boringssl and libressl do not support ffdhe key exchange with TLSv1.3.
This fails: openssl s_client -tls1_3 -groups ffdhe2048 -connect google.com:443
The same command tested on my local machine (changing google.com:443 to localhost:443) works with openssl 3.2.2, but again, does not work with boringssl or libressl.

@polarathene separately, for TLSv1.2, is there any good reason why a future version of the ssl-config-generator Intermediate guidelines should continue to recommend TLSv1.2 DHE_* ciphers? Is my understanding correct that if the DHE_* ciphers are removed from the current ssl-config-generator Intermediate recommendations, then servers following the Intermediate guidelines, and without DHE_* ciphers for TLSv1.2 will not be affected by DHEater for TLSv1.2 connections?

[polarathene]

TL;DR: I think as we approach 2025, the majority of servers and clients that would be negatively impacted by lack of DHE should be niche and are stuck on EOL software/hardware.

• For any affected consumers, they'd need to buy a replacement.
• For business/government, they'd need to either invest in migrating/upgrading or should be considered to have the expertise to maintain their cipher suite requirements when they're no longer compatible with mainstream advice that this project caters to.

The DHEater related concern only seems to pragmatically apply to TLS 1.3 when larger modulus / computation can be triggered by the client? If that can be limited that'd probably be ideal, otherwise it may require opt-out (if supported by the implementation, Postfix seems to do this internally with OpenSSL 3).

---

@polarathene is there any good reason why a future version of the ssl-config-generator guidelines should be modified to recommend ffdhe groups for key exchange with TLSv1.3?

boringssl and libressl do not support ffdhe key exchange with TLSv1.3.

AFAIK, at least with initial TLS 1.3 the FFDHE groups were never something you had much influence on at the server side, just whatever the client requested? Regardless 2048-bit is quite secure IMO, even as a static group for DHE.

I'm not an expert in this area btw, I just sunk a fair amount of time into learning enough to be able to better weigh in on the topic for projects I maintain when it comes to security 😅 I trust with TLS 1.3 the actual experts made the decision they did to reduce control over cipher suites along with the inclusion of FFDHE groups that we'd have more official channels making amendments via RFCs should the security of the groups become a concern in future.

EDIT: Looked over the paper (section 5) from @c0r0n3r (your website isn't accessible btw, cloudflare states invalid cert), I see this is a bigger issue for TLS 1.3 since FFDHE group selection can be negotiated instead of fixed 😕

I vaguely recall TLS 1.3 having FFDHE groups included but I don't recall a specific reason other than as an alternative option to ECDHE for key exchange? (which has been split out from cipher suite definitions in TLS 1.3) 🤷‍♂️ The 3 AEAD ciphers in TLS 1.3 have specific purposes (AES-GCM or ChaCha-Poly1305 often depending on HW accel IIRC, and CCM for embedded needs).

---

@polarathene separately, for TLSv1.2, is there any good reason why a future version of the ssl-config-generator Intermediate guidelines should continue to recommend TLSv1.2 DHE_* ciphers?

I think I was looking at removing these from a project I maintain, at least from the modern profile, but I'm having some trouble finding notes on that decision (might have been lost during a system failure a couple months back).

I would agree with the input of others that it's probably worthwhile to discourage DHE:

• DHE-RSA-CHACHA20-POLY1305 should NOT be used anymore #269 (comment)
• DHE ciphers should be disabled in Intermediate compatibility configuration server-side-tls#268 (comment)
• Stop recommending DHE, because of "dheater" vulnerability #162 (comment)

This project after all is a guideline for those that don't know any better, it does not enforce the exclusion of these ciphers should you need them, and those with legitimate use-cases could always raise an issue to chime in with why they believe it's still relevant to bring back for the majority.

You're dealing with rather dated servers or clients to only have support where DHE is a more secure cipher choice available. Such cases AFAIK tend to be due to businesses or government that are blocked from dropping the requirement, but have the resources to know better and make the necessary modification to bring back the ciphers they require.

As I maintain a mail server project, there is a bit more of a lag there. I changed our "modern" profile to roughly resemble the "intermediate" profile from Mozilla and OWASP in late 2020. The last main compatibility concern I can recall was possibly with Apple Mail and resolved in 2018, other than that it's businesses on systems with EOL windows and the like where I advise them to manually manage their cipher-suite lists.

---

Is my understanding correct that if the DHE_* ciphers are removed from the current ssl-config-generator Intermediate recommendations, then servers following the Intermediate guidelines, and without DHE_* ciphers for TLSv1.2 will not be affected by DHEater for TLSv1.2 connections?

I lack the time to get familiar with DHEater again, but when I did look into it years ago it did not seem like a pragmatic concern. - There's no need for 4096-bit or 8192-bit modulus that some less knowledgeable users would wrongly adopt.

• I know some software doesn't support dual-cert ECDSA + RSA (fallback), and for some software that may potentially be an issue to support dated clients (notably in mail servers), but I lack any recent statistics info on what is still limited to TLS 1.2 and for whatever reason only capable of DHE. Shouldn't be a concern for majority of deployments though.

The mail server project I maintain dropped TLS 1.0 + 1.1 in Dec 2022 (officially part of the v12 release in April 2023). That change had two reports in 2024 about affected users, 1 was stuck on Windows 7, while the other was trying to use old hardware (a document scanner). It's possible that dropping DHE based cipher-suites could have similar compatibility impact, but I think enough time has passed for that to no longer be the responsibility of your server.

Looking at the DMS test for TLS 1.2 RSA cipher suite, there should still be ample ciphers available even without DHE. I don't have my old notes from my 2020 research on me for more specific compatibility info, but as mentioned I think it should be fine to drop DHE 👍

[gstrauss]

@polarathene thanks for your comments.

@gene1wood along with my comments in #162 (comment), it would seem that there is consensus that we should remove the DHE ciphers for <= TLS1.2.

This issue is blocked waiting for guidance in mozilla/server-side-tls#268, where there seems to be support (e.g. April's comment in Jun 2024 mozilla/server-side-tls#268 (comment)) for modifying the guidelines to remove DHE ciphers.

[tomato42]

yes, at this point we probably should move DHE to "Old", and limit it to 2048 bit parameters with a safe prime

[tomato42]

that being said, replacing ffdhe2048 in TLS 1.3 with a PQC key exchange would be nice: #279

[c0r0n3r]

IMHO, 3072 bits is a good compromise between speed and security. Please consider that 2048 bits provide only 112, while 3072 bits provide 128 bits of security.

[polarathene]

Please consider that 2048 bits provide only 112, while 3072 bits provide 128 bits of security.

110-bits technically IIRC, it gets rounded to the nearest byte, so 112-bit. Likewise for 3072-bit modulus mapped to around 131-bit symmetric strength.

2048-bit is still plenty though: #256 (comment)

TL;DR: You would not be able to pull off this attack within our lifetime without the world knowing, assuming you could even acquire the necessary compute resources.

In that linked resource:

• Basically with the capability of the global bitcoin network hashrate at 750 EH/sec (that's 750 followed by 18 more zeros) which uses about 170 TW/year (power output of Ukraine), your average success for 110-bit brute force would be around 27k years. 200x that power requirement is more than the entire planet outputs btw, so you're going to bottleneck.
• That's simplifying each "operation" to the cost of SHA256 (or was it two of those with bitcoin hashing?). I don't have my old notes on me for the GNFS which is more complicated to attack, but it will require more compute and especially memory, it gets complicated. I had the math for it all and it aligned with historical records for the lower levels of entropy that were compromised.
• I'm pretty sure I also calculated with limits of physics (which is way out of our reach) where even with top tier efficiency 114-bit of entropy would require enough energy to boil all the oceans in the world, regardless of time efficiency, that's a cost that should be clearly expensive to pursue vs alternatives.

---

Doesn't really matter how much I back that sort of statement up, people still feel uncomfortable about it, especially when NIST and others like it will push for 3072-bit as a baseline. Quantum attacks to my knowledge are just as infeasible cost wise, you get the faster computation via algorithm advantage but there's a trade-off and it does not scale any better cost wise tbh.

That said, if you get some more peace of mind from bumping it up a bit more and that decision doesn't really affect your resource costs, by all means adopt 3072-bit if you like. I'm just stating that 2048-bit / 110-bit is quite secure.

[gstrauss]

@c0r0n3r: Elliptic curves are more CPU efficient, memory efficient, and more space efficient (smaller network packet size).

If using DHE instead of elliptic curves, it is more likely that the computer does not support elliptic curves, and also more likely that the computer is slower and older tech. As such, 2048 bits (currently) provides a sufficient level of security and so should be maintained at 2048 bits (for the Old configuration).

The last substantial update to the public Mozilla SSL guidelines was in 2020.

@c0r0n3r: when the next update (eventually) comes, why should DHE be part of it? (Yes ECDHE, but why DHE?) DHE should be relegated to the Old configuration (and perhaps not even included in Old configuration if DHEater DoS attacks are a strong concern). @c0r0n3r If you think the guidance should be changed from 2048-bit to 3072-bit, please provide references to help us understand why we should still be recommending DHE and why the recommendation should change from 2048-bit to 3072-bit. I am asking about DHE key exchange here, not RSA key size. Thank you.

[c0r0n3r]

@gstrauss, as we referenced in our paper (Table 1) NIST Special Publication 800-57 Part 1 Revision 5 (Table 2) says that DH using 3072-bit size provides equivalent security to AES-128 (128 bit). I thought it necessary to note that suggesting a parameter that can provide 128 bits of security is considerable.

[polarathene]

I thought it necessary to note that suggesting a parameter that can provide 128 bits of security is considerable.

110-bits is also considerable.

You could choose 256-bit over 128-bit for the same reason, but in both cases you're not really adding any pragmatic security when the cost for 110-bit is already out of reach.

[c0r0n3r]

@polarathene, as you can find in our paper 256 bits of security using DH KEX is not supported by the vast majority of the cryptographic libraries and would cause serious performance issues.

[gstrauss]

@c0r0n3r thank you for providing the reference. However, that does not quite answer the question I was asking. The reason for my question is one of "practical engineering", and I think what @polarathene might be trying to argue in the details.

NIST Special Publication 800-57 Part 1 Revision 5 (Table 2) says that DH using 3072-bit size provides equivalent security to AES-128 (128 bit). I thought it necessary to note that suggesting a parameter that can provide 128 bits of security is considerable.

I am not questioning that. Instead, coming from a practical perspective, I am asking if we can omit DHE key exchange. For (future update of) ssl-config-generator Intermediate and Modern configs, why we should recommend DHE key exchange in TLSv1.2 ciphers, or in TLSv1.3 groups?

@c0r0n3r do you disagree with my statement?

Elliptic curves are more CPU efficient, memory efficient, and more space efficient (smaller network packet size).

(and also not vulnerable to resource usage DoS due to DHEater attack)

Edit: I should have specified "elliptic curves of similar strength to much larger DH keys"

[polarathene]

@c0r0n3r you misunderstand what I was saying. I'm referring to symmetric security strength, not DH specifically. It's obvious that the equivalent in DH would be bad for other reasons discussed in this issue.

I am simply stating that 110-bits (2048-bit modulus) is sufficiently secure. I know you've referenced the NIST document as a source, but I've done that years ago and taken it a step further (as illustrated above with approximating the cost in resources to actually perform an attack).

If the information I provided earlier is not sufficient, you can review my math related to the NIST table referenced, but digging up my old notes with the more in-depth math for GFNS and the limits of physics computations is not something I can presently afford to do right now until I'm in a better situation financially.

---

The reason for my question is one of "practical engineering", and I think what @polarathene might be trying to argue in the details.

Yes, specifically that there is no pragmatic increase in security above 2048-bit with DHE to my knowledge. I've shared my knowledge over the years regarding this and have yet to have any response that invalidates my findings, which if anything the cost is higher.

DHE cipher suites to my knowledge were more of a compatibility/transition as historically support for other cipher suites on older systems (now EOL for some years IIRC) had been lacking. The only other reason I recall DHE being relevant is when ECDHE was not desired due to certain concerns (potential backdoors I think with ECC, unless using say ed25519), my old notes have the details/links related to that.

[tomato42]

IMHO, 3072 bits is a good compromise between speed and security. Please consider that 2048 bits provide only 112, while 3072 bits provide 128 bits of security.

We are accepting 2048 bit RSA keys, for legacy deployments there really is no reason to pair 3072 bit DH with 2048 bit RSA.
And I know that at least some Java versions are happy with 2048 bit DH but will fall flat when getting 3072 bit DH params, which, again, for legacy, max-compatibility configuration, is a bad thing.

[polarathene]

there really is no reason to pair 3072 bit DH with 2048 bit RSA

Technically the RSA key is replaced periodically while FFDHE 3072-bit group parameters are static, so if 2048-bit were possible to attack, bumping it up to 3072-bit for DHE would make sense.

Regarding 2048-bit compatibility, yes that limitation exists elsewhere too and are being dismissed as too old to be relevant anymore? Those environments often lacked ECDHE support or support for other modern ciphers (in TLS 1.2). Where possible it's better to put them behind a proxy to bridge to modern security capabilities.

[tomato42]

Technically the RSA key is replaced periodically while FFDHE 3072-bit group parameters are static, so if 2048-bit were possible to attack, bumping it up to 3072-bit for DHE would make sense.

while some precomputation is possible for attacking a particular parameter set, and then reusing that for attacking different key exchanges, it requires more resources than breaking a single DH key exchange. An attacker that's able to "easily" break DH with static params by use of precomputation would be able regularly break RSA public keys. See the LogJam paper for details.

So really, it's an academic distinction without relevance to practical deployments. Pair RSA with same-size DHE, even if it's a well-known DHE prime. That's the algorithm already implemented and deployed in OpenSSL, NSS, and possibly other libraries.

[c0r0n3r]

@gstrauss, thanks for clarifying your comment. I agree with your statement. However, there can be implementation issues that may cause ECDHE to be vulnerable to D(HE)at attack, but it would require further investigation.

[c0r0n3r]

We are accepting 2048 bit RSA keys, for legacy deployments there really is no reason to pair 3072 bit DH with 2048 bit RSA. And I know that at least some Java versions are happy with 2048 bit DH but will fall flat when getting 3072 bit DH params, which, again, for legacy, max-compatibility configuration, is a bad thing.

Good to know. Thanks for sharing this info.

[tomato42]

The main differentiation I was making was a certificate generally has a life time of 90 days or less, while the standardized groups with FFDHE from RFC 7919 don't have that constraint.

no, they don't: CA certificates have lifetimes measured in decades, and even regular certificates will have lifetimes measured in years because not everybody can use ACME

[gstrauss]

@polarathene here is some meta feedback: you have shown a tendency to make statements/conclusions without evidence and then ask others for evidence when they tell you that your assumptions -- which you made as statements -- are incorrect or misleading in their representation. It is not the responsibility of others to prove you wrong. Please ask questions rather than making statements and attempting to put the burden on others to disprove your statements.

Statistically, when the advice this generator provides for modern and intermediate profiles is used the bulk of certificates will be ACME with a short lifespan such as 90 days.

Citation needed. (Also, @tomato42 provided a counterexample.)

Could you provide context on why ACME wouldn't be available?

Not everyone uses ACME to manage their certificates. One possible security pattern is to disallow servers to make outgoing connections, not even via a proxy. In those configurations, certificates must be pushed to those servers and the certificate lifetimes are managed by the CA which issues the certificate, which might not be the CA you have in mind.

@polarathene There are many possible valid configurations and your preferred configuration is not one that can be enforced on the entire internet.

The systems unable to do so are going to have caveats due to environment or age which I assume won't be supported indefinitely by this generator.

For some, yes. It is an ongoing challenge to provide reasonably secure configurations for a wide variety of scenarios and ages of software. I am trying to structure the conversations around publicly maintained software versions and end-of-life versions (even if commercial support is available privately for older software versions).

[tomato42]

@polarathene the whole certificate chain needs to be secure, so as long as we have browsers trusting any CA with lifetime measured in multiple years and keys that are 2048 bit long your whole argument for mismatched recommendations for DHE and RSA pair is invalid

attacking a single key used by said CA will be easier than attacking 2048 bit static parameter set for DHE

both of which will lead to compromise of the connections happening after that break

recommending different RSA and DHE limits goes against recommendations of basically whole cryptographic community, so please, just stop

[tomato42]

Just in case big comments from me is the actual communication issue.

Attack scenario:

* 2048-bit RSA certificate (_any part of the chain_), 10 year expiry.

* 2048-bit FFDHE parameters (RFC 7919), no expiry, no rotation.

* 20 year attack. The entire planet is dedicating it's resources to accomplish this. Moore's law accounted for.

Conclusion:

* Optimal attack target? (_between these two choices, obviously there is more affordable alternatives_) DHE parameters due to sufficient time to attack.

* Counter-measure?
  
  * Raise DHE parameters from 2048-bit (_110-bit symmetric_) to 3072-bit (_132-bit symmetric_) or rotate params to non-standardized params (_without weak cyclic groups used_).
  * Use an alternative key exchange instead of FFDHE.

You're forgetting that this is about general recommendations for normal internet systems.

if you need to care about secrecy of the data for more than 20 years, then you need custom policies.

I'm not recommending anything?

And those "counter-measures" above? what's that?

sorry, but I don't find this conversation productive or pleasant

[gstrauss]

@polarathene: Your initial statements have been useful contributions to the discussion. Thank you. The repetition and drowning in some of the details has not been constructive. Please stop posting on this issue.

While you may be an expert in this area, you are not the only expert and we are not here to validate you.

Correct me if I'm wrong,

No. N.B.: I am neither validating nor am I disputing your statements; I am ceasing to entertain them further.

So let's just end this discussion and agree that my statement

No. The discussion was already over.

Otherwise I'm more than happy to continue until we're on the same page about the validity of the statement.

No. Not here.

Please stop posting here on this issue.
You are not going to receive the validation you are looking for here, as this issue is not about validating you.

Thank you for your contributions to the discussion.
Please stop repeating yourself and please stop posting here on this issue.

Have I repeated myself enough to make my point crystal clear? Did you understand it the first time? (Likely.)
If you got it the first time, and I fully expect that you did, then please turn it around and apply the same to yourself.

Further responses here repeating yourself or seeking validation maybe hidden, deleted, or otherwise removed.

As you, yourself said above:

So let's just end this discussion

Yes, to that part, on the already-ended discussion.