De 22 a 25/03/2021

Por Nivaldo Cleto (*)

Na segunda parte de nossa cobertura da ICANN 70, retornamos ao essencial assunto do combate ao Abuso no DNS. Em particular, destacamos a sessão “GNSO-CPH DNS Abuse Work Group Community Outreach”[1], na qual diversas partes com contratos com a ICANN, os registries e registrars, se colocaram disponíveis para um debate maior com a comunidade a respeito de como lidar corretamente com casos nos quais o DNS é utilizado de forma maliciosa.

A sessão foi uma extensão do trabalho já sendo conduzido por um grupo de trabalho que busca melhorar a comunicação com a parte da comunidade sem contratos, em vista de que nos últimos anos esse tema se tornou particularmente sensível. Existe uma percepção por parte significativa da comunidade de que quando uma reclamação de abuso é enviada, mesmo que por meio dos mecanismos adequados, por vezes ela é ignorada.

Já é presente nos contratos firmados com a ICANN que Abuso no DNS se enquadra nas seguintes categorias: malware, botnets, phishing, pharming, spam – todas práticas relacionadas a segurança e que possuem padrões relativamente bem-estabelecidos de operação. Segundo os dados abertos da ICANN sobre atividades maliciosas (DAAR), existem ações sendo tomadas e essas categorias de abuso estão em queda.

A questão, no entanto, é que existe necessidade não apenas de queda, mas sim de uma expressiva e observável redução de práticas predatórias que fazem uso da Internet, de uma maneira observável pela sociedade em geral. Para que isso ocorra, é necessário que o ambiente se torne mais responsivo e abrangente, de forma que mesmo os registros bem-sucedidos de domínios maliciosos não consigam sobreviver por muito tempo. Essa agilidade tem um custo, e é reconhecido esse aspecto. Ações mais firmes requerem mais pessoas qualificadas para que sejam gerados resultados.

Além disso, existem algumas poucas partes com contratos que prestam muito pouca atenção para o assunto, seja por descuido ou malícia, e se tornam verdadeiros imãs para atores maliciosos. Nesses casos, caberia ao setor de Complianceda ICANN tomar atitudes firmes, mas o que normalmente se observa são atitudes altamente cautelosas. Existe um medo legal da ICANN em termos da responsabilidade de encerrar um contrato caso exista qualquer possibilidade da outra parte alegar legitimidade.

Somados, os aspectos de custo e de excesso de cautela da ICANN criam um ambiente no qual não é feito o suficiente, e quem acaba sofrendo são os usuários e as empresas, que são frequentemente vítimas de fraudes. É preciso, portanto, que se estabeleçam caminhos para resolver esse impasse. Nesse aspecto, a participação ativa da comunidade empresarial é essencial para trazer inovação para o espaço.

Recentemente, a Internet & Jurisdiction Policy Network publicou um documento de grande valor para o tema, o “DNS Level Action to Address Abuses Toolkit”[2]. Nele, é descrita uma nova abordagem para o Abuso no DNS, que moderniza o assunto e passa a tratar sobre as ações e reações que ocorrem no nível do DNS, trazendo uma visão mais adequada para a complexidade do tema.

Continuaremos seguindo a questão de perto.

_______________

[1] https://icann.zoom.us/rec/share/hzYVcSot-U5Eqne2PbQx2fuHiIZNixU0MBjc5BA1Fic8l7FSN3ZzJCl1yT3CxWcr.A6dYzbjCQzze4PQz?startTime=1616427025000

[2] https://www.internetjurisdiction.net/domains/toolkit

_______________

(*) Nivaldo Cleto é Conselheiro do Comitê Gestor da Internet no Brasil – CGI.br representante das empresas usuárias da Internet e membro da ICANN Business Constituency

De 22 a 25/03/2021

Por Nivaldo Cleto (*)

Concluímos mais uma reunião regular da ICANN, ainda em formato virtual e seguindo o fuso horário de Cancún, que seria a sede da edição 70 do evento. Nessa reunião foram 4 dias de trabalho em uma agenda bastante compacta, devido a uma série de reuniões complementares nas semanas adjacentes, voltadas a facilitar a coordenação das atividades de formação de políticas da comunidade.

Como de costume, traremos nessa série em duas partes assuntos de maior interesse para a comunidade empresarial, refletindo nossa participação proativa na Business Constituency (BC).

Financiamento e gastos da ICANN

Iniciaremos com um olhar para o sistema de financiamento e gastos da ICANN, visando entender de onde a organização tira seus recursos e como faz uso do montante expressivo do qual dispõe. Acompanhamos uma atualização feita pelo time de Finanças da ICANN, e dessa apresentação extraímos o gráfico abaixo, que descreve como a ICANN obteve seus recursos no ano fiscal passado:

Podemos observar que 97% dos fundos são fruto dos pagamentos regulares realizados pelos operadores de nomes de domínio, que cedem uma parcela do lucro que obtém de seus clientes para a ICANN. A maior contribuição é dos Registries, que são aqueles que efetivamente são donos de uma extensão de domínio (Como é o caso da Public Interest Registry, que administra o “.org”). Ou seja, o sistema se sustenta conforme ocorrem renovações de nomes de domínio existentes e são feitos novos registros.

Nesse sentido, a ICANN possui certa independência, mas ao mesmo tempo é financiada por aqueles que ela tem a missão de regular, o que torna muito necessário que partes externas que representam outros interesses estejam presentes nas decisões tomadas e consigam exercer pressão dentro dos processos de deliberação política, para que seja mantido equilíbrio entre os interesses das partes que possuem contrato com a ICANN e as partes com interesses gerais.

A seguir, temos um gráfico relativo aos gastos da organização:

Algo que logo chama a atenção em relação ao gráfico é que a parte de “Travels & Meetings”, que deveria cobrir as reuniões presenciais regulares da comunidade, agora foi reduzida a 0% devido à sequência de reuniões virtuais, que possuem custos comparativamente bem menores, quase todos absorvidos por uma estrutura já preexistente de presença virtual da ICANN e profissionais qualificados já empregados regularmente pela organização. Se compararmos a anos fiscais anteriores[1], vemos que esse valor flutuava entre 10-15% dos gastos totais.

Uma questão levantada pela comunidade de negócios é o que aconteceu com essa verba. No gráfico, os valores foram simplesmente absorvidos pela categoria “Personnel”, que deveria ser voltada aos contratados da ICANN, mas uma reunião virtual em tese demanda menos contratados, não mais. A presença da equipe da ICANN foi sentida, mas não aparentava ser maior. Portanto, como de fato foi gasto o dinheiro? É uma questão na qual insistiremos com o Financeiro na organização. Esperamos que o relatório final do ano fiscal explique isso adequadamente.

_______________________

[1] https://www.icann.org/en/system/files/files/annual-report-2019-en.pdf

_______________________

(*) Nivaldo Cleto é Conselheiro do Comitê Gestor da Internet no Brasil – CGI.br representante das empresas usuárias da Internet e membro da ICANN Business Constituency

(*) Nivaldo Cleto

Já há alguns anos a ICANN se esforça para se adequar à General Data Protection Regulation (GDPR) da União Europeia, que trouxe uma demanda maior por privacidade de todos aqueles que possuíssem clientes europeus, e uma subsequente necessidade de um maior cuidado com os dados guardados no banco de dados WHOIS, que contém as informações pessoais dos donos de qualquer domínio que faça uso de um TLD genérico (como “exemplo.org”). O conflito dos diferentes interesses faz com que o processo se arraste sem previsão de término, apesar de certo progresso ter acontecido recentemente.

No entanto, a União Europeia possui o objetivo claro de estabelecer maior protagonismo na era da informação do que anteriormente, e já prepara um novo conjunto de leis que também terão alcance transnacional, conhecido como Digital Services Act Package (DSA). Se a lei anterior tratava de privacidade e afetava as empresas de maneira indireta, a nova proposta é especificamente direcionada a regular a atuação dos empreendimentos que façam negócios dentro do bloco.

Dentre as propostas trazidas pelo DSA, muitas que devem se tornar lei em 2 ou 3 anos, existe um tema comum da demanda por uma maior cobrança por transparência nas operações das empresas, particularmente daquelas consideradas como “plataformas”, como é o caso das grandes mídias sociais. Se tornará necessário que essas empresas sejam muito mais claras com as autoridades europeias a respeito de como seus sistemas operam e como decisões são tomadas em relação a conteúdo.

O DNS em si é citado diretamente e existe uma série de provisões associadas ao sistema, algo que chamou a atenção da comunidade ICANN. Diversas questões são abordadas na parte de segurança digital da proposta, e demandam acompanhamento sério e clareza no que significam. O foco está na diretiva conhecida como NIS 2, que se aplica a todos atores da cadeia de resolução do DNS, ou seja, todas as partes contratadas da ICANN.

Algo que é explicitamente articulado é que há uma obrigação da manutenção de um banco com os dados como os do WHOIS, com a diferença de ele ser privado. Além disso, algo vigorosamente debatido nos últimos anos pela comunidade aparece de maneira absoluta na proposta: é necessário que os dados sejam acurados. Ou seja, os registrars ou revendedores possuem sim a obrigação de garantir que os dados que estão no banco de dados são legítimos, algo que mudaria drasticamente a dinâmica de registro de nomes de domínio.

Outro ponto importante é o de que registrars passariam a ser requeridos não apenas acatar notificações de conteúdo indesejado de autoridades nacionais e suas forças policiais, mas também seriam forçados a manter um canal aberto de reclamações para o público geral, o que também modificaria a dinâmica do funcionamento do sistema e abriria muito mais espaço para, por exemplo, ações de ativismo, o que por sua vez necessitaria a contratação de mais funcionários ou terceirizados para lidar com o influxo.

Se a ICANN foi surpreendida com a GDPR, a intenção como DAS parece ser de antecipar ao máximo o possível o que pode vir a acontecer. A comunidade e a organização parecem estar em alinhamento de que é de alta prioridade monitor o desenvolvimento dessas leis, algo que é um sinal positivo.

(*)  Nivaldo Cleto é membro do Comitê Gestor da Internet no Brasil e da ICANN Business Constituency

(*) Nivaldo Cleto

Começamos os trabalhos de 2021 da Business Constituency (BC) com uma ação inovadora para o grupo, que é a de trazer a voz do empresariado de tecnologia envolvido na ICANN para processos externos que tenham impacto direto nos temas sobre os quais deliberamos. Nesse caso, submetemos uma carta para a Mozilla em resposta ao “Mozilla DNS over HTTPS (DoH) and Trusted Recursive Resolver (TRR) Comment”.

Antes de explicar o teor de nossos comentários, é importante lembrar do que se tratam as questões de DoH e TRR. A tecnologia de DNS over HTTPS (DoH) surgiu como uma resposta ao crescente número de incidentes de crime cibernético, e essencialmente faz com que os pedidos enviados por um usuário para o acesso a um nome de domínio qualquer sejam feitos de forma encriptada.

No entanto, o que torna esse padrão particularmente interessante (e potencialmente problemático) é que essa encriptação é feita misturando os pedidos de acesso a nomes de domínio com o tráfego do protocolo HTTPS, que é a forma encriptada de se requisitar informações de um website e, hoje em dia, já se tornou padrão para a maioria dos websites. O resultado disso é que se torna difícil para uma parte externa interceptar ou tentar identificar o que está acontecendo dentro daquela conexão em geral.

Para processar esses pedidos de acesso a nomes de domínios encriptados, é necessário enviá-los para um resolvedor capaz de lidar com a tecnologia DoH, um serviço no momento oferecido por algumas grandes empresas como Cloudflare e Google, além de uma pequena quantidade de grupos de porte menor. Conforme a Mozilla se encaminha para tornar o DoH, o mecanismo padrão em todas as do browser Firefox, ela está desenvolvendo uma lista de Trusted Recursive Resolver (TRR). Essas são entidades que adotam certos compromissos de ética e privacidade descritos aqui.

Em princípio, isso gera um resultado positivo de aumento de privacidade e confiabilidade para o usuário final. Por outro lado, questões importantes tem de ser levantadas. Primeiro, o resolvedor vira um poderoso agregador de dados, que sabe o que o usuário acessa enquanto o próprio provedor de serviços de Internet (ISP) do usuário não sabe. Além dos riscos de tornar alguns algumas gigantes ainda mais fortes, em diversas partes do mundo (o Brasil incluso), o ISP precisa manter os dados de acesso de seus clientes para uso policial. Certos países também fazem a censura de certos websites em nível nacional, algo que é subvertido pelo DoH. Também existem diversos outros temas, como mecanismos de controle parental, que não mencionaremos por questão de brevidade.

Atualmente a lista de Trusted Recursive Resolvers da Mozilla conta com três nomes: Cloudflare, Comcast e NextDNS. Desses, o padrão do browser é utilizar a Cloudflare, com a qual já estão em parceria há diversos anos e que garante que trata com muita seriedade a privacidade do usuário, algo que de modo geral é respaldado pela reputação da empresa. A consulta da Mozilla trata exatamente de entender quais critérios devem ser cobrados de futuros TRRs.

Em nossa opinião, é importante que se olhe para as normas estabelecidas dentro do contexto da ICANN, onde a comunidade global se reúne para estabelecer regras relativas a nomes de domínios. Tendo há muitos anos representado os interesses dos pequenos e médios empreendedores dentro desse espaço, já observamos vitórias e derrotas para o setor, mas a questão é exatamente que existem processos que podem ser acompanhados e influenciados. Um resolvedor operando DoH pode alterar ou desconsiderar decisões tomadas pela comunidade ICANN sem dever maiores explicações para ninguém, algo que vemos como negativo.

Por isso saudamos a iniciativa da Mozilla e trazemos comentários que consideramos importantes para o processo. Segue abaixo a tradução para o português de nossa carta originalmente submetida em inglês, cuja escrita foi liderada pelos empresários brasileiros da BC:

“É um prazer contribuir para esta consulta pública que está sendo realizada pela Mozilla, e gostaríamos de elogiar os esforços da organização para avançar os debates sobre este importante assunto.

A comunidade da ICANN tem se concentrado por mais de duas décadas no desenvolvimento de políticas para o DNS por meio de processos ascendentes baseados em consenso, usando o modelo de múltiplas partes interessadas para alcançar o equilíbrio entre diferentes pontos de vista e chegar a consensos satisfatórios.

Reconhecemos o valor da inovação e do desenvolvimento de novas tecnologias, como DNS over HTTPS (DoH), que têm o potencial de aumentar a privacidade das consultas DNS.

Por outro lado, também vemos alguns de seus aspectos como preocupantes. Em particular, queremos destacar a legitimidade do desenvolvimento de políticas baseadas em consenso em órgãos técnicos e de participação múltipla, como a ICANN.

Estamos de acordo com nossos colegas do Comitê Consultivo At-Large da ICANN (ALAC) que ‘está claro que o DoH pode ter um impacto direto no DNS e no sistema de servidores raiz que a ICANN apoia’.

Na ‘Security/DOH-resolver-policy’ da Mozilla, em ‘Blocking & Modification Prohibitions’, reconhecemos que é afirmado que ‘A parte que opera o resolvedor não deve, por padrão, bloquear ou filtrar domínios, a menos que especificamente exigido por lei na jurisdição em que opera o resolvedor.’

No entanto, isso não contempla totalmente o escopo das decisões meticulosamente tomadas pela comunidade da ICANN. Nós também, por exemplo, supervisionamos a adição de entradas à zona raiz, algo que não é considerado atualmente pelas políticas da Mozilla.

É nossa principal intenção com este comentário destacar a importância do cumprimento das decisões multissetoriais tomadas pela comunidade da ICANN, para que possamos manter uma Internet única e interoperável.

É também digno de nota para vários de nossos membros que essas tecnologias podem impactar significativamente a capacidade dos ISPs de cumprir as obrigações legais e regulamentares de seus governos regionais, sejam elas relacionadas a registro de atividades, proteção de propriedade intelectual, controles dos pais, cibersegurança ou qualquer propósito. Este é um assunto que precisa ser esclarecido no futuro, para evitar consequências não intencionais, como a evasão forçosa ou tentativas de bloqueio do DoH por atores estatais.

Diante de tudo isso, convidamos a Mozilla a considerar a importância de criar mecanismos para garantir que provedores de DoH (ou similares) confiáveis ​​não se desviem do consenso da comunidade global e preservem a obrigação de aderir a essas políticas.

Obrigado pela oportunidade de comentar sobre este assunto.”

(*)  Nivaldo Cleto é membro do Comitê Gestor da Internet no Brasil e da ICANN Business Constituency

Por Nivaldo Cleto*

Nessa terceira edição virtual da ICANN, a comunidade requisitou que a organização e seu Conselho Diretor convocassem uma sessão voltada a discutir o formato e a eficiência dessas reuniões, já que aquilo que inicialmente era pensado como uma solução rápida já se arrasta há um ano, e no pior cenário pode se arrastar por mais outro. A reunião mais recente foi particularmente difícil para o continente Americano em termos de fuso-horário, ainda mais por ter sido decidido de um modo não-transparente que as sessões se espalhariam por cerca de três semanas, ao invés de serem concentradas em apenas uma.

Uma pergunta inicial que podemos nos fazer é qual o propósito das reuniões presenciais da ICANN, e nesse aspecto existem alguns temas que foram citados como tendo mais destaque. É muito mencionado: 1) uma data concreta para a tomada de decisão nos projetos dos grupos de trabalho; 2) oportunidade de conhecer as pessoas que integram esse ambiente de modo mais informal e entender melhor suas motivações; 3) um espaço para fazer negócios, particularmente entre registries e registrars, mas também para a comunidade geral; 4) oportunidade de engajar novos membros e reativar o interesse de membros antigos.

A questão de viajar para um lugar específico não é apenas relacionada a buscar igualdade geográfica ou a criar um incentivo de conhecer um lugar diferente. O propósito real se manifesta de forma bastante clara: é uma maneira eficiente de justificar a ausência por uma semana ou um pouco mais que isso de suas funções diárias, seja no trabalho ou no cuidado da casa, ou qualquer outra função. Estando em casa, se torna mais difícil justificar para os outros e até para a própria pessoa o uso do tempo em um esforço que é largamente voluntário.

A questão do fuso-horário é um ponto particularmente importante, como já citamos. Durante o ano, passamos por 3 fusos diferentes, dois deles que forçaram os participantes das Américas a participarem de reuniões a altas horas da madrugada por diversos dias. Cabe a pergunta que se faz realmente sentido arrastar toda a comunidade para um dado fuso-horário ou se seria melhor organizar as sessões de modo que as sessões funcionassem bem para a maioria dos integrantes de um dado grupo.

A Business Constituency (BC), por exemplo, tem seus membros concentrados entre Américas, Europa e África. É uma pena termos muito poucos membros asiáticos, mas por outro lado, faria muito mais sentido contemplar um horário para as reuniões específicas a nós que favoreça essa faixa geral de fusos.

Outro ponto importante é o do formato adotado pela ICANN, que é o modo webinar do Zoom. Nesse modelo, apenas aqueles explicitamente autorizados a se manifestar podem fazê-lo, uma medida implementada pela organização na esperança de reduzir o número dos chamados “zoombombings”, onde pessoas alheias surpreendem os participantes com algum tipo de engajamento de baixo calão.

No entanto, a consequência disso é que os participantes muitas vezes nem chegam a conseguir saber quem mais está participando da sessão, limitando ainda mais a troca de ideias entre pessoas e aumentando a distância entre membros da comunidade. Essa fragmentação progressiva não ajuda a avançar um trabalho já tão fragilizado pelas dificuldades do ano, que afetaram o progresso de todas iniciativas da comunidade. É necessário balancear qual é a prioridade de um potencial desconforto momentâneo sendo trocado pela possibilidade da comunidade se comunicar em momentos essenciais.

Alguns membros de comitês de liderança da comunidade já falam sobre possíveis “reuniões híbridas”, nas quais existe uma participação presencial combinada com uma forte participação online. Isso traria seu próprio conjunto de problemas e soluções. Fazer com que não existisse um desequilíbrio de poder entre atendentes em pessoa e aqueles que estão presentes de forma virtual seria um grande desafio.

Há também toda a questão de como abordar o tema da vacinação de participantes e como isso se alinharia com eventuais políticas de governos locais. A questão de se a ICANN possui autoridade para cobrar essa vacinação é algo que passará primeiro pela mão de organizações maiores que terão que tomar esse tipo de decisão em 2021, e orientarão a atuação das outras em termos de medidas de profilaxia cabíveis.

A próxima reunião, que seria em Cancún, já está praticamente cancelada em sua forma presencial. A reunião que se daria na metade de 2021 também parece estar em questionamento, com a comunidade potencialmente só se reencontrando em mais um ano. Se medidas eficientes não forem decididas e implementadas o mais rápido possível, veremos a degradação desse projeto para o qual contribuímos com tanta intensidade e paixão por tanto tempo. É uma excelente hora de a comunidade se unir e refletir sobre qual o melhor caminho para sua continuidade.

Independentemente do que aconteça, seguiremos acompanhando a ICANN e trazendo as discussões de destaque que se passam dentro desse espaço.

*Nivaldo Cleto é membro da ICANN Business Constituency e Conselheiro Eleito do Comitê Gestor da Internet no Brasil – CGIbr

• • Parte 1

  • Parte 2

Por Nivaldo Cleto*

A ICANN 69, que deveria ter sido sediada na cidade de Hamburgo, está ocorrendo de modo virtual durante a maior parte do mês de outubro, em blocos de dias com carga horária reduzida. Para nós da América Latina é a segunda reunião em sequência com fuso horário desfavorável. A ICANN 68 ocorreu no horário da Malásia, invertido em relação ao nosso, e durante a edição atual muitas reuniões tem começado às 4 da manhã. De qualquer maneira, seguimos comprometidos a trazer informações de relevância para a comunidade empresarial.

TLDs de uso privado

Um tema que está aparecendo com certo destaque durante esta reunião é referente ao conteúdo do documento “SAC113: SSAC Advisory on Private-Use TLDs”, que descreve os impactos do uso de TLDs (Lista de domínios da Internet de nível superior)  privados no DNS (Domain Name System, ou sistema de nomes de domínios). Esses TLDs não são nada mais do que sufixos de nomes de domínio que não são oficialmente parte da raiz do DNS, sendo diferentes de um sufixo como o “.br”, que é acessível por toda a Internet. Pelo contrário, os TLDs privados servem a um proposito limitado de comunicação por parte de empresas específicas.

Para exemplificar melhor, podemos citar que essa técnica é utilizada por empresas como Belkin, Consul, DLink, entre outras, para fazer a transmissão de dados entre seus próprios equipamentos instalados na casa de um usuário. Sua geladeira pode, por exemplo, estar usando o sufixo “.consul” para se comunicar internamente, mesmo esse não sendo um nome aprovado para uso pela comunidade da ICANN.

Isso não necessariamente seria um problema se essas comunicações permanecessem locais, mas tem ocorrido de diversos desses requerimentos de comunicação chegarem aos servidores raiz do DNS, causando um tráfego desnecessário e que, mais ainda, pode dificultar com que no futuro esses sufixos privados sejam utilizados na Internet geral, pois já haveria um precedente de uso estabelecido.

O DNS não possui provisões para lidar corretamente com esse tipo de requerimento e a recomendação oficial relativa a isso é de que os diversos fabricantes de eletrônicos façam uso de nomes dos quais já são donos para fazer mesmo essas comunicações internas. Seria o caso do uso de algo como “intranet.empresa.com.br”. Isso manteria a consistência da identidade da empresa mesmo no caso de o tráfego acabar chegando ao DNS.

Um gráfico muito relevante trazido pelo documento demonstra o volume de requerimentos atrelados a TLDs de uso privado que chega a um dos servidores raiz (Servidor L) da Internet por segundo ao longo de um único dia:

Temos um sufixo como o “.lan”, utilizado pelo OpenWrt, um sistema operacional baseado em Linux utilizado em equipamentos, que faz 165 milhões de requerimentos desnecessários por dia, o que além de causar uma carga desnecessária nos servidores, também abre caminho para certos tipos de problemas de segurança.

A recomendação do grupo de segurança da ICANN é de que seja estabelecido um único TLD privado para uso geral, que concentre esse tipo de requerimento de maneira única e, portanto, foque os potenciais problemas em um caminho apenas. Isso dependeria de um alinhamento com a indústria em geral, e ainda precisa ser discutido com o Conselho Diretor da ICANN para que uma decisão seja tomada em cima da recomendação. Caso sinalizem que esse é o caminho, nós da Business Constituency (BC) sempre agiremos em favor de tornar a questão o mais simples possível para o empresariado.

*Nivaldo Cleto é membro da ICANN Business Constituency e Conselheiro Eleito do Comitê Gestor da Internet no Brasil – CGIbr

Por Nivaldo Cleto*

No quarto e último dia da ICANN 68, segunda edição virtual do evento, a discussão principal foi a respeito do futuro dos modelos de formação de políticas globais relativas aos nomes e números da Internet frente à atual situação de pandemia. A ICANN sempre contou com um equilíbrio no qual o grosso do trabalho é feito de modo virtual dentro dos diferentes grupos de trabalho, e periodicamente a comunidade se congrega em reuniões presenciais para que possam socializar, avançar projetos e, principalmente, fazer as importantes reuniões face a face nas quais muitos pontos contenciosos acabam sendo acertados.

Com a certeza agora de que a reunião 69 será online (e uma probabilidade alta da edição 70 também ser), a comunidade se encontra com o dever de pensar quais são as maneiras mais eficientes de seguir com os trabalhos, já que esses não podem esperar por uma normalização global. Uma reunião normal da ICANN mobiliza literalmente milhares de pessoas dos mais variados pontos do mundo para uma única localização, tornando muito difícil a retomada desse modelo, já que agora cada país possui um protocolo próprio e contam com listas variadas de quais estrangeiros são permitidos ou não de ingressar em seu território.

Não foi possível evitar comentários sobre o evento de “Zoom Bombing” no primeiro dia da reunião, no qual uma pessoa de fora da comunidade entrou em uma sessão aberta a todos, com centenas de participantes, e tomou o canal de áudio para fazer declarações racistas e desorganizar o fluxo dos trabalhos[1]. Depois desse episódio, a ICANN defensivamente passou todas as sessões para um modo de webinar, que restringiu muito as interações da comunidade. É questionável se essa era uma solução melhor do que enviar senhas para aqueles que estavam propriamente registrados na reunião, pois isso tornou ainda mais difícil a interação e identificação entre os membros da comunidade.

Muito foi falado a respeito de quais são as alternativas existentes, e muitos membros da comunidade demonstraram empolgação por alternativas de realidade virtual que simulam espaços de conferência e similares, enquanto outros expressaram apenas que gostariam de uma melhor administração da plataforma Zoom, que já é utilizada nos trabalhos rotineiros da comunidade, sendo melhor adaptada para uma reunião da escala e necessidade de participação como a ICANN. A ideia de que não fazer reuniões presenciais da instituição diminuiria nosso impacto em termos de geração de carbono foi muito repetida por alguns membros da comunidade.

O CEO, Göran Marby, aproveitou a sessão para enfatizar o estabelecimento do DNS Security Facilitation Initiative Technical Study Group[2], focado em encontrar soluções e fazer recomendações proativas a respeito de como aumentar a segurança do DNS. A formação dessa força-tarefa vem em grande parte em resposta ao ataque de DNS hijacking comandado pelo grupo Sea Turtle[3], que resumidamente obteve controle dos códigos de países de diversos territórios, principalmente asiáticos, e dessa forma conseguiram monitorar todo o tráfego que passava por qualquer website dentro daquele TLD. O “.am”, da Armênia, foi o único a se identificar publicamente como uma das vítimas.

Mark Datysgeld, parceiro da AR-TARC e recém-apontado Conselheiro do GNSO (Generic Names Supporting Organization), comentou sobre a importância de a ICANN ter investido mais atenção em maneiras para os membros da comunidade interagirem entre sessões, o que ocorreu em salas virtuais temáticas de coffee break, nas quais participantes aleatórios da reunião se juntaram para discutir temas como quais estão sendo seus hobbies durante a pandemia e quais séries estão assistindo. Essa interação orgânica é o que permite que a comunidade se veja menos como adversários e mais como pessoas tentando fazer um trabalho.

Katrina Sataki, chair do Conselho do ccNSO (Country Code Names Supporting Organization), mencionou que o ccNSO já tinha mudado antes da pandemia para uma estratégia de trabalhar mais pesadamente com webinars para alcançar seus membros, pois não são todos administradores de códigos de países que possuem a oportunidade de dedicar o tempo e dinheiro necessário para enviar representantes para uma reunião da ICANN. Sataki enfatizou a importância de usar essas oportunidades para tornar esse espaço e conhecimento mais acessível ao invés de menos.

Keith Drazek, chair do GNSO, enfatizou que os três processos de desenvolvimentos de políticas nos quais o GNSO está engajado ainda continuam planejados para uma entrega em 2020, e congratulou todos os envolvidos por não terem reduzido seu comprometimento durante o período de pandemia, de modo que será possível avançar novos temas na pauta em um futuro próximo. Notou que os esforços redobrados em não gerar duplicação de trabalhos que foram muito cobrados em 2019 estão sendo observados e produzindo bons resultados. Drazek retomou o tema da importância do engajamento face a face para que decisões possam ser tomadas pela comunidade.

Manal Ismail, chair do Governmental Advisory Committee (GAC), apontou como a maior dificuldade do grupo a escrita do communiqué, um documento que contem o resumo das recomendações dos governos à ICANN redigido ao fim de cada reunião. O ambiente virtual dificultou em muito a capacidade dos representantes formarem coalizões, procurarem entendimento, e de modo geral congregarem em torno de objetivos específicos. Também mencionou os problemas enfrentados por governos de países com infraestrutura tecnológica, mas limitada em sua participação efetiva.

Os membros brasileiros da Business Constituency (BC) participam ativamente das discussões sobre como otimizar a estrutura da ICANN e como tornar as interações dessa comunidade tão diversa mais fáceis. Estamos já escalados para contribuir com o próximo comentário dessa natureza, que se inicia no próximo mês[4]. Seguimos representando o interesse do pequeno e médio empresário latino dentro deste espaço.

[1] https://www.icann.org/news/blog/important-update-icann68-to-be-held-as-zoom-webinars

[2] https://www.icann.org/news/blog/introducing-the-dns-security-facilitation-initiative-technical-study-group

[3] https://www.wired.com/story/sea-turtle-dns-hijacking/

[4] https://www.icann.org/public-comments/multistakeholder-model-next-steps-2020-06-04-en

*Nivaldo Cleto é membro da ICANN Business Constituency e Conselheiro Eleito do Comitê Gestor da Internet no Brasil – CGIbr

Por Nivaldo Cleto*

Durante o terceiro dia da ICANN 68, segunda edição totalmente virtual do evento, contamos com uma série de reuniões mais técnicas com foco no alinhamento de políticas entre os diferentes atores que compõe o ecossistema da comunidade e o Conselho do Generic Names Supporting Organization (GNSO). Nesse sentido, faremos uma postagem mais técnica hoje, destinada apenas à comunidade especializada. No diário do dia 4 voltaremos a incorporar temas mais abrangentes, de interesse geral.

Sobre a questão dos Internationalized Domain Name (IDNs), foi feita uma decisão pelo Conselho Diretor durante a reunião 64 de Kobe que apontou para a necessidade de coordenar melhor sua implementação em ccTLDs para garantir consistência e segurança. Já são 62 nomes em formato IDN em 43 países, como podemos observar abaixo:

Para garantir a integridade do DNS e impedir casos de confusão e similaridade, o ccNSO está iniciando um grupo de trabalho que irá incorporar membros do GNSO e potencialmente do SSAC, mas sem criar um Cross Community Working Group (CCWG), pois esses não são capazes de gerar políticas, apenas recomendações.

Já sobre o processo de evolução do modelo multistakeholder, que dentro da Business Constituency (BC) foi liderado por seus membros brasileiros, as atualizações são complexas, pois as resoluções foram pensadas dentro de um contexto e a realidade se provou totalmente diferente frente à pandemia global que encaramos. O conselho diretor afirmou estar olhando para o processo de uma maneira mais direcionada, tentando compreender com ajuda dos comentários da comunidade qual é a maneira mais eficiente de usar os recursos disponíveis.

O desafio de como incluir de maneira mais eficiente as pessoas nos processos da ICANN, delineado de modo muito claro pelos comentários de reforma do modelo, é colocado ainda mais em xeque, face ao fato de que temos de levar o fator da distância em conta e as dificuldades de guiar futuros colaboradores para os caminhos corretos, de forma que se tornem membros produtivos do processo.

Foi levantado entre alguns membros do conselho que existe uma dualidade entre investirmos esforços em melhorar os processos que já existem versus fazer políticas novas, pois o tempo dos colaboradores não é ilimitado. Chegou a ser comentado que o próprio processo da transição das funções IANA não está totalmente encerrado e ainda necessita de medidas para poder ser considerado como firme.

O tema transversal do Abuso no DNS também foi levantado, como não poderia deixar de ser. Existe uma questão séria que o Conselho do GNSO quer que os membros do Conselho Diretor responda, que é qual a definição formal de Abuso no DNS para eles, e se o setor de Compliance da ICANN sente necessidade de apoio no sentido da criação de novas ou melhoradas ferramentas para lidar com essa questão.

Foi reconhecido que as partes contratadas com a ICANN têm, de modo geral, feito esforços sinceros para melhorar nesse quesito desde 2019. No entanto, como já mencionamos em um diário anterior, o caráter voluntário dos acordos que combatem o abuso torna sua eficiência limitada. Cabe agora em discussões subsequentes do Conselho Diretor ser decidido se o mais correto é o início de um processo de estabelecimento de políticas ou uma série de reformas contratuais.

A preocupação que parece imperar entre diversos conselheiros é a diferenciação entre o que é Abuso no DNS e o que é cibercrime, e em qual ponto essas duas variáveis se encontram e criam situações nas quais é útil a intervenção de direta da ICANN e seus parceiros. A remoção de um domínio do DNS é uma atitude forte e difícil de reverter, que deve ser vista como uma solução final.

Nós da comunidade de negócios acreditamos que não existe espaço para subjetividades dentro desse tema, e lutamos dentro da Business Constituency (BC) por normas rígidas que impeçam que atores maliciosos causem danos que afetam, principalmente, as pequenas e médias empresas globais que não possuem recursos para lutar complexas batalhas legais quando veem seus nomes, marcas e produtos sendo utilizados de modo ilícito na rede.

*Nivaldo Cleto é membro da ICANN Business Constituency e Conselheiro Eleito do Comitê Gestor da Internet no Brasil – CGIbr

Por Nivaldo Cleto*

O segundo dia da ICANN 68, segunda edição totalmente virtual do evento, foi marcado principalmente pela discussão a respeito de como a Internet das Coisas (IoT) pode afetar o Sistema de Nomes de Domínio (DNS) e a situação da conectividade e segurança global, em vista de que a tecnologia está trazendo mudanças significativas para a maneira como pensamos na estrutura da rede.

Os aparelhos IoT possuem algumas diferenças significativas em relação a muitos dos aparelhos aos quais estamos acostumados, se destacando: 1) seus sensores operam de maneira contínua e sem intervenção, ou por vezes conhecimento, do usuário; 2) não existe um administrador da estrutura, pois são autônomos; 3) são muito mais heterogêneos do que computadores padrão, fazendo uso dos mais variados componentes de hardware, sistemas operacionais, e inclusive modos de conexão à rede que não são o Wi-Fi (como THREAD, WiSUN, BLE, e Zigbee).

O documento mais expressivo lançado a respeito do tema até o momento é o SAC105[1], produzido por especialistas do âmbito da ICANN. Nele são descritas as possíveis interações entre aparelhos IoT e o DNS, apontando para pontos importantes de serem discutidos e coordenados. Um ponto fundamental é por qual razão optar por um endereço no DNS ao invés de um endereço IP: um endereço IP, pelos mais variados motivos, pode acabar mudando de maneira relativamente rápida por questões técnicas ou de conveniência, enquanto um endereço no DNS pode ser utilizado para direcionar a IPs diferentes sempre que esses mudam, sem necessitar de uma atualização direta do aparelho.

A análise dos autores do SAC105 é separada em pontos positivos e desafios de integração.

Dentro dos pontos positivos, o uso do DNS pode oferecer segurança elevada em relação ao uso de uma conexão IP genérica. As tecnologias emergentes de encriptação DoH e DoT são capazes de mascarar o tipo de pedido que é feito dentro de uma conexão, e ocultariam alguns sinais importantes que dão dicas a atores maliciosos de que tipo de aparelho está operando dentro de uma rede, o que facilita a exploração de vulnerabilidades, além de comprometer a privacidade da pessoa. Além disso, com o uso da técnica de validação de endereços DNSSEC, se torna possível impedir que atores maliciosos tentem mudar a rota dos pedidos de um aparelho para poder executar comandos arbitrários nele.

Dentro dos desafios desse relacionamento, é sempre importante recordarmos de quando, no ano de 2016, a provedora de DNS Dyn sofreu um ataque massivo de negação de serviço originário de uma botnet formado de aparelhos IoT, que teve tamanha intensidade que chegou a derrubar os serviços da Amazon, entre outros. Conforme olhamos para a proliferação de aparelhos IoT sem padrões mínimos de segurança (senhas padrão, ausência de encriptação, entre outros), consideramos ainda o fato de que esses são geralmente construídos com limitações muito estritas de memória (como ocorria nos primórdios da computação em geral), e a sugestão da incorporação de qualquer tecnologia não essencial ao funcionamento do produto é vista com maus olhos por muitos fabricantes, pois isso aumenta seu custo de produção.

A consolidação da tecnologia 5G é considerada como o próximo grande passo nessa evolução do conceito de IoT, provendo uma rede estável e rápida o suficiente para que esses produtos se tornem viáveis em escala nos grandes centros urbanos, o que iniciaria um novo momento de fato nas tecnologias de telecomunicação. Com a expansão tímida porem constate dessa tecnologia, se mostra essencial que discussões sobre o tema comecem a tomar maior espaço dentro da pauta de políticas digitais.

Se o aparelho é inteligente, ele é vulnerável. Essa é uma máxima que tem de ser confrontada por toda a indústria e pelos usuários, pois ela é real. No momento que se faz a integração de um aparelho à rede, todos os problemas que já enfrentamos com nosso computadores e celulares passam a ser possíveis nesse novo aparelho. Essa questão é ainda mais frágil devido ao fato de que muitos desses aparelhos são manufaturados ou tem suas peças fabricadas por empresas sem conhecimento profundo das tecnologias envolvidas, que não tomam precauções básicas como assinalar senhas aleatórias ao produto antes de sair da fábricas pois isso custaria uma fração de centavos a mais por unidade. Sem o incentivo de regulações ou pressão da indústria, esses comportamentos não mudarão.

Do ponto de vista da comunidade de formação de políticas, precisamos começar a tratar de assuntos sérios que ainda não são abordados. Se por um lado já começamos a pensar em aspectos de segurança de infraestrutura em resposta ao ataque contra a Dyn, por outro lado ainda não estamos fazendo considerações sobre outras questões de segurança, como por exemplo quais as políticas devem incidir sobre os nomes de domínio utilizados por aparelhos IoT.

Considerando que a vida útil de operação de muitos desses aparelhos é pensada para chegar a décadas, o que acontece uma vez que a empresa vá a falência ou simplesmente descontinue de modo irresponsável uma linha de produtos? Aquele nome de domínio pode ser apropriado por um ator malicioso e então usado para gerar todo tipo de reação nas máquinas que dependem de comunicação com aquele endereço.

Duas soluções mais imediatas podem ser consideradas pela comunidade ICANN: 1) a adoção de um TLD específico sob o qual residiriam todos os endereços destinados a IoT, de tal forma que teríamos a capacidade de, enquanto comunidade, monitorar conforme estes são ativados, desativados, e trocam de mãos; 2) um cadastro dos endereços utilizados por esses aparelhos que faça com que uma proteção especial incida sobre eles, e que o registrar não possa simplesmente vende-lo para outrem assim que o contrato com o comprador anterior expira.

Seguiremos acompanhando o tema e ajudando no desenvolvimento de soluções que beneficiem o empresariado latino.

[1] https://www.icann.org/en/system/files/files/sac-105-en.pdf

*Nivaldo Cleto é membro da ICANN Business Constituency e Conselheiro Eleito do Comitê Gestor da Internet no Brasil – CGIbr