Resumo

  • A RFC 9668 reduz EDHOC mais a primeira transação OSCORE a no mínimo dois turnos, desde que o fluxo seja direto, o perfil seja compatível e o payload combinado caiba.
  • O operador precisa registrar a decisão de tamanho e fallback, além de distinguir validação de message_3, contexto OSCORE, antirreplay, entrega à aplicação e efeito real.

O dispositivo tinha sido dimensionado para concluir a entrada segura na rede em dois turnos. Em laboratório, com credenciais compactas, funcionava. Em produção, uma cadeia de certificados maior entrou em message_3. Somada ao primeiro comando protegido, ela fez COMB_PAYLOAD ultrapassar o tamanho não fragmentado. O cliente abandonou a tentativa em blocos e voltou ao fluxo sequencial.

Nada estava quebrado. A política de capacidade é que nunca tinha sido observada.

A RFC 9668 explora um ponto específico do EDHOC. Depois de receber e validar message_2, o Initiator já pode derivar o OSCORE Security Context. Em vez de enviar message_3, esperar e só então iniciar a aplicação, ele cria message_3 e a requisição OSCORE ao mesmo tempo. Um único CoAP message carrega os dois. Para rádio restrito, economizar uma troca pode significar menos energia e menor exposição a perda.

O benefício, porém, não é uma constante do protocolo. Ele nasce da combinação de perfil, papéis, credencial, MTU, bloco e payload de aplicação.

O limite de bytes faz parte do contrato de implantação

O cliente concatena a codificação de message_3 com o ciphertext OSCORE. C_R viaja no kid, como Sender ID OSCORE do cliente. A opção EDHOC 21, vazia, sinaliza que o servidor deve separar e processar esses elementos nessa ordem.

message_3 pode carregar uma grande cadeia de certificados em ID_CRED_I ou External Authorization Data em EAD_3. A primeira requisição pode ser dividida com Block-wise. Somente o primeiro bloco interno participa da combinação. Se o conjunto exceder MAX_UNFRAGMENTED_SIZE, a RFC manda interromper aquela transferência por blocos; o cliente pode enviar message_3 separadamente e, depois de concluir EDHOC, transmitir a requisição OSCORE.

Por isso, um KPI chamado “taxa de otimização” precisa de denominador honesto. Dispositivos que recuam por tamanho não podem desaparecer da amostra. Guarde tamanho de message_3, tamanho do ciphertext, bloco, MTU assumido, limite aplicado, perfil de credencial, modo escolhido e duração total. Isso mostra se uma alteração de PKI transformou autonomia de bateria em custo de sinalização.

O fallback também altera timeouts. Um cliente que espera a resposta da transação combinada não pode usar a mesma máquina de estados quando primeiro precisa concluir EDHOC. A observabilidade deve dizer “selecionou sequencial por tamanho”, não “otimização falhou”.

O pacote combinado continua contendo duas autoridades limitadas

A opção 21 não concede acesso. Ela é Critical, Safe-to-Forward, parte da Cache-Key, aparece no máximo uma vez e deve estar vazia. Sua presença ensina o parser; nenhum valor nela é interpretado. O ciphertext OSCORE também não protege message_3. Cada componente preserva seu mecanismo criptográfico.

No servidor, o primeiro gate verifica formato e OSCORE option. Depois o sistema extrai message_3, lê kid como C_R, recupera a sessão e verifica se o application profile permite o caminho. Se message_4 for obrigatório, a combinação deve falhar. Só após validar message_3 o servidor deriva o contexto OSCORE.

Em seguida ele extrai o ciphertext, recompõe a requisição, remove a opção EDHOC, verifica replay e integridade e entrega o plaintext à aplicação. Uma falha de EDHOC impede criar o contexto. Uma falha OSCORE posterior tem tratamento distinto. Confundir ambas como “erro de segurança” atrasa diagnóstico e pode disparar renegociações desnecessárias.

O kid exige recibo de geração. Ele é simultaneamente identificador OSCORE e chave de busca da sessão EDHOC. A especificação impõe regras de não colisão com sessões e contextos existentes. Registrar apenas o valor não basta; é necessário registrar qual sessão, transcript, perfil e geração ele selecionou.

O retorno protegido não é o sensor de fim de curso

Se EDHOC e OSCORE terminam bem, o servidor envia resposta protegida. Sua verificação dá ao cliente evidência de que o Responder calculou material de chave compatível, e OSCORE liga resposta e requisição. Esse é o fechamento da cadeia criptográfica.

A cadeia de negócio pode ser mais longa. Uma resposta pode indicar que o comando entrou na fila; a bomba ainda não girou. Pode indicar que uma configuração foi aceita; o armazenamento ainda não sincronizou. A organização deve definir estados de efeito: entregue, autorizado, aceito, persistido, observado e compensado. A proteção criptográfica preserva a verdade do estado emitido; não o promove ao próximo estado.

Essa separação é especialmente importante no retry. EDHOC bloqueia processamento repetido de message_3 na mesma sessão, e OSCORE verifica replay. A aplicação ainda precisa de idempotency key. Se a ação ocorreu e somente a resposta se perdeu, refazer com nova identidade pode produzir um segundo efeito legítimo para a camada de negócio.

Capacidade anunciada não é recibo de uma execução

Um recurso EDHOC pode anunciar ed-r e ed-comb-req, junto com métodos, suites e tipos de credencial. O anúncio ajuda o cliente a escolher. Ele não prova que a versão ativa do profile continua igual, que message_4 não se tornou obrigatório ou que aquela transação coube no caminho.

Congele a versão de discovery e profile em cada decisão. Relacione-a ao transcript, ao contexto, ao Partial IV, à janela de replay e ao identificador de aplicação. Assim, uma regressão pode ser atribuída a alteração de credencial, rádio, política ou software, em vez de ser mascarada por um único status verde.

A RFC oferece o mínimo compartilhado para interoperabilidade. Ela também preserva uma decisão local legítima: quando o atalho não serve, voltar ao sequencial. A liderança deve tratar essa escolha como política explícita, não como vergonha estatística.

Fontes