سرویس 1.1.1.1 اکنون امضاهای DNSSEC ایجاد شده با الگوریتم ML-DSA-44 را که یک الگوریتم امضای پساکوانتمی استانداردشده توسط ملی استاندارد و فناوری آمریکا (NIST) است، اعتبارسنجی میکند. این گام نخست در راستای آمادهسازی DNSSEC برای آیندهای است که در آن الگوریتمهای امضای امروزی دیگر امن نخواهند بود.
شرکت کلودفلر (Cloudflare) برنامهریزی کرده است تا به امنیت کامل پساکوانتمی تا سال ۲۰۲۹ دست یابد. بیشتر کارهای انجام شده تاکنون بر روی پروتکل TLS متمرکز بوده، اما رمزنگاری کلید عمومی در بسیاری از سیستمهای دیگر از جمله DNSSEC نیز استفاده میشود.
در حالی که ما در سال ۲۰۱۹ آزمایش توافق کلید پساکوانتمی را در TLS آغاز کردیم و پشتیبانی از آن را در سال ۲۰۲۲ برای تمامی مشتریان فعال نمودیم، امضاهای پساکوانتمی هنوز آزمایشهای مشابهی را در DNSSEC دریافت نکردهاند. همچنین مقداری فوریت وجود دارد. پذیرش گسترده مشتریان از TLS پساکوانتمی سالها طول کشید، تا حدی به این دلیل که پیامهای بزرگتر، مفروضات و اشکالات موجود در نرمافزارهای شبکه را آشکار کردند. این تجربه نشان داد چرا آزمایشهای زودهنگام در مقیاس وسیع اهمیت دارند. ما نمیتوانیم منتظر بمانیم تا رایانههای کوانتومی به یک تهدید فوری تبدیل شوند.
مشکل این است که امضاهای پساکوانتمی بزرگ هستند. هر امضای ML-DSA-44 دارای اندازه ۲,۴۲۰ بایت است که قبل از اینکه پاسخ شامل چیز دیگری شود، محدودیتهای رایج DNS-over-UDP را پشت سر میگذارد. در عین حال، مناطق باید امضاهای سنتی را برای حلکنندههای قدیمیتر برای سالها منتشر کنند که در صورت عدم اعتبارسنجی صحیح، یک مسیر تنزل (downgrade) احتمالی ایجاد میکند. چالش این است که این پاسخهای بسیار بزرگ را به طور قابل اعتماد منتقل کنیم، بدون اینکه سازگاری با حلکنندههای قدیمیتر باعث تضعیف حفاظت برای حلکنندههای جدیدتر شود.
با فعال شدن اعتبارسنجی ML-DSA-44، سرویس 1.1.1.1 به ما اجازه میدهد هر دو چالش را در مقیاس اینترنت آزمایش کنیم: حمل پاسخهای بزرگتر DNS و جلوگیری از بازگشت به امضاهای سنتی.
چرا DNSSEC پساکوانتمی اهمیت دارد
پاسخهای DNS به طور پیشفرض احراز هویت نمیشوند. مهاجمی که میتواند یک پاسخ را جعل کند ممکن است بتواند کاربران را به یک آدرس دلخواه هدایت کند. DNSSEC با امضا کردن رکوردهای DNS از این امر جلوگیری میکند. یک حلکننده اعتبارسنجی مانند 1.1.1.1 زنجیرهای از رکوردهای امضاشده را از ریشه DNS تا دامنه درخواستشده دنبال میکند تا بررسی کند پاسخ معتبر است و تغییر نکرده است.
سیستم DNSSEC از چندین الگوریتم امضا پشتیبانی میکند، اما تقریباً تمام آنهایی که امروزه استفاده میشوند در برابر رایانههای کوانتومی آینده آسیبپذیر هستند. الگوریتمهای RSA و ECDSA بر روی مسائل ریاضی تکیه میکنند که اعتقاد بر این است برای رایانههای سنتی در اندازههای کلید مستقر غیرقابل حل هستند. ما برای این احتمال آماده میشویم که در سال ۲۰۳۰ یک رایانه کوانتومی به اندازه کافی قدرتمند ساخته شود که این کلیدها را بشکند. سپس یک مهاجم میتواند کلید خصوصی مربوطه را بازیابی کند و امضاهای جعلی ایجاد کند که اعتبارسنجیها بپذیرند.
رایانههای کوانتومی قادر به انجام این حملات امروز وجود ندارند. سیستم DNSSEC اصالت را به جای محرمانگی فراهم میکند، بنابراین مشمول حملات «اکنون جمعآوری کن، بعداً رمزگشایی کن» نمیشود. دلیل شروع کار اکنون این است که تغییر DNSSEC نیازمند هماهنگی در سرورهای معتبر (authoritative)، رجیستریها، رجیسترارها و حلکنندههای اعتبارسنجی است. مهاجرت باید در نهایت به بالای سلسله مراتب DNS برسد، جایی که یک کلید به خطر افتاده بیشترین تأثیر را دارد. یک مهاجم که یک کلید امضای منطقه ریشه را با استفاده از یک رایانه کوانتومی بازیابی کند، میتواند یک مسیر اعتبارسنجی برای هر منطقهای در زیر آن جعل کند: «یک بار بشکن، همجا جعل کن». الگوریتم ML-DSA-44 یک نقطه شروع استاندارد برای آن مهاجرت فراهم میکند و پشتیبانی از آن در 1.1.1.1 به ما و اکوسیستم گستردهتر DNS اجازه میدهد تا تجربه عملیاتی به دست آوریم.
چرا جایگزینی الگوریتم دشوار است
سیستم DNSSEC برای پشتیبانی از الگوریتمهای جدید طراحی شده است. در اصل، پشتیبانی از ML-DSA-44 به معنای انتشار کلید عمومی آن و آموزش اعتبارسنجیها برای تأیید امضاهای آن است. در عمل، دو ویژگی انتقال را دشوار میکند: امضاها بزرگ هستند و الگوریتم قدیمی همیشه نمیتواند به طور ایمن حذف شود.
یک امضای ۲۴۲۰ بایتی بسته را تغییر میدهد
الگوریتمهای DNSSEC که امروزه معمولاً استفاده میشوند امضاهای نسبتاً کوچکی تولید میکنند. به عنوان مثال، الگوریتم ECDSA P-256 یک امضای ۶۴ بایتی تولید میکند. یک امضای ML-DSA-44 دارای اندازه ۲,۴۲۰ بایت است که تقریبا ۳۸ برابر بزرگتر است.
این تفاوت اهمیت دارد زیرا بسیاری از سیستمهایی که پیامهای DNS را ارسال، حمل و دریافت میکنند به اندازه پیام حساس هستند. سیستم DNS در ابتدا پیامهای ارسال شده از طریق UDP را به ۵۱۲ بایت محدود کرده بود. استاندارد EDNS(0) بعداً به یک حلکننده اجازه داد تا بزرگترین پاسخ UDP را که مایل به پذیرش آن از یک سرور نام است، تبلیغ کند. بسیاری از پیادهسازیهای DNS از محدودیت محتاطانه بار مفید UDP یعنی ۱,۲۳۲ بایت استفاده میکنند که برای جا شدن در حداقل MTU پروتکل IPv6 یعنی ۱۲۸۰ بایت انتخاب شده است. اخیراً، استاندارد RFC 9715 حداکثر ۱,۴00 بایت را برای DNS over UDP توصیه کرده است. یک امضای ML-DSA-44 به تنهایی از آن بودجه فراتر میرود، پیش از اینکه مجموعه رکوردهای امضاشده (RRset)، نامهای دامنه، هدرهای DNS و سایر رکوردهای DNSSEC به حساب بیایند. ارسال چنین پاسخی به عنوان UDP قطعه قطعه شده (fragmented) غیرقابل اعتماد است و باید از آن اجتناب شود. در عوض، سرور معتبر باید یک پاسخ ناقص (truncated) برگرداند و حلکننده را ترغیب کند که با استفاده از یک پروتکل انتقال دیگر، معمولاً TCP، دوباره تلاش کند.
این اثر در پاسخهای DNSKEY که حاوی کلیدهای مورد نیاز یک حلکننده برای اعتبارسنجی منطقه است، بیشتر قابل مشاهده است. یک کلید عمومی ML-DSA-44 دارای اندازه ۱,۳۱۲ بایت است و مجموعه رکوردهای DNSKEY RRset همچنین یک امضای ۲,۴۲۰ بایتی را حمل میکند. الگوریتم ML-DSA-44 نمیتواند به طور کامل جایگزین الگوریتمهای امضای سنتی شود تا زمانی که به طور گسترده در سراسر اکوسیستم DNS پشتیبانی شود، فرآیندی که احتمالاً سالها طول خواهد کشید. تا آن زمان، پاسخهای DNSKEY ممکن است حاوی کلیدها و امضاهای سنتی و پساکوانتمی باشند تا با اعتبارسنجیهای قدیمیتر سازگار بمانند. چرخش کلیدها (key rollovers) میتواند کلیدهای بیشتری را اضافه کند و این پاسخها را دوباره بزرگتر کند.
حهتدهی DNS از طریق پروتکلهای انتقالی غیر از UDP به خودی خود غیرعادی نیست. دادههای Cloudflare Radar نشان میدهد که حدود ۸۵ درصد از پرسوجوها به 1.1.1.1 از طریق UDP میرسند. پلتفرم پشتیبان 1.1.1.1 یعنی Big Pineapple نیز از سایر خدمات DNS از جمله Gateway DNS پشتیبانی میکند. در تمامی خدمات مدیریت شده توسط Big Pineapple، حدود ۶۰ درصد از پرسوجوها از طریق UDP میرسند. ۴۰ درصد باقیمانده از پروتکلهای انتقالی مانند TCP، پروتکل DNS over TLS (DoT) و DNS over HTTPS (DoH) استفاده میکنند.
این ارقام نحوه رسیدن پرسوجوها به خدمات حلکننده کلودفلر را توصیف میکنند، نه اینکه چگونه 1.1.1.1 با سرورهای معتبر ارتباط برقرار میکند. پاسخهای بزرگ ML-DSA-44 همچنان میتواند باعث تلاش مجدد TCP اضافی در آن طرف شود، اما مدیریت DNS از طریق پروتکلهای انتقالی غیر از UDP از قبل یک بخش عادی از عملیات 1.1.1.1 در مقیاس است.
پشتیبانی از دو الگوریتم خطرات تنزل نسخه (Downgrade) را به همراه دارد
جایگزینی یک الگوریتم موجود DNSSEC نمیتواند یکباره اتفاق بیفتد. اگر یک منطقه تنها ML-DSA-44 را منتشر کند، حلکنندههایی که از آن پشتیبانی نمیکنند نمیتوانند منطقه را اعتبارسنجی کنند. بنابراین مسیر مهاجرت عملی این است که کلیدها و امضاهای سنتی و پساکوانتمی را با هم منتشر کنیم.
این کار سازگاری را حفظ میکند، اما امنیت پساکوانتمی را به خودی خود فراهم نمیکند. استاندارد RFC 6840 مشخص میکند که «اعتبارسنجیها باید هر مسیر معتبر منفرد را بپذیرند.» این قانون به اعتبارسنجیها اجازه میدهد از هر الگوریتم منتشر شدهای که پشتیبانی میکنند استفاده کنند.
با این حال، هنگامی که یک الگوریتم سنتی مانند ECDSA دیگر امن نباشد، همان رفتار یک مسیر تنزل ایجاد میکند. یک مهاجم میتواند پاسخ فقط ECDSA را جعل کند که یک حلکننده با وجود پشتیبانی از ML-DSA-44 آن را میپذیرد.
جلوگیری از این تنزل نیازمند یک سیگنال احراز هویتشده است که نشان دهد یک منطقه باید با ML-DSA-44 اعتبارسنجی شود. سرویس 1.1.1.1 از رکوردهای DS منتشر شده توسط منطقه والد برای این منظور استفاده میکند. اگر مجموعه رکوردهای احراز هویتشده DS RRset شامل رکوردی برای یک الگوریتم پساکوانتمی پشتیبانیشده باشد، سیگنال موجود است.
سپس 1.1.1.1 عمداً یک خط مشی اعتبارسنجی محلی محدودکنندهتر را اعمال میکند. این نیاز به حداقل یک مسیر اعتبارسنجی پساکوانتمی معتبر دارد؛ یک مسیر سنتی دیگر کافی نیست. اگر هیچ مسیر ML-DSA-44 اعتبارسنجی نکند، اعتبارسنجی شکست میخورد. این رفتار اعتبارسنجی معمولی DNSSEC نیست (هنوز)، اما استاندارد RFC 4035 به خط مشی حلکننده محلی اجازه میدهد تعیین کند که آیا امضاهای اضافی باید بررسی شوند و نتایج متناقض چگونه مدیریت شوند.
امضاهای سنتی میتوانند برای حلکنندههای قدیمیتر در دسترس بمانند بدون اینکه به حلکنندههای دارای قابلیت پساکوانتم اجازه دهند به آنها بازگردند. سیگنال تنزل تنها در صورتی پساکوانتمی امن است که استقرار ML-DSA-44 و حفاظت در برابر تنزل از لنگر اعتماد (trust anchor) تا هر تفویض اختیاری (delegation) گسترش یابد. چرخش مکرر کلید منطقه مشکل را حل نمیکند: یک مهاجم میتواند یک کلید آسیبپذیر را در هر کجای بالاتر زنجیره هدف قرار دهد و هر تفویض اختیاری را در زیر آن جعل کند.
مسیر پیش روی DNSSEC پساکوانتمی
افزودن یک الگوریتم پساکوانتمی به DNSSEC نیازمند چیزی بیش از استانداردسازی رمزنگاری است. این امر نیازمند پیادهسازیها در کتابخانههای رمزنگاری، یک شماره الگوریتم DNSSEC تخصیصیافته توسط IANA، پشتیبانی از سرورهای معتبر و حلکنندههای اعتبارسنجی، و پذیرش در سراسر زنجیره تفویض DNS است. الگوریتم ML-DSA-44 اکنون پیشنیازهای اولیه برای استقرار را دارد. سازمان NIST آن را استاندارد کرده است و کتابخانههای رمزنگاری رایج آن را پیادهسازی میکنند. استفاده از آن در DNSSEC در پیشنویس اینترنت ML-DSA for DNSSEC توصیف شده است و سازمان IANA اخیراً شماره الگوریتم DNSSEC 18 را به آن اختصاص داده است.
افزودن اعتبارسنجی ML-DSA-44 به حلکنندهها یکی از مراحل اولیه استقرار است، اما یک زنجیره اعتماد کامل پساکوانتمی ایجاد نمیکند. سرورهای معتبر باید مناطق را با ML-DSA-44 امضا کنند، رجیسترارها باید رکوردهای DS مربوطه را بپذیرند و ارسال کنند، و رجیستریها باید آنها را در مناطق والد منتشر کنند.
این پذیرش باید از طریق هر منطقه والد تا ریشه DNS گسترش یابد. ریشه باید ML-DSA-44 را اتخاذ کند و کلید پساکوانتمی آن باید به عنوان لنگر اعتماد برای حلکنندههای اعتبارسنجی تبدیل شود. هر سطحی بدون حفاظت پساکوانتمی به عنوان یک نقطه تنزل باقی میماند.
امضا کردن یک منطقه با ML-DSA-44 اگر هیچ حلکنندهای امضاهای آن را اعتبارسنجی نکند، ارزش کمی دارد. بنابراین فعال کردن پیشفرض اعتبارسنجی ML-DSA-44 روی 1.1.1.1 یک گام اولیه مهم است. این کار به ما اجازه میدهد هزینه عملیاتی تأیید امضا، پهنای باند اضافی، و افزایش استفاده از TCP بین حلکنندهها و سرورهای معتبر را اندازهگیری کنیم.
مانند مهاجرتهای قبلی، ما همچنین قابلیت استقرار در دنیای واقعی را با استفاده از پروبهای پسزمینه روی کسری کوچک از صفحات چالش کلودفلر Cloudflare Challenge Pages آزمایش خواهیم کرد. این پروبها بررسی خواهند کرد که آیا مشتریان میتوانند یک دامنه آزمایشی امضاشده با ML-DSA-44 را در شبکههای واقعی حل و به آن دسترسی پیدا کنند. ما از سایر اپراتورها و پیادهکنندگان DNS دعوت میکنیم تا آزمایش ML-DSA-44 را در مقیاس آغاز کنند. در مجموع، این اندازهگیریها نشان خواهند داد که با رشد پذیرش، چه تنظیماتی مورد نیاز است.
این موضوع برای شما چه معنایی دارد
اگر از 1.1.1.1 استفاده میکنید، نیازی به تغییر هیچ چیزی ندارید. اعتبارسنجی ML-DSA-44 به طور خودکار هنگامی رخ میدهد که یک منطقه رکوردهای لازم DNSSEC را منتشر کند، در حالی که مناطق موجود DNSSEC به اعتبارسنجی خود مانند قبل ادامه میدهند.
این کار سمت حلکننده DNS را پوشش میدهد. گام بعدی ما افزودن پشتیبانی امضای ML-DSA-44 به سرویس Cloudflare Authoritative DNS و پشتیبانی از رکورد DS مربوطه به Cloudflare Registrar است که برای همه مشتریان رایگان خواهد بود. این کار به ما اجازه میدهد کل مسیر، از تولید امضا و انتشار رکوردهای DNSKEY گرفته تا انتقال و اعتبارسنجی آنها از طریق 1.1.1.1 را آزمایش کنیم.
میخواهید DNSSEC پساکوانتمی را در عمل ببینید... تمام ۲,۴۲۰ بایت آن را؟ منطقه dnstest.dev ما را با استفاده از 1.1.1.1 پرسوجو کنید:
شما همچنین میتوانید از ابزار بررسی حلکننده DNS پساکوانتمی برای تست حلکننده فعلی خود استفاده کنید. جامعه در حال پیگیری پشتیبانی نرمافزاری ML-DSA-44 در گیتهاب است.
منبع: blog.cloudflare.com