TLS 1.3 支持哪些 Diffie-Hellman 組？我們應該使用 TLS 1.3 作為指南嗎？
這是一個由兩部分組成的問題——我問的是作為一個進入安全形色的人，誰需要標準化未來的實踐。
(1) 我很好奇以下 10 個不同的 DH 組是否是 TLS 1.3 支持的唯一組，(2) 因此，它們是我們應該使用的唯一組嗎？
https://www.rfc-editor.org/rfc/rfc8446#section-4.2.7
/* Elliptic Curve Groups (ECDHE) */ secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), x25519(0x001D), x448(0x001E), /* Finite Field Groups (DHE) */ ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), ffdhe6144(0x0103), ffdhe8192(0x0104),一些關於應該使用什麼曲線的討論已經在這裡進行，其中提到 secp256r1 和 secp384r1 是最好的。
我已經閱讀了 RFC 和這篇文章，並了解到 TLS 1.3 支持的密碼套件只有 5 個，其中 3 個是強制要求符合標準的（還有 3 個強制簽名算法）。我也了解簽名算法和支持的組在其他擴展中進行通信
(2) 詳細說明我的第二個問題：鑑於 TLS 1.3 是由專家多年來開發的，並且它只支持某些密碼機制——我們可以認為這意味著這些是唯一應該使用的機制嗎？
基本上，如果軟體/硬體支持，我們是否應該配置任何 TLS 1.1 和 TLS 1.2 連接（Web 伺服器、SSL-VPN 伺服器和 IKE/IPSEC 隧道）以使用/首選 TLS 1.3 RFC 中列出的機制？
(1) 我很好奇以下 10 個不同的 DH 組是否是 TLS 1.3 支持的唯一組，
是的，從某種意義上說，TLS 1.3 只允許在 1.3 中明確聲明為支持的組。這目前不僅包括來自RFC 8446的組，還可能包括更新的 RFC，例如來自 RFC 8734 的 Brainpool 曲線。
TLS 支持的組系統資料庫列出了所有組，但不幸的是它不區分協議版本（您必須在作為參考給出的 RFC 中追踪此資訊）。“推薦”專欄專門針對 TLS 1.3，但它既不是最小支持集也不是最大安全集（即使沒有完整的“推薦”集，您也可以擁有良好的互操作性，非推薦集包括可接受的內容，例如如 FFDH 和 160 位橢圓曲線之類的壞東西）。
(2) 因此，它們是我們唯一應該使用的嗎？
您當然不應該在 TLS 1.3 中使用其他組，因為它們不符合協議。無論如何，您的軟體不太可能支持 TLS 1.3 中的其他組。
(2) 詳細說明我的第二個問題：鑑於 TLS 1.3 是由專家多年來開發的，並且它只支持某些密碼機制——我們可以認為這意味著這些是唯一應該使用的機制嗎？
否：可以在舊版本的協議中使用其他機制。並非所有可以安全使用的機制都融入了 TLS 1.3。一些安全但沒有任何實際優勢的機制（更快、更小的程式碼、更小的消息大小等）沒有進入 TLS 1.3。TLS 1.3 的目標之一是降低協議的複雜性，這意味著更少的選擇。
在 TLS ≤1.2 的情況下，您需要在安全性（如：實施錯誤、已知協議弱點或尚未發現的協議弱點的風險）與互操作性之間取得平衡。（TLS 1.3 也是如此，但 1.3 推出的時間還不夠長，根本沒有互操作性問題。）由於現有選項的數量和現有軟體的多樣性，沒有單一的正確的答案是把平衡放在哪裡。
這裡已經討論了應該使用哪些曲線，其中提到 secp256r1 和 secp384r1 是最好的。
該討論是在 TLS 1.2 的上下文中進行的，它不支持相同的曲線。沒有理由拒絕 TLS 1.3 中支持的任何曲線，除非可能secp521r1，它容易受到實現弱點的影響。（顧名思義，secp521r1 涉及 521 位數字 - 是的，它是 521 而不是 512。因為它略大於 64 的倍數，所以某些中間數字具有最高有效字的可能性是不可忽略的0，當數字相乘時，保護不足的實現可能會洩漏這個事實，因為乘法會稍微快一些。這種洩漏足以讓攻擊者通過中等數量的連接嘗試來重建私鑰。）Curve25519 非常好並且可以說比 secp 曲線更可取，因為它更容易安全地實施。早在 2015 年，TLS 並不普遍支持它，但在 2021 年，它已成為 TLS 1.3 的標準部分。
對於有限域 Diffie Hellman，不要使用小於 2048 位的組。舊版本的 TLS 允許自定義組，並且對於是否使用它沒有達成共識。一方面，使用標準組可能允許具有足夠計算能力的攻擊者（閱讀：NSA）預先計算大量值，從而使攻擊變得可行。另一方面，生成良好的自定義組既慢又困難，這樣做可能會產生更容易利用的漏洞，例如讓中間人說服參與者使用弱組。這就是 TLS 1.3 要求使用已知良好組的原因。