يحصر DANCE 14 أربع نتائج TLSA في قرار ثنائي للخادم

الخلاصة

• نُشر draft-ietf-dance-client-auth-14 في 11 سبتمبر، وما زال Internet-Draft ضمن المراجعة النهائية لمجموعة العمل؛ ليس RFC ولا معياراً معتمداً.
• يسمي الإصدار أربعة نواتج غير مجموعة TLSA متحقق منها عبر DNSSEC: فشل التحقق، وإجابة غير موثّقة، وNXDOMAIN، وNODATA. يجب على الخادم الإنهاء، أو اعتبار العميل غير موثّق إن سمحت سياسته.
• يستطيع سجل قرار مقتضب حفظ فئة نتيجة DNS ومسار الثقة وإصدار السياسة وقرار التخويل اللاحق. هذا اقتراح تحريري لا مطلب جديد من IETF.

التعديل واضح، أما الإقرار فلم يحدث

تؤرخ صفحة Datatracker الإصدار 14 من «TLS Client Authentication via DANE TLSA records» في 11 سبتمبر 2026. الوثيقة من عمل مجموعة DANCE النشطة في مجال الأمن لدى IETF، وحالتها المستهدفة Proposed Standard. لكن وضعها الحالي يبقى In WG Last Call مع متابعة من مسؤول الوثيقة، بينما يعرض مسار IESG الحالة Waiting for AD Go-Ahead::AD Followup.

هذه أسماء لمواقع داخل الإجراء، لا شهادة اعتماد. يبين السجل التاريخي أن الإصدار 13 وصل في 23 يوليو، ثم عادت حالة مجموعة العمل في 28 يوليو من Submitted to IESG for Publication إلى In WG Last Call. قُبل الإصدار 14 في 11 سبتمبر من دون أن تتحول الوثيقة إلى RFC.

يكمن التغيير الجوهري في فقرة قصيرة من سلوك الخادم. كان الإصدار 13 يحدد المسار عند فشل تحقق DNSSEC. أما الإصدار 14 فيشمل أي نتيجة ليست مجموعة سجلات TLSA متحققاً منها عبر DNSSEC، ثم يذكر أربع فئات صراحة.

جميع الفئات تصل إلى الخيار المعياري نفسه: إنهاء الاتصال بتنبيه TLS من نوع handshake_failure، أو، إذا سمحت سياسة الخادم، معاملة العميل كطرف غير موثّق. زادت دقة وصف المدخلات، وبقي تقدير المخاطر في موقع التشغيل.

العميل يحدد الاسم المطلوب

يُعرف DANE في RFC 6698 وRFC 7671 باستخدام TLSA كي يتحقق العميل من شهادة الخادم أو مفتاحه. تنقل مسودة DANCE الفكرة إلى مصادقة العميل.

يعلن الخادم الداعم الامتداد المقترح dane_clientid داخل CertificateRequest. ويرسل العميل الراغب في DANE الاسم الكامل لمالك سجل TLSA ضمن رسالة Certificate. لا يشتق الخادم اسماً من المنفذ أو بروتوكول النقل؛ بل يسأل عن الاسم الذي قدمه العميل كما هو. ويتطلب ذلك TLS 1.3 أو DTLS 1.3 على الأقل.

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

عند موعد البحث، لا يعرض سجل IANA لامتدادات TLS قيمة مخصصة لـ dane_clientid. وتكتب المسودة عن قيمة ستُخصص مستقبلاً. لذلك لا يجوز افتراض رقم أو انتشار أو دعم منتجات.

أربعة أوصاف لا تعني «فشل DNSSEC» واحداً

يعني فشل التحقق من DNSSEC أن البيانات لم تنجح في المصادقة وفق سلسلة الثقة والقواعد المطبقة. لا يثبت ذلك وحده وقوع هجوم، ولا يحدد جهة الخطأ.

أما الإجابة غير الموثّقة بسبب نطاق غير موقع أو تفويض غير آمن فحالة مختلفة. هنا لا تكتمل سلسلة تطلب بيانات موثقة؛ وليست بالضرورة بيانات موقعة ثبت بطلانها. يحافظ RFC 4033 على الفرق بين النطاق الموقع وغير الموقع وما تفرضه مرساة الثقة.

تعني NXDOMAIN أن الاسم المطلوب غير موجود. أما NODATA فتسمح بوجود الاسم مع غياب نوع TLSA المطلوب. يثبت RFC 2308 هذا الفرق في معالجة إجابات DNS السلبية. حذف هوية جهاز ليس كإنشاء الاسم من دون نشر الاعتماد.

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

إذا حفظ السجل handshake_failure فقط، تلاشت الفروق الأربعة. وإذا استمر الاتصال ولم يُسجل سوى «نجاح بلا مصادقة»، تضيع أيضاً. صحة قرار السياسة لا تكفي لجعل أثره قابلاً للمراجعة.

المطابقة ثم التخويل

الحصول على مجموعة TLSA متحقق منها لا ينهي المصادقة. على الخادم تطبيق حقول استخدام الشهادة والمحدد ونوع المطابقة على شهادة العميل أو مفتاحه العام. وعند فشل المطابقة، تفتح المسودة مرة أخرى خيار الإنهاء أو المعاملة كعميل غير موثّق وفق السياسة.

المطابقة الناجحة تثبت هوية العميل ضمن آلية DANE، ولا تمنحه كل صلاحيات التطبيق. تسمح الوثيقة بقوائم سماح وقواعد تخويل مستقلة، مثل قبول هويات من نطاقات محددة. قد يكون العميل موثّقاً لكنه غير مخوّل، وقد يصل العميل غير الموثّق إلى سطح عام محدود فقط.

لهذا ينبغي فصل ثلاث مراحل: نتيجة DNS، ومطابقة DANE للشهادة أو المفتاح، وتخويل التطبيق. دمجها في خانة «نجاح» واحدة يخفي الجهة التي اتخذت كل قرار.

سجل صغير مع حماية الهوية

ليس الحل وضع ملف الحادث كاملاً في TLS. قد تكشف أسماء العملاء أشخاصاً أو أجهزة أو أدواراً، وتحذر اعتبارات الأمن في المسودة من قابلية الربط. أقترح سجل قرار البحث محلياً ومحدود الوصول. هذا اقتراح Daniel Kade التحريري، لا شرطاً من IETF أو DANCE أو IANA.

يربط السجل زمن الملاحظة، وصيغة مصرحاً بها أو تجزئة محمية لاسم TLSA الذي قدمه العميل، ونوع السؤال، وإحدى الفئات الأربع، وحالة DNSSEC، وهل جرى التحقق محلياً أم عبر محلل محمي، ومرجع مرساة الثقة أو سياسة الحل، وإصدار سياسة الخادم، والفرع المختار. وإذا وصل التنفيذ إلى مطابقة الشهادة والتخويل، يسجلهما في حقلين منفصلين.

تكتب المرحلة التي لم يصلها التنفيذ بوصفها لم تُبلَغ. لا يجوز استنتاج عدم تطابق شهادة بعد NXDOMAIN، ولا تحويل تفويض غير آمن إلى بيانات زائفة. تتبع مدة الاحتفاظ وصلاحيات القراءة حساسية الهوية. ويمكن للتقرير العام نشر أعداد مجمعة وتغييرات السياسة من دون أسماء العملاء أو سجل اتصالاتهم.

يطلب Policy Mirror لهينغ لو فصل الفاعل والقاعدة والدليل. مشغل DNS يتحكم في الاسم والتفويض، والعميل يقدم هوية البحث، والخادم يختار مسار التحقق وسياسة TLS، والتطبيق يقرر الصلاحيات. وتحافظ Minimum Initial Specification على الخيارات المستقبلية بإبقاء النواة المشتركة محدودة. يفعل الإصدار 14 ذلك؛ والسجل يحفظ سبب الاختيار المحلي من دون نقله إلى البروتوكول.

المصادر

1. IETF Datatracker — draft-ietf-dance-client-auth-14
2. سجل الوثيقة
3. الإصدار 13
4. الإصدار 14
5. مجموعة DANCE
6. RFC 6698 — DANE TLSA
7. RFC 7671 — تشغيل DANE
8. RFC 2308 — التخزين السلبي في DNS
9. RFC 4033 — مقدمة DNSSEC ومتطلباته
10. سجل IANA لأنواع امتدادات TLS
11. Heng Lu — The Policy Mirror
12. Heng Lu — Minimum Initial Specification