Resumo

  • A revisão 03 é um Internet-Draft ativo, não um RFC nem evidência de implementação, interoperabilidade ou adoção.
  • Cada ponta anuncia o maior plaintext interno que aceita receber; o valor é direcional e não constitui reserva de memória.
  • TLS encerra diante de um registro excessivo, enquanto DTLS normalmente o descarta sem alerta fatal.
  • Registros maiores mudam a contabilidade de uso do AEAD e não provam menor latência, menos pacotes ou entrega completa.

O transporte define a resposta ao excesso

TLS 1.3 e DTLS 1.3 normalmente limitam o plaintext interno a 2^14 + 1 octetos. O rascunho large_record_size_limit permite anunciar valores entre 64 e 2^30 - 256. A proposta serve aos dois protocolos, mas não apaga suas diferenças.

No TLS, receber um registro acima do limite aplicável exige um record_overflow fatal. A conexão ordenada termina. No DTLS, o registro grande demais SHOULD ser descartado e SHOULD NOT causar alerta fatal. Perda já faz parte do modelo de datagramas, e responder de modo destrutivo a entrada hostil pode oferecer alavanca para negação de serviço.

Logo, um controle único está errado antes de começar. O evento precisa identificar protocolo, época, direção, comprimento observado, limite vigente, autenticação quando conhecida, ação tomada e alerta. Ausência de alerta pode ser conformidade no DTLS e desvio no TLS.

Há um limite para cada direção

A extensão não escolhe um tamanho comum. O cliente anuncia quanto aceita receber do servidor; o servidor anuncia quanto aceita receber do cliente. Os números podem divergir.

Uma ponta pode enviar um registro maior do que o valor que anunciou para sua própria recepção, desde que respeite o limite recebido do par. Um painel que mantém uma única coluna elimina o sujeito da promessa. Pode acusar envio válido ou esconder excesso real sob o número da direção oposta.

Guardar direção significa reter conexão, função da ponta, política local, anúncio enviado, anúncio recebido e tamanho autenticado. Não é detalhe visual. É a relação que determina qual teto governa cada registro.

O anúncio tampouco pede ao emissor que use o máximo. Registros menores continuam legítimos por latência, congestionamento, ritmo da aplicação, memória ou estratégia de lote.

Protocolo permitido não é memória comprometida

Aceitar um grande valor no handshake não cria automaticamente um buffer dedicado por conexão. Uma biblioteca pode usar pools, processamento incremental, cotas globais ou backpressure. Por outro lado, receber um registro máximo isolado não demonstra capacidade para milhares de registros incompletos simultâneos.

O teste deve medir ciphertext pendente, estado AEAD, plaintext retido, padding, remontagem superior, filas e cancelamentos. Em especial, deve simular remetentes lentos que iniciam unidades grandes e ocupam recursos por muito tempo. Concorrência adversarial costuma ser mais relevante que o caso feliz de uma unidade.

O máximo do rascunho é fronteira de sintaxe, não recomendação de produção. Um teto operacional nasce do perfil de carga, do alocador, do escalonador e da política de sobrecarga.

Padding também atravessa o portão

O limite vale para o plaintext interno de TLS 1.3, que inclui tipo de conteúdo e pode incluir padding. Uma carga que caberia sozinha pode exceder quando a política de privacidade adiciona bytes.

Por isso, medir apenas payload visível é insuficiente. O recibo deve trazer o comprimento interno completo, o comprimento cifrado, a versão da política de padding e a direção, sem registrar conteúdo sensível. Aplicação, TLS e plataforma precisam concordar sobre qual unidade está sendo contada.

Valores de extensão abaixo de 64 ou acima de 2^30 - 256 recebem illegal_parameter fatal. Esse resultado prova negociação inválida; não autoriza arredondar silenciosamente nem inventar fallback.

Menos registros não significa menos pacotes

A motivação inclui reduzir cabeçalhos repetidos e, em alguns usos de DTLS com mensagens grandes, evitar fragmentação na camada superior. Isso não transforma registro em pacote de rede nem em mensagem de aplicação.

Um registro TLS grande pode atravessar muitos segmentos. Uma mensagem de aplicação pode ocupar vários registros; um registro pode conter partes que a camada superior separa. Congestionamento, retransmissão e remontagem conservam suas regras.

O funil de evidência deve contar conexões que anunciaram, registros grandes realmente enviados, registros autenticados, mensagens remontadas e operações aceitas. Usar “extensão negociada” como resultado inclui permissões nunca exercidas.

Eficiência e demora podem crescer juntas

Agrupar mais dados sob uma operação de proteção reduz a proporção de cabeçalho. Também pode aumentar o intervalo até que todo o registro chegue e seja autenticado. Em perda, a unidade maior pode ocupar fila por mais tempo ou ampliar o custo de retransmissão.

O rascunho não promete ganho de latência. Operações devem medir tamanho, tempo até autenticação, residência em fila, memória por conexão, unidades parciais concorrentes e conclusão da aplicação. Médias podem esconder piora de cauda em tráfego interativo.

É razoável manter tetos altos e ainda escolher registros pequenos para controle. Bulk, interação e datagramas grandes não precisam compartilhar a mesma política de preenchimento.

O orçamento criptográfico acompanha bytes

Limites de uso de AEAD dependem da construção, do número de invocações e da quantidade protegida. No AES-GCM, blocos importam diretamente. O rascunho ajusta a contabilidade para registros maiores por um fator ligado a LargeRecordSizeLimit / 2^14, com raciocínio específico de blocos quando necessário.

Aumentar o teto mantendo um KeyUpdate antigo, expresso só em registros, altera o consumo que aquele controle representava. A telemetria precisa de suíte, direção, época de chave, bytes ou blocos conservadores, número de registros e evento de rotação.

Isso não declara registros grandes inseguros. Declara que a prova deve usar a envolvente nova. O handshake confirma sintaxe e estado do protocolo, não certifica a política de vida da chave.

Implantar também significa saber recuar

O início prudente usa valores menores que o máximo, escolhidos por classe de serviço. Ensaios cobrem limites assimétricos, remetentes lentos, perda, padding máximo, muitos registros incompletos, pressão de memória e mensagens maiores ou menores que uma unidade.

TLS e DTLS precisam de casos separados. A resposta ao excesso é diferente, assim como o impacto de rollback. Reduzir a configuração altera novas negociações, mas não reescreve o estado de conexões existentes. Drenagem, compatibilidade e política de chave fazem parte do recuo.

O painel final mostra recibos distintos: configuração, anúncio direcional, aceitação, tamanho escolhido, autenticação, recursos, remontagem e resultado. Só assim a economia de envelope permanece uma hipótese mensurável, e não um SLA improvisado.

Fontes e limites

O conjunto congelado contém a revisão 03 e seus registros oficiais, histórico e referências; o grupo TLS; TLS 1.3 e sua revisão em andamento; DTLS 1.3; a extensão anterior de limite; DTLS/SCTP; MLS; QUIC; requisitos AEAD; suítes AES-GCM; e o registro TLS da IANA.

Essas fontes estabelecem texto de protocolo e registro. Não estabelecem implementação, adoção, interoperabilidade, ganho de throughput, economia de memória, menor latência, incidente ou resultado de aplicação. A abertura é um cenário analítico, não um evento observado.

Fontes