Resumo

  • O RFC 3436 pareou fluxos SCTP opostos de mesmo identificador e criou uma conexão TLS independente em cada par; retomar uma sessão reduzia custo, sem eliminar o handshake próprio do fluxo.
  • A proteção exigia entrega ordenada e totalmente confiável e alcançava dados do usuário, não todo o controle SCTP. O RFC 6083 depois levou uma única conexão DTLS à associação.

Uma associação, vários estados

Um socket SCTP podia estar ativo enquanto um fluxo já concluíra handshake completo, outro retomava uma sessão, um terceiro aguardava o primeiro uso e outro carregava SCTP nativo. Fluxos unidirecionais não podiam usar o mapeamento. Portanto, “TLS ativo na associação” não era uma descrição operacional suficiente.

Publicado em dezembro de 2002, o RFC 3436 explicou TLS 1.0 sobre SCTP. O texto, o registro editorial e o Datatracker provam a especificação, não implementação, interoperabilidade ou adoção.

O TLS 1.0 esperava bytes confiáveis em sequência. O SCTP oferecia mensagens, múltiplos fluxos e multihoming. Sem alterar os protocolos, o RFC 3436 colocou um registro TLS em uma mensagem SCTP. O transporte fragmentava e remontava, com suporte mínimo de 18.437 bytes (2^14 + 2048 + 5).

Fluxos de mesmo número em sentidos opostos formavam um canal bidirecional. Cada canal protegido tinha sua conexão e handshake: completo, abreviado por retomada de sessão ou adiado até o uso. Retomada não transformava várias conexões em uma só; cada fluxo precisava ficar pronto por conta própria.

Segurança com renúncias explícitas

Como registros TLS exigiam ordem estrita, entrega desordenada e vida limitada eram proibidas. A confiabilidade parcial do RFC 3758 não cabia nessa sequência. Mais importante, o RFC 4895 registrou que TLS protegia apenas dados do usuário SCTP. Autenticar chunks e controles exigia SCTP-AUTH.

Multihoming também não era identidade. Um registro podia chegar por outro endereço; decisões deveriam usar o peer autenticado, não a IP de transporte.

O RFC 6083 chamou de sérias quatro limitações: sem desordem, sem confiabilidade parcial, mesma quantidade de fluxos nos dois sentidos e uma conexão TLS por par. Seu DTLS usou uma conexão por associação, manteve controle de segurança ordenado no fluxo 0 e liberou os demais para mensagens, desordem e confiabilidade parcial, com autenticação SCTP-AUTH de DATA e FORWARD-TSN quando necessária.

O RFC 8996 depreciou TLS 1.0 e 1.1; a criptografia de 2002 é história, não recomendação atual. As camadas de realidade, a primazia do código em execução e a especificação inicial mínima ajudam, retrospectivamente, a separar norma, handshake, controle autenticado e resultado real.

A afirmação correta era específica: este fluxo concluiu esta conexão para esta identidade e sob estas regras; o controle da associação ainda precisava de prova própria.

Fontes

Outros registros congelados