Some loose reports have indicated that NSA implemented backdoors to some NIST elliptic curves. As far as I understand these do not include P-256, P-384, etc.
From a security standpoint, would it be considered bad practice to use e.g. the curve secp256r1 in our TLS1.2 settings.
For example:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA)
And what would be alternatives to this?
From a security standpoint, would it be considered bad practice to use e.g. the curve secp256r1 in our TLS1.2 settings
As of October 2021, NIST P-256 (secp256r1) is considered to be more than secure enough for use in TLS in any environment. Complaints about NSA backdoors relating to elliptic curves are mostly due to Dual_EC_DRBG, which is a technically separate matter, although from a security policy perspective it remains relevant.
Some loose reports have indicated that NSA implemented backdoors to some NIST elliptic curves. As far as I understand these do not include P-256, P-384, etc.
This is sort of correct. The secp256r1 curve in TLS 1.2 is being used for the Elliptic Curve Diffie-Hellman (ECDH) exchange. This is the part of the handshake that allows the two clients to agree upon a key. There is no strong evidence that the NIST P-256 and P-521 curves were backdoored.
The link you posted is talking about Dual_EC_DRBG. This is a random number generator (CSPRNG) that was backdoored by the NSA. It uses elliptic curves, but has nothing to do with the P-256 or P-521 curves. The use of Dual_EC_DRBG is not specified as part of a TLS cipher suite. It was promoted for use in some TLS implementations, but it is not used today. Elliptic curve cryptography is an entire branch of study based on an entire field of mathematics - the use of EC in a backdoored cipher has no real impact on the security of EC curves or EC cryptography in general.
The reason that people are somewhat suspicious of the NIST curves is because the NSA used NIST to promote Dual_EC_DRBG. Whether or not they were willing participants remains to be seen, and it is worth keeping in mind that the NSA's project to promote this backdoored CSPRNG largely took place between 1997 and 2005. Given general changes in attitudes and policy regarding cryptography and security infrastructure since then, it is certainly not unfathomable that the NSA may have learned their lesson with regard to damaging trust in NIST. It's also entirely possible that they didn't, of course.
Since the NIST curves were derived from random numbers, there's no way to tell if those numbers were picked in order to insert a backdoor. There's absolutely no evidence or cryptanalysis to concretely support allegations of a backdoor, but it does make some people uneasy. Most cryptographers prefer the use of nothing-up-my-sleeve numbers to alleviate this problem.
secp256k1 is a somewhat popular alternative to secp256r1 precisely because its selection process was fairly transparent. Another curve that some people prefer is Curve25519, which is called X25519 when used in Diffie-Hellman, although it's worth being aware that the most referenced resource for evaluating curve security was written by DJB, who developed Curve25519, so it's hardly surprising that he gives it a glowing review. Still, it's well-trusted, and support for this curve is mandatory in TLS 1.3.
Ultimately, this isn't really a question of cryptographic strength. It's a question of perception and gut feelings around who is or is not trustworthy. There's also the question of whether it really matters in practice. If your threat model doesn't include the NSA (which it almost certainly shouldn't - see Mickens' This World Of Ours for an excellent and highly amusing discussion on this topic) then it doesn't make any material difference whether you use secp256r1, secp256k1, or X25519 for your ECDH key exchange in TLS. If the NSA isn't trying to steal your traffic, the secret presence of an NSA backdoor in NIST P-256 is ultimately irrelevant to your threat model. If the NSA is trying to steal your network traffic, in particular, for whatever unfathomable reason, your use of one particular elliptic curve over the other is not going to be an impediment to them.
In fact, the use of TLS 1.2 instead of TLS 1.3 is far more likely to be the source of a practically exploitable vulnerability than a possible backdoor that might allow the NSA to decrypt TLS traffic to your website. Time spent worrying about which EC curve to use is time you could be spending on security controls to mitigate far more likely and impactful security issues.
Your link (DRBG) is a Deterministic Random Bit Generator based on ECC (Dual_EC_DRBG). Dual_EC_DRBG has a trapdoor for the NSA. The trapdoor is not related to a possible backdoor of the NIST curves 1. NIST revealed the s where b = SHA1(s) of the curve P224 or P256 curves;
y2 = x3 - 3x + b
We don't know secp256r1 has a backdoor or not.
You can use NIST's Koblitz Curves; NIST K-409 (sect409k1), NIST K-571 (sect571r1) as stated in the appendix A of
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
1 The NIST curve has synonyms; like P256 has other names secp256r1 and prime256v1. The NIST P curves are designed by NSA and the seed is revealed by NIST.
Thomas made a test against Koblitz curves. Similarly, the nothing-in-my-sleeve-number is psychological. It is the seed here. The NSA can search for seed and corresponding curve that they have a backdoor and you still consider that the first number from PI are a nothing-in-my-sleeve-number
