NSA और IETF: निष्पक्षता

मूल लेख ↗ Hacker News चर्चा ↗

विवाद का दायरा

  • चर्चा इस बात पर केंद्रित है कि क्या IETF TLS वर्किंग ग्रुप को TLS में pure-ML-KEM उपयोग का वर्णन करने वाला एक informational RFC प्रकाशित करना चाहिए (ECC hybrid के बिना post‑quantum KEM), और प्रक्रिया की निष्पक्षता पर भी।
  • लेख का लेखक प्रक्रिया और ML-KEM का प्रमुख आलोचक है, लेकिन बहस standards governance, NSA के प्रभाव, और PQC की परिपक्वता तक भी फैली हुई है।

IETF प्रक्रिया: “rough consensus” बनाम “voting”

  • कुछ लोग तर्क देते हैं कि WG निर्णयों को “votes” कहना भ्रामक है और प्रक्रियागत आपत्तियों को कमजोर करता है; IETF स्पष्ट रूप से “rough consensus” से काम करता है, न कि सिर गिनकर।
  • अन्य लोग नोट करते हैं कि व्यवहार में chairs और प्रक्रियाओं में हेरफेर किया जा सकता है, लेकिन “consensus” और antitrust carve‑outs से जुड़े कानूनी तर्कों को बढ़ा-चढ़ाकर या कानूनी रूप से भोला मानते हैं।
  • चिंता यह भी है कि IETF की कड़ी आलोचना उन लोगों को दूर कर सकती है जो अब भी इसे कुल मिलाकर अच्छा काम करने वाला मानते हैं, भले ही कुछ bad actors हों।

TLS में ML-KEM की स्थिति

  • केवल ML-KEM वाले named groups के लिए पहले से IANA codepoints मौजूद हैं; draft मुख्यतः यह बताता है कि उन्हें TLS में कैसे उपयोग किया जाए और इसे “recommended = N” के रूप में चिह्नित किया गया है।
  • Hybrid ECC+ML-KEM पहले से standardize है और recommended है; विवाद pure ML-KEM को एक विकल्प के रूप में दस्तावेज़ित करने पर है।
  • कुछ लोगों का कहना है कि इसे IETF से ज़बरदस्ती पारित कराने की प्रक्रियागत आवश्यकता नहीं है: codepoints के लिए कोई भी सार्वजनिक specification पर्याप्त है, और एक independent RFC stream (सैद्धांतिक रूप से) संभव है।

सुरक्षा, परिपक्वता, और side-channel चिंताएँ

  • एक पक्ष: ML-KEM जैसे lattice KEMs अपनी उम्र के हिसाब से उतने ही अच्छी तरह studied हैं जितना ECC mainstream होने के समय था; ML-KEM के formal analyses, deployment history हैं, और hybrid TLS पहले से व्यापक रूप से उपयोग होता है।
  • दूसरा पक्ष: PQC (और विशेष रूप से ML-KEM) नया है, जिसमें उल्लेखनीय implementation flaws हैं (जैसे KyberSlash timing leaks); मजबूत side-channel-safe implementations के लिए तकनीक अभी अपरिपक्व है।
  • इस बात की तीखी आलोचना कि FIPS 203 और ML-KEM TLS draft side-channel resistance को normative requirement के बजाय वैकल्पिक “encouragement” की तरह लेते हैं; इसे कुछ पुराने RFCs की अधिक विशिष्ट guidance से तुलना की जाती है।
  • कुछ का तर्क है कि standards स्पष्ट रूप से misuse-resistant होने चाहिए और “footguns” से बचना चाहिए, जैसे शक्तिशाली लेकिन side-channel-fragile विकल्प।

Hybrid बनाम pure ML-KEM

  • pro-hybrid दृष्टिकोण: चूँकि PQC की परिपक्वता और side-channel व्यवहार अनिश्चित हैं, PQ को मौजूदा ECC के साथ जोड़ा जाना चाहिए, बदला नहीं; कई यूरोपीय सरकारी दिशानिर्देश short–medium term में hybrid की स्पष्ट सिफारिश करते हैं।
  • hybrid के प्रति संदेहपूर्ण दृष्टिकोण: अच्छी तरह डिज़ाइन की गई schemes के लिए ECC+ML-KEM वास्तविक लाभ में मामूली है (जैसे मजबूत ciphers को cascade करना) जबकि जटिलता बढ़ाता है; एक औपचारिक proof मौजूद है कि एक निश्चित hybrid सुरक्षित रहता है, भले ही ML-KEM विफल हो जाए।
  • कुछ लोग ऐसे environments (जैसे telecoms) का उल्लेख करते हैं जिन्हें कथित रूप से pure ML-KEM का उपयोग करना “पड़ता” है, इसलिए इसे दस्तावेज़ित करना interoperability में मदद करता है, उपयोग को बाध्य नहीं करता।

NSA की भूमिका और standards पर भरोसा

  • एक पक्ष NSA की ऐतिहासिक भूमिका पर ज़ोर देता है: DES में कमजोर key sizes को आगे बढ़ाना, Dual_EC_DRBG backdoor प्रकरण, 1990s export restrictions, और वर्तमान classified Suite A algorithms — ये सभी गहरे संदेह के कारण हैं।
  • दूसरे पक्ष का प्रतिवाद है कि:
    • ML-KEM अकादमिक टीमों द्वारा डिज़ाइन किया गया था, किसी intelligence agency द्वारा नहीं।
    • मुख्य national standards body और एक signals-intelligence agency अलग-अलग हैं, और उनके प्रोत्साहन कभी-कभी टकराते हैं (offense बनाम defense)।
    • उच्च classification स्तरों पर ML-KEM का उपयोग करने की NSA की अपनी चाल किसी deliberate backdoor की बजाय भरोसे का संकेत है।
  • अल्पसंख्यक का तर्क है कि hybrids के विरुद्ध intelligence-agency pressure का पैटर्न स्वयं संदिग्ध है और अत्यधिक सावधानी को उचित ठहराता है।

RFC प्रकाशित करने (या न करने) का प्रभाव

  • कुछ लोगों का कहना है कि “not recommended” स्थिति के साथ informational RFC प्रकाशित करना केवल मौजूदा प्रथा को दर्शाता है और अन्य SDOs (जैसे telecom और wireless bodies) का समर्थन करता है जिन्होंने एक stable reference माँगा है।
  • अन्य लोग तर्क देते हैं कि कोई भी RFC, भले informational हो, “RFC sheen” देता है और deployment बढ़ाएगा, उन संदर्भों सहित जहाँ pure ML-KEM एक अनावश्यक या असुरक्षित जोखिम हो सकता है।
  • इस पर असहमति है कि “लोग पहले से ऐसा कर रहे हैं” standardize करने का वैध कारण है, या संदिग्ध practices को मुहर लगाने का रास्ता।

प्रक्रिया में हेरफेर और brigading

  • कई टिप्पणियाँ ML-KEM-only TLS के आलोचकों द्वारा TLS mailing list पर समन्वित “brigading” का आरोप लगाती हैं, जिसमें template subject lines और draft का विरोध करने के लिए सिर्फ शामिल होने के आह्वान शामिल हैं।
  • IETF प्रतिभागी दोहराते हैं कि दिखाई देने वाले “vote counts” निर्णायक नहीं होते; मजबूत तकनीकी तर्क और implementer consensus raw numbers को मात दे सकते हैं।
  • यदि WG प्रकाशित करने से इंकार करता है, तो ML-KEM codepoints वैध रहते हैं; मुख्य अंतर आधिकारिक TLS-binding RFC का खो जाना है।