Resumo

  • Na RFC 3982, private dizia que um conteúdo ausente talvez nunca pudesse ser publicado; denied dizia que a política não o entregava ao nível atual de acesso.
  • Valores presentes podiam carregar specialAccess e doNotRedistribute, preservando a diferença entre receber informação por privilégio e ter permissão para repassá-la.

O incidente não começa com uma invasão. Começa com uma exportação. Um analista autenticado recebe um contato de domínio sob acesso especial. A ferramenta seguinte copia apenas o texto para uma planilha e descarta os atributos. Quando o arquivo chega a um canal mais amplo, ninguém consegue ver que o dado não era ordinariamente público nem que sua redistribuição estava vedada.

RFC 3982 criou um vocabulário para impedir essa perda silenciosa. O registro de situação, a página de errata e o histórico no Datatracker documentam a norma de janeiro de 2005. Ela definiu o tipo de registro de domínios do IRIS, com consultas e resultados estruturados para domínios, hosts, contatos, registradores e autoridades de registro.

A intenção apareceu primeiro nos requisitos. RFC 3707, com seu status, seus errata e o processo IETF, exigia que o protocolo não impedisse níveis granulares de acesso segundo a política de cada operador. Para um valor não entregue, ele deveria admitir omissão sem explicação, autorização insuficiente ou restrição de privacidade independentemente da autorização. Para um valor entregue, deveria admitir as marcas “não redistribuir” e “acesso especial concedido”, inclusive juntas.

O pano de fundo era o WHOIS. RFC 3912, seu status, seus errata e seu histórico descrevem uma requisição textual na porta TCP 43 e uma resposta também textual. O documento reconhece a ausência de segurança forte, controle de acesso, integridade e confidencialidade. Um serviço podia acrescentar avisos humanos, mas o protocolo não oferecia um modelo comum para que programas preservassem o motivo de um campo vazio.

Na seção 3.2.1 da RFC 3982, certos tipos de resultado podiam aparecer com conteúdo ou com conteúdo vazio. Se um elemento relevante estivesse presente sem valor, ele precisava trazer ao menos um de dois atributos booleanos. private indicava que o conteúdo faltava porque talvez nunca pudesse ser publicado. denied indicava que a política não autorizava sua entrega no nível de acesso atual.

Essa diferença orienta a ação. Um dado privado não se torna automaticamente visível quando a credencial melhora. Um dado negado pode ser acessível a outra função autenticada, mas nada no rótulo promete isso. Nenhum dos dois significa que o registro não armazena a informação. E um elemento completamente omitido continua sem explicação padronizada.

Quando o valor vinha na resposta, specialAccess explicava que direitos especiais permitiram a entrega. doNotRedistribute restringia a circulação posterior. O primeiro atributo descrevia a origem do privilégio; o segundo, a responsabilidade do destinatário. A possibilidade de combinar ambos impedia que “posso ver” fosse transformado em “posso publicar”.

O perigo está no caminho seguinte. Conversores frequentemente guardam o valor e removem metadados. Interfaces mostram o contato sem a condição de uso. Caches não distinguem resposta pública de resposta privilegiada. Quando a conta perde acesso, as cópias antigas permanecem disponíveis. A violação nasce de um modelo de dados incompleto, não necessariamente de uma falha criptográfica.

Os rótulos também não eram fiscalização automática. RFC 3981 e seu status colocavam a negação e a verificação prévia de permissões no núcleo IRIS, mas dependiam do transporte para autenticação e privacidade. RFC 3983 e seu status mapearam o serviço para BEEP. Um atributo podia informar que a redistribuição era proibida; não podia criptografar, autenticar, impedir cópias ou, sozinho, definir consequências legais.

O problema reapareceu no RDAP. RFC 9083, com status, errata e Datatracker, define o modelo JSON das respostas. RFC 9537, seu status, seus errata e seu registro IETF acrescentam a extensão para campos redigidos.

A RFC 9537 separa remoção, valor vazio, valor parcial e valor substituído. Pode apontar o campo, o método e uma razão. Rejeita preenchimentos genéricos como XXXX, porque não são sinais consistentes e podem violar o formato esperado. Também reconhece que sinalizar uma redação revela a existência do dado; se essa existência for sensível, o servidor pode omitir o próprio sinal.

As fontes não demonstram uma linhagem direta entre a RFC 3982 e a RFC 9537, e não há motivo para inventá-la. Elas demonstram a persistência da questão. Ausência precisa de proveniência. Divulgação precisa de condições. Se a arquitetura mantém somente texto e vazio, perde as duas coisas.

Para sistemas atuais, a lição é preservar separadamente o valor, a razão da ausência, o contexto de acesso e a autorização de circulação. Uma planilha não deveria transformar acesso especial em publicidade. Um cache não deveria traduzir denied como “não existe”. Uma interface não deveria esconder a restrição justamente quando mostra o valor. A RFC 3982 lembrava que informação útil inclui a história de por que ela chegou àquele destinatário.

Fontes