الخلاصة

  • يخصص RFC 9558 رقم خوارزمية DNSSEC ‏23 لـ GOST R 34.10-2012، ونوع ملخص DS رقم 5 لـ GOST R 34.11-2012، ضمن ملف ثنائي دقيق.
  • الوثيقة Informational من مسار Independent Submission؛ لا تمثل إجماع IETF ولا شهادة مستقلة بصلاحية التشفير أو انتشار التنفيذ.
  • النتيجة القابلة للدفاع تحتاج إيصالات مستقلة للتسجيل ودعم الموقّع والنشر وDS في الأب وقدرة المدقق والتحقق من السلسلة وحالة التطبيق.

كانت المنطقة موقعة، لكن المدقق لم ير مساراً يستطيع تنفيذه

نشر مشغّل DNSKEY بالخوارزمية 23 ووقّع مجموعات السجلات وفق GOST R 34.10-2012. نشر الأب DS بنوع الملخص 5. أعاد المختبر حالة Secure، فبدت المهمة مكتملة.

عند مستخدم آخر كان المحلل التكراري لا يدعم خوارزمية المفتاح ولا خوارزمية الملخص. وفق المعالجة التي يوضحها RFC 6840، تجاهل المحلل سجلات DS الموثقة التي تشير إلى خوارزميات غير معروفة أو غير مدعومة. ولأنه لم يبق مسار آخر، تعامل مع الابن كما لو كان غير موقع.

لم يختف السجل ولم يثبت أن التوقيع مزور. الذي غاب هو القدرة التنفيذية في نقطة القرار. سجل IANA يجعل المعنى قابلاً للتنسيق؛ لا يثبت الكود في المحللات ولا ينقل النتيجة إلى التطبيق.

هوية الوثيقة تحدد حدود سلطتها

نُشر RFC 9558 في أبريل 2024 بوصفه Informational ضمن Independent Submission stream. ليس وثيقة Standards Track، ولا يحمل إجماع مجتمع IETF، ولا يحظى بتأييد رسمي في عملية معايير IETF. كما لا يقرر RFC Editor قيمته للتنفيذ أو النشر.

ويحذر النص من أن الخصائص التشفيرية للمعيارين الوطنيين الروسيين GOST R 34.10-2012 وGOST R 34.11-2012 لم تُتحقق منها جهة مستقلة في هذا السياق، وأن IETF وIRTF لم تحللا ملاءمتهما لأي تطبيق محدد.

هذه ليست إدانة تقنية تلقائية، بل قيد إثبات. الوثيقة تمنح المنفذين الذين اختاروا المجموعة طريقة موحدة لتمثيل البايتات. لا تمنحهم توصية IETF ولا تتخذ قرار المخاطر نيابة عن الطرف المعتمد.

أربعة وستون ثُمانية لا تسمح بتقريب المعنى

يختار الملف متغير التوقيع ذي 256 بت والملخص ذي 256 بت ومجموعة المعلمات A. تُمثل نقطة المنحنى Q=(x,y) في DNSKEY ضمن 64 ثُمانية: 32 ثُمانية لـ x بترتيب little-endian ثم 32 لـ y بالترتيب نفسه. يبلغ كل من المفتاح العام والتوقيع 512 بت، والملخص 256 بت.

قد تتعامل مكتبة مع نقطة رياضية صحيحة ثم تكتب ترتيب البايتات خطأ، فيفشل الطرف الآخر. ويقدم RFC بادئة ASN.1 ثابتة بطول 30 بايت لتغليف قيمة DNSKEY عند تمريرها إلى واجهات X.509 الداعمة لـ GOST. هذا محول صيغة، لا شهادة ولا مرساة ثقة.

في RRSIG يُلخص مدخل التوقيع المحدد في RFC 4034 عبر GOST R 34.11-2012 ثم يوقع عبر GOST R 34.10-2012. قيمة k المنشورة في المثال مخصصة لإعادة الإنتاج ويحظر استخدامها في توقيع حقيقي. مطابقة متجه الاختبار لا تثبت سلامة العشوائية في الإنتاج.

الرقمان 23 و5 يصفان رابطين مختلفين

يسجل IANA ‏ECC-GOST12 كخوارزمية DNSSEC رقم 23. وفي سجل منفصل يظهر GOST R 34.11-2012 كنوع ملخص DS رقم 5 وحالته OPTIONAL. يحدد 23 كيفية تفسير DNSKEY وRRSIG، بينما يحدد 5 كيفية ربط DS لدى الأب بمفتاح DNSKEY لدى الابن.

لا يغني أحدهما عن الآخر. توقيع صحيح بلا DS قابل للاستخدام لا يصل الابن بالأب. وDS مطابق بلا دعم في المدقق لا يصنع مساراً. وحتى مع الدعم، قد تغير ذاكرة مؤقتة قديمة أو مرساة ثقة مختلفة أو نافذة توقيع منتهية النتيجة.

لهذا يجب أن يضم إيصال التدقيق مجموعات DNSKEY وRRSIG وDS الفعلية، ونقطتي المراقبة عند الأب والابن، وserial، وبداية صلاحية التوقيع ونهايتها، وTTL، ومرساة الثقة، وإصدار المدقق وقائمة خوارزمياته. عبارة «DNSSEC مفعل» لا تكفي لإعادة التجربة.

غير مدعوم لا يساوي Bogus

إذا أسقط المدقق كل المسارات لأنها غير مدعومة، تعامل القواعد المنطقة كما لو كانت غير موقعة. أما Bogus فيعني أن مساراً قابلاً للفحص أخفق في الاختبارات المطلوبة. الخلط بين الحالتين يوجه الإصلاح إلى المكان الخطأ.

إعادة التوقيع لا تضيف خوارزمية إلى برنامج بعيد. وتحديث البرنامج لا يصلح RRSIG تالفة فعلاً. سجل الحادثة يجب أن يجيب: أي مدقق، بأي إصدار ومجموعة خوارزميات، رأى أي RRsets، وفي أي وقت، وبأي مرساة، وأعاد أي حالة أمنية؟

نجاح أداة واحدة دليل على نقطة المراقبة تلك، لا على سوق المحللات بأكمله.

المفتاحان KSK يفتحان جسراً ويزيدان الحالة

يوصي RFC 9558 بتوقيع المنطقة بخوارزميتي KSK إلى أن ينتشر دعم GOST في برامج DNSSEC، إلا إذا كان الاستخدام الحصري مقصوداً. يحفظ المسار الموازي المصادقة لدى المدققين الذين لا يعرفون الخوارزمية 23.

لكن ذلك يزيد المفاتيح وسجلات DS والتوقيعات والنوافذ الزمنية وتغييرات الأب وحالات الذاكرة المؤقتة. يوصي RFC 6840 بقبول أي RRSIG صالحة وبالحكم Bogus فقط إذا أخفقت كلها، إلا أن السياسة المحلية المقيدة واختلاف زمن المراقبة قد يصنعان نتائج متباينة.

يجب تعريف الخروج قبل الدخول. بعد إضافة المسار الجديد تُقاس مجموعات المدققين المهمة. وقبل حذف القديم يُتحقق من DS لدى الأب والنشر لدى الابن وانقضاء TTL من شبكات مستقلة. ظهور مفتاحين ليس إيصالاً يسمح بحذف أحدهما.

تنتهي DNSSEC قبل قرار التطبيق

تثبت Secure أن RRset موثقة وفق قواعد DNSSEC نسبة إلى مرساة ثقة محددة وفي وقت محدد. لا تثبت الهوية القانونية للمشغل، ولا صلاحية الخوارزمية لكل سياسة، ولا توافر الخدمة، ولا نجاح الاتصال التالي.

يطلب DO بيانات DNSSEC، ويغير CD سلوك الفحص، وينقل AD حالة المصادقة ضمن شروط. إذا كانت القناة بين stub والمحلل غير موثوقة، أو كان التطبيق لا يستهلك الحالة، فلا يتحول البت إلى دليل طرف إلى طرف.

الإيصال الأخير يسمي المحلل الموثوق والقناة والحالة والسياسة والقرار والأثر المرصود. RFC 9558 يعرّف كائناً يمكن التحقق منه؛ لا يمنح التطبيق سلطة التصرف.

المصادر

المصادر