الخلاصة

  • المراجعة 03 هي Internet-Draft نشطة، وليست RFC ولا دليلاً على تنفيذ أو نشر أو قابلية تشغيل بيني.
  • يعلن كل طرف أكبر نص صريح داخلي يقبل استقباله؛ القيمة اتجاهية وليست حجزاً للذاكرة ولا أمراً باستخدام الحجم الأقصى.
  • يدخل الحشو ضمن السقف، بينما تبقى حدود رسالة التطبيق وتقسيم النقل وإعادة التجميع منفصلة.
  • تغيّر السجلات الأكبر محاسبة استخدام AEAD، ولذلك يجب إعادة حساب سياسة تحديث المفاتيح.

كل بايت داخل الغلاف محسوب

يحد TLS 1.3 وDTLS 1.3 عادةً النص الصريح الداخلي عند 2^14 + 1 بايت. تقترح مسودّة large_record_size_limit أن يعلن الطرف قيمة بين 64 و2^30 - 256. تنطبق القيمة على النص الصريح الداخلي الكامل، لا على الجزء الذي يسميه التطبيق حمولة مفيدة فقط.

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

القيمة الأقل من 64 أو الأعلى من 2^30 - 256 تؤدي إلى illegal_parameter قاتل. هذا يثبت أن قيمة التفاوض غير صحيحة، ولا يمنح المنفّذ صلاحية تقريبها أو اختراع قيمة بديلة.

الوعد له اتجاه وصاحب

لا تتفاوض الإضافة على رقم مشترك واحد. يعلن العميل ما يستطيع استقباله من الخادم، ويعلن الخادم ما يستطيع استقباله من العميل. يمكن أن تختلف القيمتان.

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

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

السقف ليس طلباً لملئه

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

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

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

المصافحة لا تحجز موارد المنصة

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

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

الحد الأعلى في المسودّة حد نحوي وليس توصية تشغيلية. اختيار الإنتاج يحتاج إلى فئات حمل، وافتراضات تزامن، وسلوك واضح عند الضغط، وقياس للذاكرة والجدولة.

TLS وDTLS لا يغلقان الباب بالطريقة نفسها

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

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

يجب ألا تستخدم المراقبة قاعدة واحدة للبروتوكولين. تسجّل البروتوكول، وepoch، والاتجاه، والطول، والحد، والفعل، والتنبيه إن وجد. غياب التنبيه في DTLS قد يكون النتيجة المطلوبة، بينما يحتاج الغياب نفسه في TLS إلى تحقيق.

السجل ليس رسالة التطبيق

يمكن أن تقلل السجلات الكبيرة تكرار الرؤوس، وقد تتجنب بعض التجزئة العليا في استخدامات DTLS ذات الرسائل الكبيرة. لكن رسالة التطبيق قد تمتد عبر عدة سجلات، وقد يحتوي سجل واحد على بيانات تقسمها الطبقة العليا لاحقاً. ويمكن للنقل أن يقسم السجل نفسه إلى حزم كثيرة.

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

المقامات مهمة: كم اتصالاً أعلن؟ كم سجلاً كبيراً أُرسل؟ كم سجلًا وُثّق؟ كم رسالة اكتملت؟ كم عملية قبلها التطبيق؟ كل نسبة تجيب عن سؤال مختلف.

تقليل الرأس قد يزيد وقت الانتظار

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

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

القرار بين الكفاءة والاستجابة قرار خدمة. السماح بوحدة كبيرة لا يمنع اختيار وحدة صغيرة حين تكون أسرع للمستخدم.

ميزانية التشفير تتبع حجم العمل

تعتمد حدود استخدام AEAD على الخوارزمية وعدد الاستدعاءات وكمية البيانات المحمية. وفي AES-GCM يهم عدد الكتل مباشرةً. توضّح المسودّة أن السجلات الأكبر تتطلب ضبط المحاسبة بعامل مرتبط بـLargeRecordSizeLimit / 2^14، مع حساب كتل أدق حين يلزم.

رفع السقف مع إبقاء حد KeyUpdate القديم المبني على عدد السجلات يغير العمل الذي كان ذلك الحد يمثله. ينبغي تسجيل حزمة التشفير، والاتجاه، وepoch المفتاح، والبايتات أو الكتل المحافظة، وعدد السجلات، وحدث التدوير.

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

الإدخال التدريجي يحافظ على طريق الرجوع

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

يُختبر TLS وDTLS كل على حدة. كما يحتاج الرجوع إلى خطة: خفض القيمة يغير المفاوضات الجديدة لكنه لا يعيد كتابة حالة الاتصالات القائمة. تصريف الاتصالات والتوافق وسياسة المفاتيح وتمييز عدم دعم النظير عن التعطيل المحلي كلها أجزاء من الخطة.

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

المصادر والحدود

تضم الحزمة المجمّدة المراجعة 03 وسجلها الرسمي وتاريخها ومراجعها؛ ومجموعة TLS؛ وTLS 1.3 ومسودّة تحديثه؛ وDTLS 1.3؛ وإضافة حد السجل السابقة؛ وDTLS/SCTP؛ وMLS؛ وQUIC؛ ومتطلبات AEAD؛ وحزم AES-GCM؛ وسجل TLS لدى IANA.

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

المصادر