Resumo

  • A versão 01 de um Internet-Draft individual propõe negociar SHAKE256 ou TurboSHAKE256 separadamente da suíte TLS 1.3. Ela passa a tratar de DTLS e Exported Authenticators, que a versão 00 excluía.
  • Um autenticador implementado fora da biblioteca TLS tem de receber o identificador do KDF escolhido, ou a informação de que nenhum KDF novo foi negociado, além do protocolo usado. Receber apenas bytes do TLS-Exporter não resolve essa tarefa.

Uma empresa aprova uma atualização da biblioteca TLS porque o handshake com XOF funciona. O aplicativo que faz uma segunda autenticação continua em outro módulo. Se esse módulo recebe apenas material exportado, a aprovação cobriu metade da conversa. A revisão 01 do rascunho XOF põe essa fronteira no texto do protocolo.

A extensão schedule_profile escolhe o KDF sem trocar a suíte criptográfica. Sem a extensão, continua valendo o HKDF ligado ao hash da suíte em TLS 1.3. Com SHAKE256 ou TurboSHAKE256 negociado, o novo KDF faz as derivações e o hash da transcrição. O nome da suíte ainda traz SHA-256 ou SHA-384, embora esse hash já não comande o calendário de chaves. Um painel que lê só a suíte está olhando a placa da máquina, não o que ela está fazendo.

O salto em relação à versão 00 de julho é verificável: ela deixava DTLS 1.3 e Exported Authenticators de fora. A versão de outubro propõe atualizar quatro RFCs e detalha esses caminhos. RFC 9261 permite que uma das partes se autentique após o handshake. Hoje, o hash do autenticador segue a suíte. Na conexão com XOF, a nova seção 14.2 manda usar o TranscriptHash de 64 octetos do KDF selecionado, além das saídas do exportador e do MAC de Finished correspondentes. A conexão que não escolhe o novo KDF segue as regras atuais.

O requisito de integração é explícito. Se o autenticador mora fora da biblioteca TLS, o aplicativo precisa receber o identificador do KDF negociado ou uma indicação clara do caminho padrão. Precisa também distinguir TLS de DTLS, pois este usa outra etiqueta interna no cálculo. A API TLS-Exporter(label, context, length) não comunica nenhuma das duas escolhas. Atualizar apenas a biblioteca pode deixar o aplicativo produzindo um autenticador incompatível.

O vínculo se estende a segredos pré-compartilhados e bilhetes de retomada: a proposta usa os identificadores de KDF já previstos em RFC 9258. A assinatura de certificado é negociada em separado. Assim, um calendário sem SHA-2 ainda pode vir acompanhado de uma cadeia de certificados que o utiliza. O Datatracker classifica o texto como rascunho individual em I-D Exists. Falta no conjunto examinado um teste público de interoperabilidade do autenticador externo; uma verificação de Finished em TLS e DTLS com XOF escolhido mudaria essa avaliação.