الخلاصة

  • تجمع draft-ietf-tls-tlsflags-18 ما يصل إلى 2040 إشارة خالية من المحتوى في امتداد TLS واحد. وهي مسودة نشطة مقصود بها Proposed Standard وحالتها I-D Exists، لا RFC ولا تقرير نشر؛ والنسخة 18 تحديث صيانة.
  • قد يعني البت دعماً أو نية استخدام، وقد يكون اقتراحاً أو إقراراً أو إعلاناً مسموحاً بلا طلب. تحدد مواصفة كل علامة رسائلها وحاجتها إلى جواب وتفاعلها مع 0-RTT.
  • يقترح Daniel Kade غلاف تفسير يربط البت بالرسالة والدور والاتجاه والمرجع والـ transcript والاستئناف والنتيجة والقرار المحلي. هذا ضبط تحريري لا متطلب من IETF.

أراد فريق الامتثال نسبة بسيطة للخوادم التي «فعّلت» ميزة TLS. كان المخزن يسجل أرقام العلامات، فصار عدّ البتات بديلاً عن فحص الجلسات. لاحقاً تبيّن أن معظم الزيادة جاءت من NewSessionTicket يعلن احتمالاً لاتصال مستقبلي، لا من استعمال الميزة في الاتصال الحالي.

لم يكذب العداد. إنما أعطى الإعلان اسم التنفيذ.

تاريخ حديث لا يغيّر منزلة الوثيقة

تصف صفحة Datatracker النسخة 18 المنشورة في 10 سبتمبر 2026 بأنها Internet-Draft نشطة في مجموعة TLS، ومقصدها Proposed Standard. ما زالت حالة IESG هي I-D Exists وحالة المجموعة Waiting for Implementation، من دون AD مسؤول أو موعد telechat.

يبين السجل والفرق الرسمي 17→18 أن التعديل يقتصر على رقم النسخة والتاريخ والانتهاء. لم تتغير قواعد العمل. إطالة صلاحية المسودة إلى مارس 2027 ليست موافقة نهائية ولا اختبار تشغيل بيني ولا دليلاً على التبني.

تعالج مجموعة TLS تكلفة حقيقية. حتى الامتداد الذي لا يحمل شيئاً سوى حضوره يستهلك أربعة octets. وإذا كررت وظائف اختيارية كثيرة الغلاف نفسه، ازدادت الكلفة. سلسلة بتات واحدة تخفض الكلفة الحدية.

لكنها تضغط الصياغة ولا توحّد دورة حياة الميزات.

أقصر ترميز لا يصنع معنى كاملاً

تعرف النسخة 18 سلسلة من octet واحد إلى 255، أي المواضع 0–2039. يبدأ الترتيب من البت الأقل أهمية ويجب أن ينتهي عند octet الذي يحوي أعلى بت مضبوط. القيمة الصفرية كلها أو الأصفار الزائدة في النهاية غير صالحة وتؤدي إلى illegal_parameter قاتل.

تضمن هذه القاعدة أن يجد الطرفان الموضع نفسه وأن يرفضا الصيغ غير الدنيا. لكنها لا تجعل كل بت حكماً واحداً. تعريف المسودة يقول إن الحضور قد يدل على support أو intent to use.

الدعم قدرة في البرنامج. النية اختيار لهذه المعاملة. الاقتراح حدث في رسالة. الإقرار حدث آخر حين تطلبه المواصفة الخاصة. أما تشغيل الوظيفة ونجاحها وقبول أثرها في سياسة التطبيق فهي أدلة لاحقة.

الحقل enabled=true يطوي السلسلة كلها داخل كلمة لم يقلها البروتوكول.

موضع الرسالة يحدد الفعل

يجوز إرسال علامة بلا طلب في ClientHello وCertificateRequest وNewSessionTicket. أما وجودها في ServerHello أو EncryptedExtensions أو Certificate أو HelloRetryRequest فيحتاج إلى اقتراح سابق ملائم. والإجابة غير المطلوبة خطأ قاتل.

في ClientHello يقترح العميل. وفي رسالة جواب من الخادم قد تكون العلامة إقراراً إذا طلبت مواصفتها ذلك. وفي NewSessionTicket يعلن الخادم من دون رسالة جواب من العميل. وبين CertificateRequest وCertificate ينعكس اتجاه الاقتراح والإجابة.

لا تستطيع خانة «مدعوم» تمثيل هذه الأفعال. وحتى نموذج offer/accept الثابت يخطئ في العلامات التي لا تتطلب إقراراً. تسجل المسألة 19 سبب إسناد قاعدة الإقرار إلى كل علامة على حدة.

لذلك قد يكون غياب الجواب هو السلوك الصحيح، لا رفضاً.

الإقرار بالعلامة لا يثبت استعمالها

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

تطابق البتين يثبت اتباع قاعدة الإشارة. لا يثبت أن الوظيفة عملت لاحقاً أو نجحت أو بقيت مسموحة بعد تقييم السياسة.

يوضح RFC 8446 الحد عبر post_handshake_auth. يقول العميل إنه مستعد لمصادقة لاحقة. لا يثبت ذلك أن الخادم أرسل CertificateRequest، ولا أن العميل قدم شهادة، ولا أن التطبيق منح صلاحية. الاستعداد والطلب والإنجاز والترخيص أربع وقائع.

يحتاج 0-RTT إلى ترتيب زمني محفوظ

في استئناف TLS 1.3 قد تخرج بيانات 0-RTT قبل اكتمال المصافحة الجديدة. يمكن أن يظهر وعاء العلامات في الرسائل، لكنه لا يمنح كل علامة مستقبلية معنى موحداً للبيانات المبكرة. على مواصفة العلامة أن تحدد هذا التفاعل.

تفصل المسألة 16 المسؤوليات: الوعاء إطار ترميز، وكل ميزة مسؤولة عن معنى 0-RTT. قد تورث ميزة قراراً من ticket، وقد تحتاج أخرى إلى إقرار جديد، وقد يخص إعلان ثالث استئنافاً قادماً فقط.

إذا حذف المخزن نوع المصافحة وعرض 0-RTT وقبوله والـ ticket والوقت، استطاع true المتأخر أن يغيّر معنى bytes أُرسلت قبله. في قرار هوية أو أمن، ينسب ذلك إلى الفعل إذناً لم يكن موجوداً عند وقوعه.

عدم الرؤية ليس عدم الإرسال

تحذر المسودة من أن الإقرار في ServerHello وHelloRetryRequest ظاهر للمراقب السلبي، وتقترح عادة رسالة مشفرة حين لا تلزم الرؤية العامة.

يرى حساس المسار المواضع الواضحة ولا يقرأ EncryptedExtensions. ترى نقطة النهاية transcript بعد فك الحماية لكنها تحمل سلطة وواجب احتفاظ مختلفين. ويسجل TLS terminator المقطع الذي شارك فيه لا كل اتصال آخر.

لذلك يجب أن تحمل عبارة «لم تُرصد العلامة» نقطة المراقبة والرسائل المرئية ونافذة الالتقاط وإصدار parser. جهل الحساس ليس صمت النظير.

السجل ينسق رقماً ولا يشهد بالتنفيذ

تطلب النسخة 18 سجلاً باسم TLS Flags يضم Value وFlag Name وMessage وRecommended وReference. تحتاج القيم 0–15 إلى Standards Action، وتستخدم 16–2039 سياسة Specification Required في RFC 8126. والمدخل الأول المقترح هو 8 resumption_across_names في NewSessionTicket مع Recommended N.

عند قطع البحث، كان سجل IANA ExtensionType يعرض الوعاء tls_flags نفسه بالقيمة 62 وفي CH وSH وHRR وEE وCR وCT وNST، مع Recommended N ومرجع إلى النسخة 14. هذه حالة تنسيق رقمية، لا شهادة بأن منتجاً ينفذ علامة بعينها.

يشرح RFC 8447 أن N لا يعني خللاً بالضرورة؛ فقد يكون الاستخدام محدوداً أو خاصاً أو لم يحصل على الإجماع المطلوب. وموافقة designated expert ليست تزكية. دفعت المسألة 32 نحو Y/N/D والاعتراف بإمكان تغيير Recommended لاحقاً.

ما زال TLS 1.3 bis وعمل سجل TLS bis قيد التطوير. يدل السجل إلى موضع القاعدة؛ أما الرسالة والتنفيذ والقرار فلها أدلتها.

التنبيه القاتل دليل محدود

يمكن لقيمة صفرية أو طول غير أدنى أو جواب بلا اقتراح أن يوقف المصافحة. يجوز للسجل أن يثبت الرسالة والاتجاه والـ bytes والقاعدة والتنبيه.

لكنه لا يثبت تلقائياً أن السبب مكتبة قديمة أو snapshot متأخر أو serializer معطلاً أو تجربة خاطئة أو هجوماً. تحفظ الواقعة أولاً، ثم يضاف التشخيص وصاحب الإصلاح وقرار الاستئناف بأدلة مستقلة.

غلاف تفسير العلامة

يقترح Daniel Kade غلاف تفسير لكل ملاحظة. يحفظ مرجعاً محدوداً إلى transcript من دون أسرار، وإصدار TLS، ومصافحة كاملة أو مستأنفة، وحالة 0-RTT، ودور المرسل والاتجاه والرسالة، وقيمة الوعاء وهاش السلسلة وطولها الأدنى وموضع البت وsnapshot السجل والمواصفة المعرفة وإصدارها.

ثم يصنف الحدث: اقتراح أو إقرار أو إعلان مسموح؛ هل يلزمه جواب، وما الاقتراح السابق المرتبط، وما نتيجة التحقق. ويفصل الرؤية السلبية عن معرفة endpoint ويحفظ إصدار parser والسياسة.

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

ليس هذا الغلاف مطلباً في المسودة ولا تغييراً لـ TLS. إنه يمنع معلومة صحيحة عن رسالة من التحول إلى حالة لم يشهد بها أحد.

سلّم للادعاءات

«شوهد البت 8 في NewSessionTicket» ملاحظة. «أعلن الخادم الاستئناف بين الأسماء وفق الإصدار R» تفسير. «حاول العميل لاحقاً» تنفيذ. «قبل الخادم تحت السياسة P» قرار. «منح التطبيق صلاحية للهوية» يحتاج دليلاً إضافياً.

يوفر الوعاء bytes مكررة. ولا ينبغي للنظام أن يوفر الأفعال أيضاً. علامة TLS تثبت بتاً في رسالة؛ وحدها لا تسجل حالة الميزة.

المصادر