O Encontro mundial da internet continua. Confira o relato de Mario Teza sobre a reunião mundial da ICANN. Neste relato ele destaca as novas implementações que o grupo de segurança propõe para ajudar a combater as fraudes, ataques e spams.

* John Klensin:

Na foto John Klensin, um dos pioneiros da internet presentes no evento.

"" Quais as características da internet brasileira hoje?

Castells – É a sociedade mais desigual do mundo. O Brasil é um país extraordinário; sempre se fala na sua grande potencialidade, mas que nunca acontece. A internet no Brasil se divide em duas partes, em ser e não ser. Há uma comunidade pequena de 8% de internautas concentrada em Ipanema e nos Jardins, em São Paulo, culturalmente inovadora e abastada em software livre. O Brasil, em termos de criatividade no setor da comunidade de internautas, é semelhante à Califórnia.

Em princípio, parece que grande parte da população brasileira está excluída da internet, mas não está. Há núcleos muito ativos, pobres por um lado, em nível social, mas educados, que tem uma grande atividade na internet e, sobretudo, há um enorme potencial. O importante é que haja uma política de uso inteligente de internet com linhas de banda larga, conexão de baixo custo, conexão na escola, liberdade de no trabalho as pessoas acessarem os seus correios eletrônicos. Nesse sentido, tenho esperança de que este governo atual entenda que a internet é tão importante hoje em dia como alfabetizar tradicionalmente a população do país. (1)

Nesta terça-feira, 05/04 foi um dia puxado. Começei assistindo o whorkshop sobre DNSSec. Foi uma sessão pública com todo o time de segurança da ICANN, com direito a Stephen Crocker no debate. A atividade foi coordenada por Frederico Neves, da equipe do RegistroBR?/Comitê Gestor do Brasil. Grande atiividade com direiito a sessão hacker, demonstração de ataques, etc. A principal vantagens para as pessoas quando osprovedores adotarem o DNSSec, será a garantia de que o site que ela quer visitar realmente é aquele que ela digitou. Isso vai coibir os sites clonados de bancos, por exemplo. O detalhe interessante é que a última RFC saíu na semana passada. Está fou a primeira demonstração pública da nova implementação. O tema é antigo, novo é o este realese do DNSSec.

No final deste relato, detalho tecnicamente o assunto. Maiores informações sobre o whorshop ver no site http://dnssec-deployment.org

A tarde tivemos o whorkshop sobre a Cúpula da Sociedade da Informação (WSIS) que vai ocorrer em Tunis em janeiro de 2006. Tivemos a presença de embaixadores/a, representantes da ONU e dos grupos internos da ICANN. Ao final dos debates, fiquei com a sensação de que nem a ONU, não sabe oque fazer com a " governança da internet". Por outro lado, me pareceu que as pessoas que atuam na ICANN não estão percebendo o enorme perigo para a democracia na internet as decisões que podem ser tomadas em Tunis. Debutei na plenária da ICANN. Basicamente coloquei que não acredito na democracia da ONU. Que prefiro aprofundar a democracia na ICANN a entregar a "governaça da internet" para quem não ouve a sociedade civil. Afinal,quem elegeu a ONU? Sei que a questão é polêmica e não terei tempo de desenvolve-la aqui. Estou preparando um texto sobre o tema. Durante todo o debate, muitas pessoas falaram sobre o problema da exclusão digital. Uma mesa latino-americana tratou disso na primeira parte do debate.

A última sessão do dia foi a apresentação e o debate sobre o plano estratégico e orçamento da ICANN. Segundo Harmut Glaser, que participou de todas as reuniões mundiais da ICANN, foi a primeira vez que isso acontece. Houve um longo processo de debate e participação que culminou com o de da tarde. na quinta-feira a Diretoria da ICANN vai bater o martelo sobre o assunto. (3)

Encerramos a noite com um churrasco argentino. Para o padrão do Rio Grande do Sul, falta o sal grosso. Mas para a saúde, com certeza é melhor. Comum entre os dois o excesso de gordura. Um veneno para o meu colesterol.

A delegação brasileira garantiu a descontração numa mesa. Recebemos a visita do Vinton Cert quando ele relembrava a reunião mundial que ocorreu no Rio de Janeiro. Os estrangeiros ficaram impressionados com a roda de capaoeira, Cerf foi quem puxou o "trenzinho" durante uma apresentação de um grupo de Chorinho. Quando entrou na churrascaria uma Escola de samba, eles foram a loucura. Até os chineses dançavam enloquecidamente. Segundo Cerf, ele percebe uma enorme diferença entre os eventos realizados no Norte e entre os Latinos. Entre nós tem uma alegria contagiante.

Dedico esta coluna aos/as meus colegas da DATAPREV, que em condições muito dificeis, mantém de pé os sistemas e a rede da Previdência Social do Brasil. Participando de eventos como este, vejo a enorme diferença de infra-estrutura e dinheiro entre o Brasil e o dito "primeiro" Mundo. Mesmo sem dinheiro, fazemos milagres. No caso da DATAPREV, está semana ela concluiu a primeira parte da instalação de um software livre para inventario de hardware e software nos Ministérios do Planejamento, Cidades, Relações Exteriores, Desenvolvimento Social, Advocacia Geral da União (AGU) e Agência Nacional dos Transportes Terrestres (ANTT). Já são 2.000 estações instadas. (4)

***************************

Sobre DNSSec

As extensões propostas fornecem 3 serviços distintos: distribuição de chaves, certificação da origem dos dados e certificação da transação e requisição. Seguindo a filosofia original do DNS, os dados são de domínio público e não existe diferenciação dos clientes, isto é, todos recebem a mesma resposta (pelo menos no protocolo, o próprio BIND fornece maneiras de proteger os dados). As extensões não pretendem incluir nenhum tipo de lista de acesso ou outros meios de diferenciar os resolvedores de nomes.

As extensões introduzirão 3 novos RRs: KEY, SIG e NXT. A RFC 2065 detalha o formato destes RRs. Neste artigo, elas serão citadas no seu uso, para maiores detalhes os leitores são convidados a ler a RFC.

DISTRIBUIÇÃO DE CHAVES

Um RR chamado KEY foi especificado de forma a permitir ao DNS a distribuição de chaves públicas de criptografia. Este RR inclui campos com um identificador de algoritmo, parâmetros necessários ao uso da chave pública, além de uma série de indicadores, tais como o tipo da entidade associada à chave ou a ausência de associção da chave com entidades.

RRs KEY serão anexados à seção de dados adicionais, automaticamente, pelos servidores de nomes seguros, sempre que possível.

CERTIFICAÇÃO DA ORIGEM E DA INTEGRIDADE DOS DADOS

A certificação será obtida por assinatura criptográfica associadas aos RRs. Cada RR de uma zona terá associado um RR SIG. Geralmente, haverá uma única chave privada que assinará por toda uma zona. Se um resolvedor seguro aprender de modo confiável a chave pública da zona, ele poderá verificar se os dados assinados são certificados e razoavelmente atuais.

Esta chave de certificação da origem dos dados pertence à zona e não aos servidores que armazenam cópias dos dados. Isto significa que o comprometimento de um servidor, ou até mesmo de todos os servidores de uma zona, não necessariamente afeta o grau de garantia que um resolvedor tem de que ele pode determinar se o dado é legítimo.

A transmissão de RR SIGs assinando os RR das respostas não resolve, entretanto, o problema das respostas negativas, isto é, a resposta dada por um servidor quando um nome não existe, ou o tipo procurado não existe. Isto é resolvido com a introdução do RR NXT (non-existent). Este RR carrega a informação de que o nome procurado não existe, o nome mais próximo imediatamente anterior (talvez o próprio) e os tipos (A, MX, LOC, ...) a ele associados. Como os outros RRs, o RR NXT será assinado e terá um RR SIG associado. Estes RRs (NXT e SIG) deverão ser gerados a partir dos arquivos de zonas utilizados no DNS atual, usando uma chave privada guardada no servidor de nomes primário (master). Eles não são gerados dinamicamente. Portanto, não significam um acréscimo significativo de processamento para o servidor de nomes.

Existem dois casos em que um RR SIG não é assinado pela chave privada da zona. O primeiro caso dá suporte à atualização dinâmica quando algumas estações têm permissão para atualizar dinamicamente (DNS dinâmico) dados de uma zona. A estação fica, então, responsável também pela assinatura dos RRs modificados. A chave pública desta estação estará presente no arquivo da zona e será assinada como os outros RRs da zona, mas os RRs atualizados/modificados devem ser assinados pela estação.

O segundo caso suporta a certificação da transação e da requisição. A assinatura dos RRs não protege os cabeçalhos das mensagens do DNS nem suas requisições. Se os bits do cabeçalho foram falsificados por um servidor, existe pouca coisa que pode ser feita. Entretanto, é possível adicionar a certificação da transação. Tal certificação significa que um resolvedor pode ao menos ter certeza que ele está recebendo a resposta do servidor para quem ele acredita ter passado a consulta e que a mensagem não foi manipulada no caminho. Isto é feito adicionando, opcionalmente, um RR SIG no final de uma resposta que assina a concatenação da resposta do servidor com a consulta do resolvedor.

Consultas também podem ser assinadas com um RR SIG. No DNS atual, tais assinaturas não são usadas mas, no futuro, elas podem ser úteis para requisições de atualização dinâmica ou consultas especiais.

O protocolo detalha diversos aspectos de implementação que não serão tratados neste artigo mas que o leitor mais interessado deve verificar na RFC 2065. Em particular, é interessante ver o tratamento da assinatura de transferência de zona para servidores escravos, dos problemas que envolvem os CNAMEs, da expiração das assinaturas, os algoritmos de criptografia considerados e o formato das mensagens." (2)

******************************

(1) http://www.sinpro-rs.org.br/extraclasse/mar05/entrevista.asp

(2) http://www.rnp.br/newsgen/9801/dnssec.html

(3) http://www.icann.org/strategic-plan/strategic-plan.html

(4) http://www.softwarelivre.org/news/3823

Fonte: Projeto Software Livre Brasil - Mario Teza - http://www.softwarelire.org

-- MarioTeza - 12 Apr 2005