[GTER] Fwd: DNSCurve

[Durval Menezes]

Prezado Rubens,

On Tue, Sep 02, 2008 at 04:44:42PM -0300, Rubens Kuhl Jr. wrote:
> Eu gostei da idéia. Eu tenho sérias restrições à postura do DJB, mas
> gostei do DNSCurve *apesar* de ser do DJB e não *por* ser do DJB.

Entendido. Em materia de postura, eu procuro nao ser nem contra
nem a favor, muito pelo contrario... ate' porque isso ja' seria
um problema de postura :-) Mas concordo que de fato o "estrelismo"
muitas vezes atrapalha.

> Mas
> torço para que entre as primeiras implementações estejam o NSD e o
> Unbound;

Ja' andei experimentando com ambos, e achei-os pouco flexiveis quando
comparados com o BIND; nao tem por exemplo o conceito de "views" do BIND,
e nao da' para rodar um servidor recursivo e autoritativo no mesmo IP
(util para instalacoes menores). Por outro lado, o Unbound ja' era (mais)
resistente `a vulnerabilidade levantada pelo Dan Kaminski "por default",
nao precisando de nenhum patch, ao contrario do BIND...

> a idéia ser do DJB não significa que a implementação precise
> ser DJB-ware...

E' verdade, o proprio DJB deixa isso (mais ou menos) claro. Ele so'
nao publicou (ate' agora) nenhum codigo para permitir/facilitar
estas implementacoes.

> eu gostaria de um cache resolver com suporte a NSEC,
> NSEC3 e DNSCurve, não a apenas um deles.

De fato seria o melhor, e nao deve ser dificil fazer isso no Unbound,
uma vez que ele e' totalmente modular.

> O autoritativo talvez seja
> mais prático fazer como forward como até o DJB sugere, e deixar o
> processo normal de desenvolvimento implantar essa funcionalidade nas
> novas versões.

Desde que algum dia saia uma implementacao para um DNSCurve server...
ate' agora o DJB nao "mostrou o codigo".

> Minha sensação é que se Nominum, Akamai, Google e Microsoft gostarem e
> adotarem o DNSCurve, será um padrão de fato. Gostaria que se tornasse
> um padrão de direito através de uma RFC, mas não acho que o ego do DJB
> o permita passar pelo processo da IETF... então pessoas dessas 4
> entidades, mais familiarizadas, poderiam fazê-lo, creditando-o pela
> idéia original.

Acho que este cenario tem bastante chance de vir mesmo a ocorrer.

Vamos observar, e torcer... eu ficaria muito satisfeito de ver
algo como o DNSCurve sendo implementado em larga escala.

Neste particular, na minha opiniao nada ajudaria a difundir o DNSCurve
mais rapidamente do que a sua implementacao no BIND (se possivel com a
bencao da ISC, senao atraves de patches de terceiros): a enorme maioria
de servidores DNS atualmente roda BIND (da ultima vez que vi, mais de 
65% dos dominios era servida por BIND).

Um Grande Abraco,
-- 
   Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)

> 
> Rubens
> 
> 
> On Tue, Sep 2, 2008 at 4:24 PM, Durval Menezes <durval at tmp.com.br> wrote:
> > Alo Rubens,
> >
> > E voce, como esta' encarando o DNSCurve?
> >
> > --
> >   Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)
> >
> >
> > On Mon, Sep 01, 2008 at 10:38:29AM -0300, Durval Menezes wrote:
> >> Alo Rubens,
> >>
> >> On Mon, Sep 01, 2008 at 12:32:41AM -0300, Rubens Kuhl Jr. wrote:
> >> > Como vocês veem as chances do DNSCurve, que apesar do discurso de ser
> >> > complementar ao DNSSEC, me parece sim uma tentativa (só um pouco
> >> > tardia) de propor uma alternativa ?
> >> >
> >> > http://dnscurve.org
> >> > http://cr.yp.to/talks/2008.08.22/slides.pdf
> >>
> >> Eu entendo que o DNSCurve ataca o problema da seguranca do DNS de uma
> >> forma completamente ortogonal `a do DNSSEC: enquanto o DNSSEC propoem
> >> implementar uma verdadeira PKI (hierarquica e tudo) baseada em chaves
> >> RSA, de forma que cada registro possa ser assinado e validado, o
> >> DNSCurve simplesmente implementa criptografia do trafego DNS; os
> >> registros de DNS sao mantidos inalterados, e simplesmente encapsulados
> >> dentro de um pacote criptografado.
> >>
> >> Concordo com voce quanto `a questao do DNSCurve poder ser uma
> >> alternativa ao DNSSEC: uma implementacao do DNSCurve produz uma boa
> >> imunidade quanto ao maior problema do DNS tradicional (ou seja, a
> >> facilidade de "poisoning"), e ao mesmo tempo prove algo que o DNSSEC
> >> nao prove, ou seja, a confidencialidade do trafego (o DNSSEC prove
> >> somente autenticidade). Alem disso, o DNSCurve parece (pelo que vi
> >> ate' agora) ser MUITO mais facil de implementar.
> >>
> >> O que eu achei GENIAL no DNSCurve e' a forma de distribuir as chaves
> >> publicas dos servidores autoritativos de cada dominio: elas sao EMBUTIDAS
> >> no proprio nome (FQDN) do servidor. Isso torna o "deployment" MUITO mais
> >> simples e evita os problemas logisticos de distribuicao de chaves do
> >> DNSSEC: voce nao precisa que o seu "DNS parent" suporte DNSSEC para voce
> >> tambem suporte) e permite uma implementacao mais "grassroots" e menos
> >> hierarquizada. Por outro lado, enquanto o seu "parent" nao suportar o
> >> DNSCurve, o seu dominio continua sendo passivel de envenenamento (que e'
> >> claro fica mais dificil, mas nao para um "sniffing attacker").
> >>
> >> Achei interessante tambem o fato do DNSCurve estar usando ECC para
> >> criptografia (dai' o nome "Curve"), principalmente por conta da
> >> eficiencia computacional. Entretanto, achei meio forte a afirmacao
> >> do DJB de que "1024-bit RSA is already breakable by large companies and
> >> botnets"; apesar de pessoalmente nao usar mais chaves RSA de 1024 bits
> >> desde 2002, nao estou ciente de nenhuma evidencia de que de fato essas
> >> chaves sejam tao vulneraveis assim. O Schneier concorda, vide post dele
> >> bem recente (a respeito da Kaspersky anunciar que uma botnet c/ 15M
> >> computadores ser capaz de quebrar uma chave RSA de 1024 bits em 1 ano)
> >> em http://www.schneier.com/blog/archives/2008/06/kaspersky_labs.html.
> >>
> >> O grande problema que vejo no presente momento com o DNSCurve e' que
> >> ele ainda e' "vaporware", ou seja, nao ha' ainda nenhum software de
> >> DNS server que o suporte (nem mesmo o djbdns do proprio DJB); certamente
> >> deverao haver novidades nos proximos dias...
> >>
> >> Um Grande Abraco,
> >> --
> >>    Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)
> >

----- End forwarded message -----

-- 
   Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)