Кратко

  • RFC 3436 объединял встречные потоки SCTP с одинаковым идентификатором и создавал отдельное TLS-соединение на каждой паре; возобновление сессии экономило ресурсы, но не заменяло рукопожатие данного соединения.
  • Защищённый поток должен был доставлять данные строго по порядку и без отказа от просроченных записей. TLS защищал пользовательские данные, а не всё управление SCTP; RFC 6083 позднее перенёс границу на одно DTLS-соединение ассоциации.

Одна ассоциация не означала одно состояние

Поток 0 мог завершить полное рукопожатие, поток 1 — возобновлять сессию, поток 2 — ждать первого использования, а поток 3 — переносить обычные данные SCTP. Однонаправленные потоки в эту схему TLS не входили. Поэтому общий индикатор «TLS включён» скрывал важные различия.

RFC 3436 вышел в декабре 2002 года. Его текст, карточка RFC Editor и досье IETF подтверждают спецификацию, но не реализацию, совместимость или внедрение.

TLS 1.0 ожидал надёжный упорядоченный поток байтов. SCTP предлагал сообщения, множество потоков и multihoming. RFC 3436 не менял протоколы: одна запись TLS становилась одним пользовательским сообщением SCTP. SCTP выполнял фрагментацию и сборку; требовалось не менее 18 437 байт (2^14 + 2048 + 5).

Потоки с одинаковыми номерами в двух направлениях образовывали двунаправленную пару. Каждая защищённая пара получала своё соединение и рукопожатие: полное, сокращённое с возобновлением сессии или отложенное до первого использования. Общая сессия не делала соединения общими — каждый поток завершал собственный обмен.

Что защита исключала

TLS требовал строгой последовательности, поэтому запрещались неупорядоченная доставка и ограниченный срок жизни записи. Частичная надёжность RFC 3758 не помещалась в такую последовательность.

RFC 4895 обозначил более глубокую границу: TLS из RFC 3436 защищал только пользовательские данные SCTP, но не все chunks. Для транспортного управления понадобился SCTP-AUTH. Шифрование содержимого, личность TLS-пира и подлинность DATA либо управляющего chunk — разные доказательства.

Multihoming также не был личностью. Запись могла прийти с другого IP; решение следовало связывать с аутентифицированным пиром, а не транспортным адресом.

RFC 6083 назвал четыре серьёзных ограничения: отсутствие неупорядоченной доставки, частичной надёжности, поддержка лишь одинакового числа потоков в обоих направлениях и отдельное TLS-соединение на каждую пару. DTLS использовал одно соединение внутри ассоциации, отправлял управление безопасностью по надёжному упорядоченному потоку 0, а приложениям возвращал много потоков, границы сообщений и частичную надёжность. Нужные DATA и FORWARD-TSN защищались SCTP-AUTH.

RFC 8996 позднее вывел TLS 1.0 и 1.1 из употребления. Криптография 2002 года — история, не нынешняя рекомендация. Идеи Heng Lu о слоях реальности, приоритете работающего кода и минимальной начальной спецификации помогают ретроспективно разделить стандарт, рукопожатие, управление и наблюдаемый результат.

Точная формула звучала так: этот поток завершил это соединение для этой личности по этим правилам; управление ассоциацией всё ещё требовало отдельного доказательства.

Источники

Дополнительные зафиксированные источники