From owner-namedroppers@ops.ietf.org Thu Jul 1 02:41:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03033 for ; Thu, 1 Jul 2004 02:41:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfvA2-000Glk-1s for namedroppers-data@psg.com; Thu, 01 Jul 2004 06:35:06 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfv9z-000GlF-Vo for namedroppers@ops.ietf.org; Thu, 01 Jul 2004 06:35:04 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 27B6E55E57; Thu, 1 Jul 2004 08:35:03 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 974DC4E475 for ; Thu, 1 Jul 2004 08:35:02 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i616Z28r020242 for ; Thu, 1 Jul 2004 08:35:02 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id i616Z1I2026705 for namedroppers@ops.ietf.org; Thu, 1 Jul 2004 08:35:01 +0200 Date: Thu, 1 Jul 2004 08:35:01 +0200 From: Olaf Kolkman Message-Id: <200407010635.i616Z1I2026705@x50.ripe.net> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy X-RIPE-Spam-Status: U 0.498972 / 0.0 / 0.0 / disabled X-RIPE-Signature: d8339d379601fa46b3aaadc3923db414 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format ISSUE: Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.7 2004/05/17 12:46:38 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From nv33134@yahoo.com Sat Jul 3 16:37:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19934 for <dnsext-archive@ietf.org>; Sat, 3 Jul 2004 16:37:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgrGl-0003HZ-41 for dnsext-archive@ietf.org; Sat, 03 Jul 2004 16:37:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgrFh-0002uF-00 for dnsext-archive@ietf.org; Sat, 03 Jul 2004 16:36:50 -0400 Received: from [202.129.49.34] (helo=ietf.org ident=squid) by ietf-mx with smtp (Exim 4.12) id 1BgrES-0001fK-00; Sat, 03 Jul 2004 16:35:35 -0400 From: "Atualidade Brasileira" <nv33134@yahoo.com> To: adm@ietf.org Subject: Moral e Economia: relação indispensável . yqi X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: <E1BgrES-0001fK-00@ietf-mx> Date: Sat, 03 Jul 2004 16:35:35 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA, FORGED_YAHOO_RCVD,FROM_ENDS_IN_NUMS,HTML_50_60,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID, SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora * -0.5 AWL AWL: Auto-whitelist adjustment <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252"> <META NAME="Generator" CONTENT="Microsoft Word 97"> <TITLE>www.msn.com

(ref.:eni) Última hora! Acaba de chegar à Cidade do Vaticano filial pedido a S.S. João Paulo II: Santo Padre, protegei o Brasil da "esquerda católica"! Clique aqui para receber gratuitamente, por e-mail, o texto completo da carta.

Série Temas Patrulhados (8)

Moral e Economia: relação indispensável

A formação moral de uma nação, com sólidos princípios culturais e religiosos, é a condição para resolver em profundidade os problemas econômicos, afirma Lindenberg

Verdadeira solução

* Para solucionar em profundidade os problemas econômicos, é necessário que os responsáveis pela formação de uma nação - o Clero em primeiro lugar - efetivamente ensinem os princípios morais, culturais e religiosos que são o fundamento e a "conditio sine qua non" da ordem socioeconômica, afirma Adolpho Lindenberg no artigo "Economia e Moral", da Série Temas Patrulhados.

"Patrulhamento"

* Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza, "patrulha" ou encobre com um manto de silêncio, opiniões "politicamente incorretas", não afinadas com as ideologias de esquerda.

Progresso material e hábitos virtuosos

* O articulista acrescenta que a riqueza, a estabilidade econômica e o progresso material de um povo dependem não só do respeito ao direito de propriedade e às leis da livre iniciativa, mas de hábitos sociais virtuosos: esforço intenso, sistematizado, capacidade profissional adquirida pelo estudo e trabalho, vontade e força de poupar , morigeração nos gastos e discernimento na condução dos negócios.

Entrelaçamento da moral e a economia

* Infelizmente, esse entrelaçamento de preceitos de ordem moral e de questões econômicas é esquecido pela maioria dos prelados que prega reformas de estrutura, condena a inserção de nossa economia no cenário mundial, censura os lucros das empresas, etc. com o intuito alegado de minorar a sorte dos carentes e marginalizados. Sermões recomendando o hábito de trabalhar metódica e intensamente e a praxe de economizar seriam muito mais úteis do que incitamentos a protestos, greves e invasões, conclui Lindenberg em seu extenso artigo, que oferecemos gratuitamente aos leitores.

040610CN - ConstruNews

Links de opinião

Gostaríamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail, incluindo, se possível, conhecer sua valiosa opinião:

Concordo - Discrepo - EmTermos

Links gratuitos (e-Book e outros artigos):

* Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em: EsteArtigoCompletoGratuitamente(No.8)

E-BookGratuitoBr (em formato Word, com 11 artigos de Lindenberg)

IntroduçãoGratuitaDoLivro (em formato Word, Introdução do livro "Os católicos e a economia de mercado")

ArtigosAnteriores - ProximosArtigos

LinksGratuitos-TODOS (para receber, num só e-mail, todos os links gratuitos acima)

Outros links

EnEspañol - LinkToFreeTranslator

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder adquirir o livro no Brasil)

Remover Caso já tiver efetuado anteriormente, sem sucesso, o pedido de remoção, lhe solicitamos o enorme favor de nos enviar na íntegra o denominado "Código Fonte da Mensagem". Assim poderemos verificar a qual e-mail, exatamente, lhe escrevemos, e tirá-lo imediatamente do Address Book. Instruções para chegar até o "Código Fonte": no Outlook Express clique acima da mensagem com o botão direito do "mouse", depois em "Propriedades", "Detalhes" e "Código Fonte". Solicitamos sinceras desculpas pelos inconvenientes ocasionados.

A difusão desta mensagem --com o intuito de promover um debate cultural, respeitoso de idéias-- é de exclusiva responsabilidade da ConstruNews. Telefone de contato: (11) 9252 - 7873

 

 

 

 

From owner-namedroppers@ops.ietf.org Wed Jul 7 05:01:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05059 for ; Wed, 7 Jul 2004 05:01:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bi8DO-00066n-16 for namedroppers-data@psg.com; Wed, 07 Jul 2004 08:55:42 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bi8DM-00066R-Nu for namedroppers@ops.ietf.org; Wed, 07 Jul 2004 08:55:40 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id F2DE94FFEF; Wed, 7 Jul 2004 10:55:39 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A21A44FFF7; Wed, 7 Jul 2004 10:55:39 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i678td4c011263; Wed, 7 Jul 2004 10:55:39 +0200 Date: Wed, 7 Jul 2004 10:55:39 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Cc: Rip Loomis , Ben Laurie Subject: Denial of Existence: Requirements Message-Id: <20040707105539.59d7dc4e.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.002199 / 0.0 / 0.0 / disabled X-RIPE-Signature: 19a2b40c52c359f2bc8b4984d52109f3 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear colleagues, DNSSEC-bis is about to go out of the door. It is now time to start some work on the denial of existence problem (among other work in DNSEXT). In order to not be surprised at a later stage we would like to start with making an inventory of the requirements for this work. We have found two document editors who are willing to collect requirements off-list and write these down in an internet-draft that can be presented in San Diego [*]. We want to be careful that drawing up the requirements does not end up in a 'bashing party' and we do not want to go into the feasibility of the requirements. Once the requirements are collected and published we want to assign a priority to them (a WG task). Some requirements may be dropped to achieve others, we want to know up-front which requirements are of least value. Only after this work has been done we can go off and try to find a solution to our problems. Please send your requirements, in the form of use cases, policy language, or your favorite functional requirement language to Ben Laurie _and_ Rip Loomis who have kindly volunteered to be the editors for this work. --Olaf and Olafur DNSEXT co-Chairs. [*] or an initial post to the mailinglist so that we have discussion material in San Diego where we have set aside a 1 hour slot on discussing "the future of DNSSEC" -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 7 05:17:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05636 for ; Wed, 7 Jul 2004 05:17:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bi8X3-0008q6-DU for namedroppers-data@psg.com; Wed, 07 Jul 2004 09:16:01 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bi8X2-0008po-CI for namedroppers@ops.ietf.org; Wed, 07 Jul 2004 09:16:00 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id BBF6755DE3; Wed, 7 Jul 2004 11:15:56 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 49B6555DDB for ; Wed, 7 Jul 2004 11:15:56 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i679Fu4c019190 for ; Wed, 7 Jul 2004 11:15:56 +0200 Date: Wed, 7 Jul 2004 11:15:56 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: DNSEXT Agenda Items for IETF 60 Message-Id: <20040707111556.03eea66b.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000485 / 0.0 / 0.0 / disabled X-RIPE-Signature: 30bcec23bb36de1a418c6500d293e3ee X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues We are scheduled to have two slots in San Diego: Monday 09:00-11:30 and Tuesday 17:00-18:00. In the first slot we plan to cover all open WG items and we'll make a start with discussing some deployment issues, the second slot will be about DNSSEC future work and possibly a continuation of the discussions started in the first slot. During the whole IETF meeting there will be ability to conduct experiments, and hold small meetings in a room with white board. If people want to conduct interoperability testing we would like to facilitate that, please propose these on namedroppers. The agenda is not set yet. We invite you to bring topics to the table. Please send in requests for discussion slots to both chairs. If you plan to publish an new ID before the meeting please let us know in your slot request. Beware of the cutoff dates of July 12th 09:00 ET for initial versions of draft and of July 19th 09:00ET for Olafur & Olaf Draft Agenda 1s version 1st slot Monday Aug 2, 09:00-11:30 - WG Administrivia + Session administration - Appointment Scribes - Agenda Bashing - Previous Minutes + Document Status + Charter Review - Schlyter: Report on RFC 3597 interoperability testing. - DNSSEC Deployment issues + Key management topics - St. John: draft-stjohns-dnssec-trustupdate-00 - Ihren: DNSSEC in-band key rollover (draft to be published). 2nd slot Tuesday Aug 3, 17:00-18:00 - What's next in DNSSEC. + Requirements for future work on Denial of Existence See my message posted earlier today. - Open mike (We are hoping Eminem to show up.) ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 12 11:25:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17168 for ; Mon, 12 Jul 2004 11:25:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk2Xr-00029y-JK for namedroppers-data@psg.com; Mon, 12 Jul 2004 15:16:43 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk2Xq-00029Q-C8 for namedroppers@ops.ietf.org; Mon, 12 Jul 2004 15:16:42 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 28F07AC8B; Mon, 12 Jul 2004 17:16:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 27DDEAC8A for ; Mon, 12 Jul 2004 17:16:37 +0200 (CEST) Date: Mon, 12 Jul 2004 17:16:37 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: draft-arends-dnsnr-00 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, I've just submitted draft-arends-dnsnr-00.txt as an individual draft. This draft sollicits acceptance by the DNSEXT working group. The draft can be found at http://www.logmess.com/~roy/draft-arends-dnsnr-00.txt Abstract: This document describes the DNSNR Resource Record (RR) for the Non-Repudiation (NR) of Existence service in the context of the DNS Security Extensions (DNSSEC). The DNSNR is an alternative to NSEC or "Authenticated Denial of Existence" Resource Records. A signed DNSNR RR protects security-aware DNS components against false denial of existence of RRsets by providing the RR types that exist for its ownername, which optionally includes a non-authoritative delegation point NS RR type. Labels in the ownername and the RDATA may be a hash-value as a defense against zone traversal. The DNSNR is an alternative to current NSEC or "Authenticated Denial of Existence" records. Thanks, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 12 13:10:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24615 for ; Mon, 12 Jul 2004 13:10:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk4FV-000Hdm-Qf for namedroppers-data@psg.com; Mon, 12 Jul 2004 17:05:53 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk4FU-000HdE-QS for namedroppers@ops.ietf.org; Mon, 12 Jul 2004 17:05:52 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i6CH2YC0024594 for ; Mon, 12 Jul 2004 13:02:34 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i6CH22qR002271 for ; Mon, 12 Jul 2004 13:02:03 -0400 (EDT) From: "Scott Rose" To: Subject: comments on draft-arends-dnsnr-00 Date: Mon, 12 Jul 2004 13:02:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just went over the DNSNR draft quickly. Some comments - 1. The acronym MNR and NMR are used, but I don't see them defined anywhere. It isn't the authoritative only bit, is it? Because the ascii representation says it can have the value of '3'. 2. The next owner name is represented as a domain name - what if it's a hash value? 3. TTL recommendations - Section 2 says there are none, but DNSSECbis has the NSEC RR's TTL value be the SOA min. Is there a good reason not to have it be that value? I would like to see this become a WG document as a possible replacement for NSEC. If it can address zone owners' concerns with zone enumeration. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Roy Arends > Sent: Monday, July 12, 2004 11:17 AM > To: namedroppers@ops.ietf.org > Subject: draft-arends-dnsnr-00 > > > Hi, I've just submitted draft-arends-dnsnr-00.txt as an individual draft. > This draft sollicits acceptance by the DNSEXT working group. The draft > can be found at http://www.logmess.com/~roy/draft-arends-dnsnr-00.txt > > Abstract: > > This document describes the DNSNR Resource Record (RR) for the > Non-Repudiation (NR) of Existence service in the context of the DNS > Security Extensions (DNSSEC). The DNSNR is an alternative to NSEC or > "Authenticated Denial of Existence" Resource Records. > > A signed DNSNR RR protects security-aware DNS components against > false denial of existence of RRsets by providing the RR types that > exist for its ownername, which optionally includes a > non-authoritative delegation point NS RR type. Labels in the > ownername and the RDATA may be a hash-value as a defense against zone > traversal. > > The DNSNR is an alternative to current NSEC or "Authenticated Denial > of Existence" records. > > Thanks, > > Roy > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 12 22:48:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17416 for ; Mon, 12 Jul 2004 22:48:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkDGq-00021K-Qs for namedroppers-data@psg.com; Tue, 13 Jul 2004 02:43:52 +0000 Received: from [149.8.64.32] (helo=mclmx2.mail.saic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkDGp-00020y-LO for namedroppers@ops.ietf.org; Tue, 13 Jul 2004 02:43:52 +0000 Received: from mcl-its-ieg01.mail.saic.com by mclmx2.mail.saic.com; Mon, 12 Jul 2004 22:43:31 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.6.45) with SMTP id M2004071222433123215 ; Mon, 12 Jul 2004 22:43:31 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <33RNP99H>; Mon, 12 Jul 2004 22:43:31 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE1051CC@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Roy Arends'" Cc: namedroppers@ops.ietf.org Subject: comments on draft-arends-dnsnr-00 Date: Mon, 12 Jul 2004 22:41:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello Roy-- In section 2.1.3, there is a sentence that says, "The Salt field value must be the same for every DNSNR generated in the zone." That may be a reasonable requirement, but off the top of my head I think I can come up with some good reasons not to make that a requirement--could you please elaborate (on list or in a revised draft) as to why that's a "must"? I also have some very very minor typos which I'll send to you off-list. --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 13 03:17:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17013 for ; Tue, 13 Jul 2004 03:17:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkHRL-000AMH-1D for namedroppers-data@psg.com; Tue, 13 Jul 2004 07:10:59 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkHRJ-000AM4-RV for namedroppers@ops.ietf.org; Tue, 13 Jul 2004 07:10:58 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id E9B45AC8B; Tue, 13 Jul 2004 09:10:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id E3F12AC8A; Tue, 13 Jul 2004 09:10:55 +0200 (CEST) Date: Tue, 13 Jul 2004 09:10:55 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Scott Rose Cc: namedroppers@ops.ietf.org Subject: Re: comments on draft-arends-dnsnr-00 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 12 Jul 2004, Scott Rose wrote: > Just went over the DNSNR draft quickly. Some comments - > > 1. The acronym MNR and NMR are used, but I don't see them defined anywhere. > It isn't the authoritative only bit, is it? Yes it is. MNR must be 'Authoritative Only Field'. > Because the ascii > representation says it can have the value of '3'. Yes. That must be either a value of '0' or '1'. This is due to a previous version where you could extend the use by having more granualarity. I decided to drop that in favour of less complexity. > 2. The next owner name is represented as a domain name - what if it's a > hash value? I will add an example to the draft. A Domain name is never presented as a hash. Labels are. The label is then represented as a base32 encoded output of the hash function. In case of SHA-1, the label would be 32 characters long if no truncation is used. > 3. TTL recommendations - Section 2 says there are none, but DNSSECbis has > the NSEC RR's TTL value be the SOA min. Is there a good reason not to have > it be that value? There is no good reason :-). I will add TTL recommendations to the draft. > I would like to see this become a WG document as a possible replacement for > NSEC. If it can address zone owners' concerns with zone enumeration. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 13 03:37:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17885 for ; Tue, 13 Jul 2004 03:37:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkHn7-000CwR-T2 for namedroppers-data@psg.com; Tue, 13 Jul 2004 07:33:29 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkHn6-000CwB-TQ for namedroppers@ops.ietf.org; Tue, 13 Jul 2004 07:33:29 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 1F262AC8B; Tue, 13 Jul 2004 09:33:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 1968EAC8A; Tue, 13 Jul 2004 09:33:28 +0200 (CEST) Date: Tue, 13 Jul 2004 09:33:28 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: "Loomis, Rip" Cc: namedroppers@ops.ietf.org Subject: Re: comments on draft-arends-dnsnr-00 In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE1051CC@US-Columbia-CIST.mail.saic.com> Message-ID: References: <4E25ECBBC03F874CBAD03399254ADFDE1051CC@US-Columbia-CIST.mail.saic.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 12 Jul 2004, Loomis, Rip wrote: > Hello Roy-- > In section 2.1.3, there is a sentence that says, "The Salt field > value must be the same for every DNSNR generated in the zone." > That may be a reasonable requirement, but off the top of my head > I think I can come up with some good reasons not to make that a > requirement--could you please elaborate (on list or in a revised > draft) as to why that's a "must"? I will add text to the draft on why that MUST be for every NSEC for the same version. In short, when a nameserver on reception of a query for a non-existent name must add the proper DNSNR to the response (to repudiate existence), it needs a salt (x) to augment QNAME, it will hash the result and find the appropriate DNSNR to proof the hash(salt+qname) does not exist. If (x) is different for every DNSNR, you might end up with proof claiming example.com + salt=4 does not exist, and example.com + salt=7 does exist. > I also have some very very minor typos which I'll send to you > off-list. Thanks ! Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 13 08:24:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05207 for ; Tue, 13 Jul 2004 08:24:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkMDB-0002QU-Kr for namedroppers-data@psg.com; Tue, 13 Jul 2004 12:16:41 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkMDA-0002QD-Ek for namedroppers@ops.ietf.org; Tue, 13 Jul 2004 12:16:40 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 927174FD12; Tue, 13 Jul 2004 14:16:39 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 54CD04FCFF for ; Tue, 13 Jul 2004 14:16:39 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i6DCGd4c011243 for ; Tue, 13 Jul 2004 14:16:39 +0200 Date: Tue, 13 Jul 2004 14:16:39 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: In-Band Rollover and Out-Of-Band Priming Message-Id: <20040713141639.0e844225.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.013952 / 0.0 / 0.0 / disabled X-RIPE-Signature: ff7fd7d29e955f0e644694d0d3f1ecc8 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a heads up for: draft-kolkman-dnsext-dnssec-in-band-rollover-00: http://www.ietf.org/internet-drafts/draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt Abstract The DNS Security Extensions (DNSSEC) works by validating so called chains of authority. The start of these chains of authority are usually public keys that are anchored in the DNS clients, the so called trust anchors. This memo describes a method how these client trust anchors can be replaced using the DNS validation and querying mechanisms (in-band) if the key pairs used for signing by zone owner are rolled. This memo also describes a method to establish the validity of trust anchors for initial configuration, or priming, using out of band mechanisms. This will be on the agenda of Thuesday slot. -- Olaf Co-author ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 13 09:48:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10459 for ; Tue, 13 Jul 2004 09:48:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkNZu-000PTw-JZ for namedroppers-data@psg.com; Tue, 13 Jul 2004 13:44:14 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BkNZr-000PTV-8k for namedroppers@ops.ietf.org; Tue, 13 Jul 2004 13:44:11 +0000 Received: (qmail 86322 invoked from network); 13 Jul 2004 13:49:15 -0000 Received: from yahoobb219001188031.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.31) by necom830.hpcl.titech.ac.jp with SMTP; 13 Jul 2004 13:49:15 -0000 Message-ID: <40F3E878.9020909@necom830.hpcl.titech.ac.jp> Date: Tue, 13 Jul 2004 22:49:44 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: namedroppers@ops.ietf.org Subject: Re: In-Band Rollover and Out-Of-Band Priming References: <20040713141639.0e844225.olaf@ripe.net> In-Reply-To: <20040713141639.0e844225.olaf@ripe.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf; > This is a heads up for: draft-kolkman-dnsext-dnssec-in-band-rollover-00: Why do we need rollover? What kind of attack is assumed to be protected against? Depending on the assumed attack, it may be better just to have a single long key forever than having multiple short ones. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 14 19:11:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07034 for ; Wed, 14 Jul 2004 19:11:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkslB-000ONO-2Q for namedroppers-data@psg.com; Wed, 14 Jul 2004 23:01:57 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bksl8-000OMi-2z for namedroppers@ops.ietf.org; Wed, 14 Jul 2004 23:01:54 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i6EN1p7O015463; Wed, 14 Jul 2004 16:01:51 -0700 Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jul 2004 16:01:52 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Olaf M. Kolkman'" , namedroppers@ops.ietf.org Subject: RE: DNSEXT Agenda Items for IETF 60 Date: Wed, 14 Jul 2004 16:01:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The second meeting appears to have moved: 0900-1130 Morning Sessions THURSDAY, August 5, 2004 It is on at the same time as SEC mass Message Authentication Signature Standards BOF Which is likely to be attended by most of the crypto people. A common feature of all the input docs for MASS is the use of DNS for distribution of domain keys [and key management service keys]. Ergo MASS is likely to be one of the applications that would create a demand for DNSSEC. Phill > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Olaf M. Kolkman > Sent: Wednesday, July 07, 2004 5:16 AM > To: namedroppers@ops.ietf.org > Subject: DNSEXT Agenda Items for IETF 60 > > > > > Dear Colleagues > > We are scheduled to have two slots in San Diego: Monday 09:00-11:30 > and Tuesday 17:00-18:00. In the first slot we plan to cover all open > WG items and we'll make a start with discussing some deployment > issues, the second slot will be about DNSSEC future work and possibly > a continuation of the discussions started in the first slot. > > During the whole IETF meeting there will be ability to conduct > experiments, and hold small meetings in a room with white board. If > people want to conduct interoperability testing we would like to > facilitate that, please propose these on namedroppers. > > The agenda is not set yet. We invite you to bring topics to the table. > Please send in requests for discussion slots to both chairs. If you > plan to publish an new ID before the meeting please let us know in > your slot request. > > Beware of the cutoff dates of July 12th 09:00 ET for initial versions > of draft and of July 19th 09:00ET for > > > Olafur & Olaf > > > Draft Agenda 1s version > > 1st slot > Monday Aug 2, 09:00-11:30 > > - WG Administrivia > + Session administration > - Appointment Scribes > - Agenda Bashing > - Previous Minutes > > + Document Status > > + Charter Review > > > - Schlyter: Report on RFC 3597 interoperability testing. > > - DNSSEC Deployment issues > + Key management topics > - St. John: draft-stjohns-dnssec-trustupdate-00 > - Ihren: DNSSEC in-band key rollover (draft to be published). > > > 2nd slot > Tuesday Aug 3, 17:00-18:00 > > - What's next in DNSSEC. > > + Requirements for future work on Denial of Existence > See my message posted earlier today. > > - Open mike > > (We are hoping Eminem to show up.) > > > > > > ---------------------------------| Olaf M. Kolkman > ---------------------------------| RIPE NCC > > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 15 03:49:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01257 for ; Thu, 15 Jul 2004 03:49:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bl0tm-0006Ns-Ex for namedroppers-data@psg.com; Thu, 15 Jul 2004 07:43:22 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bl0tl-0006NZ-6t for namedroppers@ops.ietf.org; Thu, 15 Jul 2004 07:43:21 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 1A8D64FC77; Thu, 15 Jul 2004 09:43:20 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id ADC704E17A; Thu, 15 Jul 2004 09:43:19 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i6F7hJ4c009327; Thu, 15 Jul 2004 09:43:19 +0200 Date: Thu, 15 Jul 2004 09:43:19 +0200 From: "Olaf M. Kolkman" To: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT Agenda Items for IETF 60 Message-Id: <20040715094319.2e48329b.olaf@ripe.net> In-Reply-To: References: Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000282 / 0.0 / 0.0 / disabled X-RIPE-Signature: 3495c3ac5d328a76babb364aa5c0abb4 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 14 Jul 2004 16:01:50 -0700 "Hallam-Baker, Phillip" wrote: > The second meeting appears to have moved: > > 0900-1130 Morning Sessions > THURSDAY, August 5, 2004 (...) > Ergo MASS is likely to be one of the applications that would create > a demand for DNSSEC. Sounds like a conflict to me, we want crypto geeks around during the DNSEXT session. One of the possible ways to solve it is by rearanging the DNSEXT agenda, see below.q I've included the parallel sessions. It looks like we can draw crypto and ops folk (although multi6 might pull them away) on monday morning. --Olaf ------------------------------------------------------------ DRAFT DNSEXT Agenda IETF 60. Monday Aug 2, 09:00-11:30 1st slot DNSSEC session - WG Administrivia (5-10 min) + Session administration - Appointment Scribes - Agenda Bashing - Previous Minutes http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02219.html - DNSSEC Deployment issues + Key management topics - St. John: draft-stjohns-dnssec-trustupdate-00 - Ihren: DNSSEC in-band key rollover (draft-kolkman-dnsext-dnssec-in-band-rollover-00) - Requirements for future work on Denial of Existence A possible approach: + DNSNR draft-arends-dnsnr-00.txt (10 min) This session is parallel to: APP apparea Applications Open Area Meeting IRTF mobopts IP Mobility Optimizations OPS multi6 Site Multihoming in IPv6 WG OPS hubmib Ethernet Interfaces and Hub MIB WG RTG manet Mobile Ad-hoc Networks WG TSV xcon Centralized Conference WG -------------------- -------------------- -------------------- 2nd slot Thursday Aug 5, 9:00-11:30 Other DNSEXT extention work. - Schlyter: Report on RFC 3597 interoperability testing. http://www.rfc.se/interop3597 - Eastlake: draft-eastlake-tsig-sha-03.txt (5-10 minutes) - More WG Administrivia + Document Status + Charter Review - Open mike This session is parallel to: APP atompub Atom Publishing Format and Protocol WG GEN newtrk New IETF Standards Track Discussion WG INT hip Host Identity Protocol WG RTG mpls Multi Protocol Label Switching WG SEC mass Message Authentication Signature Standards BOF SEC msec Multicast Security WG TSV tsvwg Transport Area Working Group ------------------------------------------------------------ $Id: agenda.txt,v 1.5 2004/07/15 07:42:51 olaf Exp $ ------------------------------------------------------------ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 15 20:27:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21715 for ; Thu, 15 Jul 2004 20:27:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlGSI-0004Al-IP for namedroppers-data@psg.com; Fri, 16 Jul 2004 00:20:02 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlGSH-0004AC-Iv for namedroppers@ops.ietf.org; Fri, 16 Jul 2004 00:20:01 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id B9B4027C for ; Thu, 15 Jul 2004 20:20:00 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 18BD642B2 for ; Thu, 15 Jul 2004 20:20:00 -0400 (EDT) Date: Thu, 15 Jul 2004 20:20:00 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: New versions of DNSSECbis drafts posted MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040716002000.18BD642B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk New versions of the DNSSECbis drafts have just been sent off to the Internet-Drafts coordinator. Copies (and htmlwdiff output) are also available on the web at: http://www.hactrn.net/ietf/dns/dnssec-editors/ These versions reflect the final changes from the WG last call. As always, please send minor comments to dnssec-editors@east.isi.edu, substantive issues to namedroppers. --Rob (on behalf of your friendly neighborhood DNSSEC editors) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 16 09:23:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29616 for ; Fri, 16 Jul 2004 09:23:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlSYm-000Gl1-7A for namedroppers-data@psg.com; Fri, 16 Jul 2004 13:15:32 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlSYc-000GiC-Al for namedroppers@ops.ietf.org; Fri, 16 Jul 2004 13:15:23 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 1CC271078C9; Fri, 16 Jul 2004 13:15:21 +0000 (GMT) Message-ID: <40F7D4E8.9080705@algroup.co.uk> Date: Fri, 16 Jul 2004 14:15:20 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= Cc: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO References: <6.1.0.6.2.20040524180114.0652aec0@localhost> <40B35FB7.1080302@algroup.co.uk> <6.1.0.6.2.20040525102400.02f9a038@localhost> In-Reply-To: <6.1.0.6.2.20040525102400.02f9a038@localhost> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Ólafur Guðmundsson wrote: > > Thanks Ben for sticking to technical issues. > > At 11:01 25/05/2004, Ben Laurie wrote: > >> Ólafur Guðmundsson wrote: >> >>> 2. MarkK is too much of an gentleman to say this, so I will: >>> - opt-in addresses your publicly stated issue with NSEC. >>> only by securing a domain does become it trivial to >>> find whois info. >> >> >> Security or privacy, choose one, you mean? >> >> Another problem with this coould be that you are now publishing a list >> of high-value targets. > > But it is the "targets" choice, not the registries. It is not a free choice - by choosing to be secure, they also choose to be exposed. >>> 6. Current NSEC2 proposal does not address the issue of name conflict >>> between >>> a valid name and a digest, NO addressed this by moving all NO >>> records >>> into a separate name space. >> >> I haven't understood why this is needed - why do name conflicts >> matter? Since NSEC2 records are special, they can be treated as being >> in a separate namespace anyway. Explicitly adding one just wastes >> space. Or am I missing something? > > Ok let me demonstrate, for the sake of argument we hash with md5 once > and the hashed name is encoded in hex. > MD5("amazon.co.uk") = beb32a6851b0317502d5a40ce5146e43.co.uk. I make it 4d99aa84d5d72b1b57e56a5b186a0c64.co.uk. (or 873bcdba87401b485022b8dcd4190e3e.co.uk. if the more correct "amazon.co.uk." is the string). > Now, what if I have already registered that name and even gone as > far as trademarking it. > what happens ? Nothing - that name only appears in NSEC2 records - it would not be a trademark infringement for it to do so. > how will resolvers react seeing both NS and NSEC-bis at the same > note? I'm not sure I understand this question. > what does the denial for my name look like ? MD5("873bcdba87401b485022b8dcd4190e3e.co.uk.")=ac054ef84e1e8228996513d3ea6d8484.co.uk. > The current proposal addresses this partially by having multiple rounds > of hash, and salt. But these parameters can only be changed once in a > while. No, these measures are not intended to address this problem. > Moving the rounds into the NSEC2 record allows the zone signer to keep > trying > until there is no conflict, but there is no way for resolver to query > directly > for the NSEC2 record as the resolver does not know how many rounds there > are. I still do not see why a conflict matters. Even if there is, the "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the other name _never_ appears in NSEC2 records. > > These are just some of the complications that needs to be thought out > documented, coded and tested a few times, before DNSSEC v4 will be ready > in 2006. I am working on coding as we speak. > First lets get the requirements on the table, not the solutions. I agree we should understand the requirements. However, I am reasonably confident that NSEC2 addresses Nominet's requirements, as may other solutions. It would be nice to know that we can address _everyone's_ requirements. > As far as I can tell there is only one requirement on the table: > NO ZONE walking of TLD's via negative answer records. Is this what you would like us to include for you in the requirements I-D? > As for constraints > size (number of names) > wildcards > label depth. > > Add requirements and constraints as you see fit. > Think about both TLD's and leaf zones. > Then think about ENUM, a sparse but deep zone, what are the implications > there. ENUM is trivially enumerated by trial and error, so I don't see the applicability of NSEC2. This could be considered a flaw in ENUM. There may be workarounds, but that would be an issue for ENUM and not for DNSSEC, IMO. > We can not keep on solving just one party's problem we need to think > forward. Which "one party" did you have in mind? It has already been made clear that this issue is not solely Nominet's. Nominet have, though, undertaken to put the work in required to solve it. > Once we have the requirements we can think about how to best address the > issue, either by protocol changes, document changes or (maybe) ignore. > > Example: Opt-in was viewed by some as a solution to a "Verisign only" > problem, > in hindsight it might provide what you want/need. I do not see how it does. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 16 11:05:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07456 for ; Fri, 16 Jul 2004 11:05:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlUDp-0003Xx-HO for namedroppers-data@psg.com; Fri, 16 Jul 2004 15:02:01 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlUDo-0003Xc-Gh for namedroppers@ops.ietf.org; Fri, 16 Jul 2004 15:02:00 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 6A0AE1078C9; Fri, 16 Jul 2004 15:01:59 +0000 (GMT) Message-ID: <40F7EDE6.9060302@algroup.co.uk> Date: Fri, 16 Jul 2004 16:01:58 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Ben Laurie Cc: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO References: <6.1.0.6.2.20040524180114.0652aec0@localhost> <40B35FB7.1080302@algroup.co.uk> <6.1.0.6.2.20040525102400.02f9a038@localhost> <40F7D4E8.9080705@algroup.co.uk> In-Reply-To: <40F7D4E8.9080705@algroup.co.uk> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben Laurie wrote: Apologies - not sure why Olafur's orginal email got recycled, but it appeared to be in response to recent stuff, so I mistakenly responded. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 16 11:53:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10777 for ; Fri, 16 Jul 2004 11:53:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlUyB-0009Mm-OX for namedroppers-data@psg.com; Fri, 16 Jul 2004 15:49:55 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlUyA-0009MW-3X for namedroppers@ops.ietf.org; Fri, 16 Jul 2004 15:49:54 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i6GFngqJ022802; Fri, 16 Jul 2004 16:49:42 +0100 (BST) To: Ben Laurie cc: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Message from Ben Laurie of "Fri, 16 Jul 2004 14:15:20 BST." <40F7D4E8.9080705@algroup.co.uk> Date: Fri, 16 Jul 2004 16:49:42 +0100 Message-ID: <22801.1089992982@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Ben" == Ben Laurie writes: Ben> I make it 4d99aa84d5d72b1b57e56a5b186a0c64.co.uk. (or Ben> 873bcdba87401b485022b8dcd4190e3e.co.uk. if the more correct Ben> "amazon.co.uk." is the string). >> Now, what if I have already registered that name and even gone >> as far as trademarking it. what happens ? Ben> Nothing - that name only appears in NSEC2 records - it would Ben> not be a trademark infringement for it to do so. Suppose I've just incorporated 873bcdba87401b485022b8dcd4190e3e Limited and registered that name as a trademark. Oh, and I want to register my company's name in co.uk. See you in court. :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 16 11:53:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10816 for ; Fri, 16 Jul 2004 11:53:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlUyW-0009RB-1N for namedroppers-data@psg.com; Fri, 16 Jul 2004 15:50:16 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlUyU-0009QO-OJ for namedroppers@ops.ietf.org; Fri, 16 Jul 2004 15:50:15 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id C87131078C9; Fri, 16 Jul 2004 15:50:13 +0000 (GMT) Message-ID: <40F7F935.7050204@algroup.co.uk> Date: Fri, 16 Jul 2004 16:50:13 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 References: In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > This document describes the DNSNR Resource Record (RR) for the > Non-Repudiation (NR) of Existence service in the context of the DNS > Security Extensions (DNSSEC). The DNSNR is an alternative to NSEC or > "Authenticated Denial of Existence" Resource Records. I would argue against the use of the term "non-repudiation" in any case (for detailed reasons, see http://www.apache-ssl.org/tech-legal.pdf) but in this particular case, regardless of its lack of merit, it has the opposite meaning to that intended - that is, you are trying to repudiate existence. In 2.1.5 you say "The Type bit for the DNSNR and RRSIG MUST be set during generation, and MUST be ignored during processing." - I don't see why? 3.2.2 says "The probability of finding a second preimage is 1 in 2^160 for SHA-1 on average." - it would be more proper to say "the probability of a random string being a second preimage is 1 in 2^160..." (I can make the probability of _finding_ one as close to 1 as I like, by searching for longer). Also, you have not dealt with wildcards at all. If there is interest in allowing for opt-in in NSEC2 (optionally), btw, I am quite happy to modify it to do so. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 16 11:55:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11118 for ; Fri, 16 Jul 2004 11:55:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlV2d-000AHW-AG for namedroppers-data@psg.com; Fri, 16 Jul 2004 15:54:31 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlV2c-000AHA-8q for namedroppers@ops.ietf.org; Fri, 16 Jul 2004 15:54:30 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 2E44A1078C9; Fri, 16 Jul 2004 15:54:29 +0000 (GMT) Message-ID: <40F7FA34.3040401@algroup.co.uk> Date: Fri, 16 Jul 2004 16:54:28 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Jim Reid Cc: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO References: <22801.1089992982@gromit.rfc1035.com> In-Reply-To: <22801.1089992982@gromit.rfc1035.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim Reid wrote: >>>>>>"Ben" == Ben Laurie writes: > > > Ben> I make it 4d99aa84d5d72b1b57e56a5b186a0c64.co.uk. (or > Ben> 873bcdba87401b485022b8dcd4190e3e.co.uk. if the more correct > Ben> "amazon.co.uk." is the string). > > >> Now, what if I have already registered that name and even gone > >> as far as trademarking it. what happens ? > > Ben> Nothing - that name only appears in NSEC2 records - it would > Ben> not be a trademark infringement for it to do so. > > Suppose I've just incorporated 873bcdba87401b485022b8dcd4190e3e > Limited and registered that name as a trademark. Oh, and I want to > register my company's name in co.uk. See you in court. :-) Sure, but I'm pretty damn sure you'd lose. If you really want to waste a lawyer's time on this red herring, I'm sure I can get an opinion. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 16 12:15:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12348 for ; Fri, 16 Jul 2004 12:15:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlVKe-000DMa-Im for namedroppers-data@psg.com; Fri, 16 Jul 2004 16:13:08 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlVKd-000DMM-Fx for namedroppers@ops.ietf.org; Fri, 16 Jul 2004 16:13:07 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i6GGD5WE006998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 16 Jul 2004 16:13:06 GMT (envelope-from roy+dated+1092586384.427af1@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i6GGD4CG030344 for ; Fri, 16 Jul 2004 17:13:04 +0100 (BST) (envelope-from roy+dated+1092586384.427af1@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i6GGD4H4030343 for namedroppers@ops.ietf.org; Fri, 16 Jul 2004 17:13:04 +0100 (BST) (envelope-from roy+dated+1092586384.427af1@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 16 Jul 2004 17:13:02 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16631.65166.40261.244144@giles.gnomon.org.uk> Date: Fri, 16 Jul 2004 17:13:02 +0100 To: Ben Laurie Cc: Jim Reid , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: <40F7FA34.3040401@algroup.co.uk> References: <22801.1089992982@gromit.rfc1035.com> <40F7FA34.3040401@algroup.co.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Ben" == Ben Laurie writes: >> Suppose I've just incorporated >> 873bcdba87401b485022b8dcd4190e3e Limited and registered that >> name as a trademark. Oh, and I want to register my company's >> name in co.uk. See you in court. :-) Ben> Sure, but I'm pretty damn sure you'd lose. If you really want Ben> to waste a lawyer's time on this red herring, I'm sure I can Ben> get an opinion. However it would be nice if the NSEC2 record at 873bcdba87401b485022b8dcd4190e3e.co.uk didn't prevent that owner name from being used as a prefectly normal name for other purposes. ie someone _should_ be allowed to register it if they really wanted to. Whilst a clash of this kind occuring accidentally is improbable, there may be future applications of the DNS which demand using names that are derived from MD5 hashes of strings... -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 16 12:21:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12664 for ; Fri, 16 Jul 2004 12:21:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlVQo-000EDM-DU for namedroppers-data@psg.com; Fri, 16 Jul 2004 16:19:30 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlVQl-000ECz-0n for namedroppers@ops.ietf.org; Fri, 16 Jul 2004 16:19:27 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BlVQk-00052d-00 for ; Fri, 16 Jul 2004 18:19:26 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Jul 2004 18:19:26 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Jul 2004 18:19:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: NSEC+ and NO Date: Fri, 16 Jul 2004 18:19:18 +0200 Lines: 40 Message-ID: References: <22801.1089992982@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:/qXx26uxN2Y7vbhtyriGGOZYDek= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Reid writes: >>>>>> "Ben" == Ben Laurie writes: > > Ben> I make it 4d99aa84d5d72b1b57e56a5b186a0c64.co.uk. (or > Ben> 873bcdba87401b485022b8dcd4190e3e.co.uk. if the more correct > Ben> "amazon.co.uk." is the string). > > >> Now, what if I have already registered that name and even gone > >> as far as trademarking it. what happens ? > > Ben> Nothing - that name only appears in NSEC2 records - it would > Ben> not be a trademark infringement for it to do so. > > Suppose I've just incorporated 873bcdba87401b485022b8dcd4190e3e > Limited and registered that name as a trademark. Oh, and I want to > register my company's name in co.uk. See you in court. :-) One solution is to put NSECbis records in a separate namespace, e.g.: $ORIGIN co.uk. 873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSECbis 881345... ; for amazon.co.uk. This has other advantages: * There is no special parent/child behaviour for NSECbis that complicate resolvers. * (Speculative and unbaked:) You could delegate the _no zone to separate servers, which might have the computing capacity to perform online signing of NSECbis. Or purely for administrative purposes, to perhaps outsource the work of maintaining NSECbis to someone else. There are some synchronization issues that need to be studied here, though. I'm not sure what any obvious disadvantage would be. Regards, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 16 13:47:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18881 for ; Fri, 16 Jul 2004 13:47:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlWjc-000Ou3-Q8 for namedroppers-data@psg.com; Fri, 16 Jul 2004 17:43:00 +0000 Received: from [195.169.17.168] (helo=exchangefe.corporate.telin.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlWjb-000Otl-G6 for namedroppers@ops.ietf.org; Fri, 16 Jul 2004 17:42:59 +0000 Received: from [62.195.91.153] ([62.195.91.153]) by exchangefe.corporate.telin.nl with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Jul 2004 19:42:57 +0200 Message-ID: <40F813B4.9090004@dnss.ec> Date: Fri, 16 Jul 2004 19:43:16 +0200 From: Roy Arends User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie CC: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 References: <40F7F935.7050204@algroup.co.uk> In-Reply-To: <40F7F935.7050204@algroup.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2004 17:42:57.0889 (UTC) FILETIME=[54E84D10:01C46B5C] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,RCVD_IN_SBL, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben Laurie wrote: > Roy Arends wrote: > >> This document describes the DNSNR Resource Record (RR) for the >> Non-Repudiation (NR) of Existence service in the context of the DNS >> Security Extensions (DNSSEC). The DNSNR is an alternative to NSEC or >> "Authenticated Denial of Existence" Resource Records. > > > I would argue against the use of the term "non-repudiation" in any case > (for detailed reasons, see http://www.apache-ssl.org/tech-legal.pdf) but > in this particular case, regardless of its lack of merit, it has the > opposite meaning to that intended - that is, you are trying to repudiate > existence. As I understand, non-repudiation is a property achieved through cryptographic methods which prevents denying having performed an action related to the data. The DNSNR record prevents denying of having performed signing a record set. This specific property is used for proving existence and absence. > In 2.1.5 you say "The Type bit for the DNSNR and RRSIG MUST be set > during generation, and MUST be ignored during processing." - I don't see > why? Oh, thats the ol' silly state discussion. The first MUST follows from the fact that both record exist for a name, and must therefore be set in the DNSNR. The second MUST is to prevent future abuse when some idiot comes up with the idea of redefining interpretation of these specific bits. > 3.2.2 says "The probability of finding a second preimage is 1 in 2^160 > for SHA-1 on average." - it would be more proper to say "the probability > of a random string being a second preimage is 1 in 2^160..." (I can make > the probability of _finding_ one as close to 1 as I like, by searching > for longer). Yeah, but not on average ;-) I'll rewrite that part as per your suggestion. Thanks ! > Also, you have not dealt with wildcards at all. If there is special processing due to wildcards that is different from NSEC, I'll put it in. I haven't found one though. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 16 14:00:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19767 for ; Fri, 16 Jul 2004 14:00:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlWxs-00010E-8d for namedroppers-data@psg.com; Fri, 16 Jul 2004 17:57:44 +0000 Received: from [195.169.17.168] (helo=exchangefe.corporate.telin.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlWxr-0000zy-C9 for namedroppers@ops.ietf.org; Fri, 16 Jul 2004 17:57:43 +0000 Received: from [62.195.91.153] ([62.195.91.153]) by exchangefe.corporate.telin.nl with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Jul 2004 19:57:42 +0200 Message-ID: <40F81729.5040203@dnss.ec> Date: Fri, 16 Jul 2004 19:58:01 +0200 From: Roy Arends User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Reid CC: Ben Laurie , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundss?= =?ISO-8859-1?Q?on?= , namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO References: <22801.1089992982@gromit.rfc1035.com> In-Reply-To: <22801.1089992982@gromit.rfc1035.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2004 17:57:42.0875 (UTC) FILETIME=[646672B0:01C46B5E] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim Reid wrote: >>>>>>"Ben" == Ben Laurie writes: > > > Ben> I make it 4d99aa84d5d72b1b57e56a5b186a0c64.co.uk. (or > Ben> 873bcdba87401b485022b8dcd4190e3e.co.uk. if the more correct > Ben> "amazon.co.uk." is the string). > > >> Now, what if I have already registered that name and even gone > >> as far as trademarking it. what happens ? > > Ben> Nothing - that name only appears in NSEC2 records - it would > Ben> not be a trademark infringement for it to do so. > > Suppose I've just incorporated 873bcdba87401b485022b8dcd4190e3e > Limited and registered that name as a trademark. Oh, and I want to > register my company's name in co.uk. See you in court. :-) 873bcdba87401b485022b8dcd4190e3e NS 873bcdba87401b485022b8dcd4190e3e NSEC2 They're unrelated. There is no problem. The NS record has a different NSEC2 associated with it. The NSEC2 is associated with a different owner name. It is highly unlikely both would appear in a single response (nee AXFR). Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 16 14:30:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22034 for ; Fri, 16 Jul 2004 14:30:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlXQa-00054k-2I for namedroppers-data@psg.com; Fri, 16 Jul 2004 18:27:24 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlXQY-00053x-PI for namedroppers@ops.ietf.org; Fri, 16 Jul 2004 18:27:23 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i6GIRHqJ022954; Fri, 16 Jul 2004 19:27:17 +0100 (BST) To: Roy Arends cc: Ben Laurie , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundss?= =?ISO-8859-1?Q?on?= , namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Message from Roy Arends of "Fri, 16 Jul 2004 19:58:01 +0200." <40F81729.5040203@dnss.ec> Date: Fri, 16 Jul 2004 19:27:17 +0100 Message-ID: <22952.1090002437@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Roy" == Roy Arends writes: Roy> 873bcdba87401b485022b8dcd4190e3e NS Roy> 873bcdba87401b485022b8dcd4190e3e NSEC2 Roy> They're unrelated. There is no problem. The NS record has a Roy> different NSEC2 associated with it. The NSEC2 is associated Roy> with a different owner name. So what? These two records have the same owner-name. Given that one of the records is for a delegation, this has to mean complications for the already far too ugly semantics of a zone cut. Especially wrt backwards compatibility with the installed base. For example, what happens on an ANY query for 873bcdba87401b485022b8dcd4190e3e.co.uk? Will it stop at the NSEC2 in the parent or follow the delegation? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 16 15:41:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27887 for ; Fri, 16 Jul 2004 15:41:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlYWU-000EDZ-Mq for namedroppers-data@psg.com; Fri, 16 Jul 2004 19:37:34 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlYWL-000ECi-I4 for namedroppers@ops.ietf.org; Fri, 16 Jul 2004 19:37:25 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id i6GJbIO7027696; Fri, 16 Jul 2004 12:37:18 -0700 Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <3Y80BF4Q>; Fri, 16 Jul 2004 12:37:17 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Ben Laurie'" , Jim Reid Cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: RE: NSEC+ and NO Date: Fri, 16 Jul 2004 12:37:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Since this is only going to be verifiable via applications that know the semantics it cannot be beyond our abilities to fix this. A prefixing scheme should be fine. Each time we go to fix this record there is a huge amount of pushback trying to minimize the extent of the fix and then someone finds that the fix is insufficient for their real world requirements and then we have another 18 month delay while something else is built and so on. And in the process the spec gets ever more complex because it is no longer sufficient to solve the problem, the solution has to avoid treading on the previous attempts now found to be insufficient. I think it is entirely possible to build something here that meets all the stated requirements and have done with the issue for good. Can't we try that route for once and build something=20 that might appear to some slightly more complex than required or allowing deployments to be slightly less secure than some think is the perfect solution? There are a bunch of proposals in the offing to use the DNS as a protocol policy distribution mechanism. MARID and the proposed MASS being only the first of that type. These are going to create a requirement for DNS security that could be the killer app. I have interests in the policy publication mechanism, I don't care how DNS security happens, only that it does happen and it has sufficient buy in and support from the operators and be available in circa 4Q2005 which is when I expect the bad guys to find it worthwhile to perform DNS content attacks. If DNSSEC meets these criteria I'll be happy to use it but not otherwise. > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Ben Laurie > Sent: Friday, July 16, 2004 11:54 AM > To: Jim Reid > Cc: =D3lafur Gu=F0mundsson; namedroppers@ops.ietf.org > Subject: Re: NSEC+ and NO >=20 >=20 > Jim Reid wrote: >=20 > >>>>>>"Ben" =3D=3D Ben Laurie writes: > >=20 > >=20 > > Ben> I make it 4d99aa84d5d72b1b57e56a5b186a0c64.co.uk. (or > > Ben> 873bcdba87401b485022b8dcd4190e3e.co.uk. if the more = correct > > Ben> "amazon.co.uk." is the string). > >=20 > > >> Now, what if I have already registered that name and=20 > even gone > > >> as far as trademarking it. what happens ? > >=20 > > Ben> Nothing - that name only appears in NSEC2 records=20 > - it would > > Ben> not be a trademark infringement for it to do so. > >=20 > > Suppose I've just incorporated 873bcdba87401b485022b8dcd4190e3e > > Limited and registered that name as a trademark. Oh, and I want to > > register my company's name in co.uk. See you in court. :-) >=20 > Sure, but I'm pretty damn sure you'd lose. If you really want=20 > to waste a=20 > lawyer's time on this red herring, I'm sure I can get an opinion. >=20 > Cheers, >=20 > Ben. >=20 > --=20 > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ >=20 > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff >=20 > -- > to unsubscribe send a message to=20 > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 19 04:02:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22658 for ; Mon, 19 Jul 2004 04:02:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmT1K-000Il2-9y for namedroppers-data@psg.com; Mon, 19 Jul 2004 07:57:10 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmT1J-000Ikm-AZ for namedroppers@ops.ietf.org; Mon, 19 Jul 2004 07:57:09 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id BC8E04E3C7; Mon, 19 Jul 2004 09:57:08 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 692724EDB8; Mon, 19 Jul 2004 09:57:08 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i6J7v84c026858; Mon, 19 Jul 2004 09:57:08 +0200 Date: Mon, 19 Jul 2004 09:57:08 +0200 From: "Olaf M. Kolkman" To: Jim Reid Cc: roy@dnss.ec, ben@algroup.co.uk, ogud@ogud.com, namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO Message-Id: <20040719095708.17469f6e.olaf@ripe.net> In-Reply-To: <22952.1090002437@gromit.rfc1035.com> References: <40F81729.5040203@dnss.ec> <22952.1090002437@gromit.rfc1035.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 2ff5849b0a3860dede164665355349cf X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jim(*) If trademark issues form a requirement than please contact Ben and Rip. (see: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01237.html) -- Olaf (*) just because Jim brought this up, the message is off course intended for a broader audience: Bring your implicit and explicit requirements and non-requirements to Ben and Rip. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 19 09:49:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16919 for ; Mon, 19 Jul 2004 09:49:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmYRJ-000Fs8-M5 for namedroppers-data@psg.com; Mon, 19 Jul 2004 13:44:21 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmYRI-000Frp-Au for namedroppers@ops.ietf.org; Mon, 19 Jul 2004 13:44:20 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id E3C3F1078C9; Mon, 19 Jul 2004 13:44:18 +0000 (GMT) Message-ID: <40FBD032.3080504@algroup.co.uk> Date: Mon, 19 Jul 2004 14:44:18 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 References: <40F7F935.7050204@algroup.co.uk> <40F813B4.9090004@dnss.ec> In-Reply-To: <40F813B4.9090004@dnss.ec> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > Ben Laurie wrote: > >> Roy Arends wrote: >> >>> This document describes the DNSNR Resource Record (RR) for the >>> Non-Repudiation (NR) of Existence service in the context of the DNS >>> Security Extensions (DNSSEC). The DNSNR is an alternative to NSEC or >>> "Authenticated Denial of Existence" Resource Records. >> >> I would argue against the use of the term "non-repudiation" in any >> case (for detailed reasons, see >> http://www.apache-ssl.org/tech-legal.pdf) but in this particular case, >> regardless of its lack of merit, it has the opposite meaning to that >> intended - that is, you are trying to repudiate existence. > > As I understand, non-repudiation is a property achieved through > cryptographic methods which prevents denying having performed an action > related to the data. > > The DNSNR record prevents denying of having performed signing a record > set. I cannot see how it achieves this. Specifically, I can trivially have a DNSNR record without ever having signed any record sets at all (except the DNSNR record, of course). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 19 10:17:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19853 for ; Mon, 19 Jul 2004 10:17:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmYtv-000KV8-5u for namedroppers-data@psg.com; Mon, 19 Jul 2004 14:13:55 +0000 Received: from [195.169.17.168] (helo=exchangefe.corporate.telin.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmYtr-000KUj-QN for namedroppers@ops.ietf.org; Mon, 19 Jul 2004 14:13:51 +0000 Received: from mobile666 ([195.169.15.151]) by exchangefe.corporate.telin.nl with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Jul 2004 16:13:50 +0200 Message-ID: <007f01c46d9a$a0451690$970fa9c3@mobile666> From: "Roy Arends" To: "Ben Laurie" Cc: References: <40F7F935.7050204@algroup.co.uk> <40F813B4.9090004@dnss.ec> <40FBD032.3080504@algroup.co.uk> Subject: Re: draft-arends-dnsnr-00 Date: Mon, 19 Jul 2004 16:13:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 19 Jul 2004 14:13:50.0401 (UTC) FILETIME=[9D42D310:01C46D9A] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Ben Laurie" To: "Roy Arends" Cc: Sent: Monday, July 19, 2004 3:44 PM Subject: Re: draft-arends-dnsnr-00 > Roy Arends wrote: > > > Ben Laurie wrote: > > > >> Roy Arends wrote: > >> > >>> This document describes the DNSNR Resource Record (RR) for the > >>> Non-Repudiation (NR) of Existence service in the context of the DNS > >>> Security Extensions (DNSSEC). The DNSNR is an alternative to NSEC or > >>> "Authenticated Denial of Existence" Resource Records. > >> > >> I would argue against the use of the term "non-repudiation" in any > >> case (for detailed reasons, see > >> http://www.apache-ssl.org/tech-legal.pdf) but in this particular case, > >> regardless of its lack of merit, it has the opposite meaning to that > >> intended - that is, you are trying to repudiate existence. > > > > As I understand, non-repudiation is a property achieved through > > cryptographic methods which prevents denying having performed an action > > related to the data. > > > > The DNSNR record prevents denying of having performed signing a record > > set. > > I cannot see how it achieves this. Specifically, I can trivially have a > DNSNR record without ever having signed any record sets at all (except > the DNSNR record, of course). If you would have signed a record set, the DNSNR prevents you denying having signed that record set. If you would not have signed a record set, the DNSNR prevents you claiming that you did. That is non-repudiation for DNS. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 19 15:28:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18432 for ; Mon, 19 Jul 2004 15:28:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bmdgh-000D58-UU for namedroppers-data@psg.com; Mon, 19 Jul 2004 19:20:35 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bmdgg-000D4Z-E7 for namedroppers@ops.ietf.org; Mon, 19 Jul 2004 19:20:34 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18023; Mon, 19 Jul 2004 15:20:31 -0400 (EDT) Message-Id: <200407191920.PAA18023@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-protocol-07.txt Date: Mon, 19 Jul 2004 15:20:31 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Protocol Modifications for the DNS Security Extensions Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-protocol-07.txt Pages : 57 Date : 2004-7-19 This document is part of a family of documents which describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-protocol-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-19152202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-protocol-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-19152202.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 19 16:17:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18433 for ; Mon, 19 Jul 2004 15:28:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bmdga-000D3A-Gv for namedroppers-data@psg.com; Mon, 19 Jul 2004 19:20:28 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmdgZ-000D2e-Bz for namedroppers@ops.ietf.org; Mon, 19 Jul 2004 19:20:27 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18010; Mon, 19 Jul 2004 15:20:24 -0400 (EDT) Message-Id: <200407191920.PAA18010@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-11.txt Date: Mon, 19 Jul 2004 15:20:24 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Introduction and Requirements Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-intro-11.txt Pages : 26 Date : 2004-7-19 The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions, and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the group of documents that collectively describe DNSSEC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-intro-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-19152157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-19152157.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 19 16:17:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18434 for ; Mon, 19 Jul 2004 15:28:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmdhD-000DCr-P5 for namedroppers-data@psg.com; Mon, 19 Jul 2004 19:21:07 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmdhC-000DCU-Nm for namedroppers@ops.ietf.org; Mon, 19 Jul 2004 19:21:07 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18050; Mon, 19 Jul 2004 15:21:04 -0400 (EDT) Message-Id: <200407191921.PAA18050@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-records-09.txt Date: Mon, 19 Jul 2004 15:21:03 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Resource Records for the DNS Security Extensions Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-records-09.txt Pages : 33 Date : 2004-7-19 This document is part of a family of documents that describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-records-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-19152215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-19152215.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 20 03:55:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27725 for ; Tue, 20 Jul 2004 03:55:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmpO1-000B5K-K1 for namedroppers-data@psg.com; Tue, 20 Jul 2004 07:50:05 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmpNy-000B2F-7p for namedroppers@ops.ietf.org; Tue, 20 Jul 2004 07:50:02 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 4990C4E264; Tue, 20 Jul 2004 09:50:01 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8D5334E13B; Tue, 20 Jul 2004 09:50:00 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i6K7o04c003311; Tue, 20 Jul 2004 09:50:00 +0200 Date: Tue, 20 Jul 2004 09:50:00 +0200 From: "Olaf M. Kolkman" To: Thomas Narten , Margaret Wasserman Cc: iesg-secretary@ietf.org, namedroppers@ops.ietf.org Subject: Advance: DNSSECbis document set Message-Id: <20040720095000.45135cf3.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.018731 / 0.0 / 0.0 / disabled X-RIPE-Signature: 91c5806b7259a5b8c4c98f086a9a0c2b X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Thomas and Margaret, This is a request to advance draft-ietf-dnsext-dnssec-intro-11, draft-ietf-dnsext-dnssec-proto-07, and draft-ietf-dnsext-dnssec-records-09 to proposed standard. Below follows the filled in questionair from http://www.mip4.org/2004/draft-writeup-items.html (version 0.3) 1. Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? Yes. 2. Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? The document set has seen a few review cycles, there where also a number of workshops in which implementations of the specs where tested. We had comments from people that were present at those workshops but also comments by people that reviewed the document during last call and not earlier. In other words, various eyes had various looks under different circumstances. 3. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. The document-set is founded on RFC2535 and a number of modifications introduced by later RFCs those modifications have all been approved and published as standard track documents. The document set intends to be a compilation and a clarification on earlier work. 4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. During the development of the DNSSECbis specs (as this document set is refered to) several modifications to the RFC2535 specs were proposed. Some of them made it to RFC (e.g. 3755 and 3757) and some of them where rejected by the working group. The rejection of the so called "opt-in" modification caused heated debate. This debate concluded more than a year ago. Given that the pro- and opponents of "opt-in" have constructivly participated in the further development and conclussion of the DNSSECbis specs we conclude that the WG has moved on. During the last call it was made explicit that the possibility that zone enumeration is possible through a so called "NSEC" walk would be prohibitive for deployment of DNSSEC in some CC-TLD zones. The zone-enumeration has been a well known feature, documented in the security section since the first versions of the document set. While this problem was sometimes brought up, providing privacy was an explicit non-goal. The WG decided not to fix this problem but assessed that further development of DNSSEC to cope with the issue is possible within the current specification. The WG is in the process of formulating requirements for this future work, it is on the IETF 60 agenda. There is broad consensus that this is the appropriate way forward. 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? We believe that there is broad consensus for for forwarding the document set. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No. See 4 above, which started with a demonstration of discontent with the NSEC-walk issue. We feel the issue brought to closer with the WG members content. 7. Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes (We checked against http://www.ietf.org/ID-Checklist.html, that is what we are being redirected to). 8. Does the document a) split references into normative/informative, and b) are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (Note: the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) All reference sections are split. For each document in the DNSSECbis document set the only IDs in the normative references are other documents in the DNSSECbis document set. e.g. The only IDs in the normative reference set for intro are: I-D.ietf-dnsext-dnssec-protocol and I-D.ietf-dnsext-dnssec-records 9. For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: * Technical Summary * Working Group Summary * Protocol Quality Please provide such a writeup. (We will hopefully use it as is, but may make some changes.) For recent examples, have a look at the "protocol action" announcements for approved documents. Note: * When doing the technical summary, one would expect that the relevant information is in the abstract and/or introduction of the document. It turns out that the step of producing the writeup sometimes points out deficiencies in the introduction/abstract that are also worthy of rectifying. * For the Working Group Summary, was there anything in WG process that is worth noting? (E.g., controversy about particular points, decisions where concensus was particularly rough, etc.) * For the protocol quality, useful information could include: o is the protocol already being implemented? o have a significant number of vendors indicated they plan to implement the spec? o are there any reviewers (during the end stages) that merit explicit mention as having done a thorough review that resulted in important changes or a conclusion that the document was fine (except for maybe some nits?) [ Below is a technical summary that can be used with all 3 documents. Please let me know if you want to have this split.] Technical Summary This document is part of a family of documents that describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. The document series consists out of 3 documents: + DNS Security Introduction and Requirements ([dnssec-intro]) + Protocol Modifications for the DNS Security Extensions ([dnssec-proto]) + Resource Records for the DNS Security Extensions ([dnssec-records]) [dnssec-intro] introduces the DNS security extensions, and describes their capabilities and limitations. [dnssec-intro] also discusses the services that the DNS security extensions do and do not provide. [dnssec-intro] describes the interrelationships between the group of documents that collectively describe DNSSEC. [dnssec-proto] describes the DNSSEC protocol modifications. [dnssec-proto] defines the concept of a signed zone, along with the requirements for serving and resolving using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. [dnssec-records] defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. Working Group Summary There was consensus within the working group to publish the document as Proposed Standard. Protocol Quality The following quote from draft-ietf-dnsext-dnssec-intro-11.txt is relevant: "The specification in the DNSSEC document set defines the behavior for zone signers and security-aware name servers and resolvers in such a way that the validating entities can unambiguously determine the state of the data. (...) A method for signaling advanced error codes and policy between a security aware stub resolver and security aware recursive nameservers is a topic for future work, as is the interface between a security aware resolver and the applications that use it. Note, however, that the lack of the specification of such communication does not prohibit deployment of signed zones or the deployment of security aware recursive name servers that prohibit propagation of bogus data to the applications." (end quote) Various parts of the specification have been implemented. There are (at least) 2 signer implementations There are (at least) 2 authoritative server implementations There is (at least) 1 verifying recursive nameserver (hence a verifying resolver) implementation. There are various troubleshooting tools that have partial or full verification capabilities. These implementations have been used in several workshops and have been found to inter-operate. -- Olaf Kolkman Olafur Gudmundsson DNSEXT Chairs -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 20 15:47:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21108 for ; Tue, 20 Jul 2004 15:47:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bn0St-000MXa-Jy for namedroppers-data@psg.com; Tue, 20 Jul 2004 19:39:51 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bn0Ss-000MX4-FU for namedroppers@ops.ietf.org; Tue, 20 Jul 2004 19:39:50 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20341; Tue, 20 Jul 2004 15:39:47 -0400 (EDT) Message-Id: <200407201939.PAA20341@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-insensitive-04.txt Date: Tue, 20 Jul 2004 15:39:47 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) Case Insensitivity Clarification Author(s) : D. Eastlake Filename : draft-ietf-dnsext-insensitive-04.txt Pages : 11 Date : 2004-7-20 Domain Name System (DNS) names are 'case insensitive'. This document explains exactly what that means and provides a clear specification of the rules. This clarification should not have any interoperability consequences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-insensitive-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-insensitive-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20155234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-insensitive-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-insensitive-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155234.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 20 15:47:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21130 for ; Tue, 20 Jul 2004 15:47:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bn0Sk-000MUf-TU for namedroppers-data@psg.com; Tue, 20 Jul 2004 19:39:42 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bn0Sj-000MUE-I0 for namedroppers@ops.ietf.org; Tue, 20 Jul 2004 19:39:42 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20319; Tue, 20 Jul 2004 15:39:37 -0400 (EDT) Message-Id: <200407201939.PAA20319@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dhcid-rr-08.txt Date: Tue, 20 Jul 2004 15:39:37 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A DNS RR for encoding DHCP information (DHCID RR) Author(s) : M. Stapp, et al. Filename : draft-ietf-dnsext-dhcid-rr-08.txt Pages : 10 Date : 2004-7-20 It is possible for multiple DHCP clients to attempt to update the same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, 'Resolution of DNS Name Conflicts'[1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the 'DHCID' RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dhcid-rr-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20155228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155228.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 20 15:49:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21248 for ; Tue, 20 Jul 2004 15:49:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bn0TI-000MbS-Af for namedroppers-data@psg.com; Tue, 20 Jul 2004 19:40:16 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bn0TF-000Mau-7z for namedroppers@ops.ietf.org; Tue, 20 Jul 2004 19:40:13 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20428; Tue, 20 Jul 2004 15:40:10 -0400 (EDT) Message-Id: <200407201940.PAA20428@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-33.txt Date: Tue, 20 Jul 2004 15:40:10 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-33.txt Pages : 26 Date : 2004-7-20 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-33.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-33.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-33.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20155240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-33.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-33.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155240.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 20 16:38:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29257 for ; Tue, 20 Jul 2004 16:38:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bn1KX-0003oH-38 for namedroppers-data@psg.com; Tue, 20 Jul 2004 20:35:17 +0000 Received: from [63.161.60.61] (helo=mail25-res-R.bigfish.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bn1KU-0003nt-PC for namedroppers@ops.ietf.org; Tue, 20 Jul 2004 20:35:15 +0000 Received: from mail25-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail25-res-R.bigfish.com (Postfix) with ESMTP id 10FC42B793B; Tue, 20 Jul 2004 20:35:14 +0000 (UCT) Received: by mail25-res (MessageSwitch) id 1090355713830919_8887; Tue, 20 Jul 2004 20:35:13 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail25-res.bigfish.com (Postfix) with ESMTP id AAEDB2B6F86; Tue, 20 Jul 2004 20:35:13 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id i6KKZDXS021465; Tue, 20 Jul 2004 15:35:13 -0500 (CDT) Received: from PDAWG01A.corp.sprint.com (PDAWG01A.corp.sprint.com [10.184.134.78]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6KKZDG11597; Tue, 20 Jul 2004 15:35:13 -0500 (CDT) Received: from mail pickup service by PDAWG01A.corp.sprint.com with Microsoft SMTPSVC; Tue, 20 Jul 2004 15:35:11 -0500 Received: from mailhost.sprintspectrum.com ([207.40.65.55]) by PDAWG01A.corp.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jul 2004 15:31:01 -0500 Received: from PKDWG02A.ad.sprint.com (PKDWG02A.corp.sprint.com [10.185.12.80]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6KKV1T13851 for ; Tue, 20 Jul 2004 15:31:01 -0500 (CDT) Received: from mailhost.sprintspectrum.com ([207.40.65.56]) by PKDWG02A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jul 2004 15:31:00 -0500 Received: from PDAWG01A.corp.sprint.com (PDAWG01A.corp.sprint.com [10.184.134.78]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6KKV0G05844 for ; Tue, 20 Jul 2004 15:31:00 -0500 (CDT) Received: from mailhost.sprintspectrum.com ([207.40.65.55]) by PDAWG01A.corp.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jul 2004 15:30:52 -0500 Received: from PDAWG01A.corp.sprint.com (PDAWG01A.corp.sprint.com [10.184.134.78]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6KKUqT13648 for ; Tue, 20 Jul 2004 15:30:52 -0500 (CDT) Received: from mailhost.sprintspectrum.com ([207.40.65.55]) by PDAWG01A.corp.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jul 2004 15:30:40 -0500 Received: from PKDWG02A.ad.sprint.com (PKDWG02A.corp.sprint.com [10.185.12.80]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6KKUeT13396 for ; Tue, 20 Jul 2004 15:30:40 -0500 (CDT) Received: from mailhost.sprintspectrum.com ([207.40.65.56]) by PKDWG02A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jul 2004 15:29:37 -0500 Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6KKTbG04675 for ; Tue, 20 Jul 2004 15:29:37 -0500 (CDT) Received: from mail38-red-R.bigfish.com (mail-red.bigfish.com [216.148.222.61]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id i6KKTVA6017770 for ; Tue, 20 Jul 2004 15:29:36 -0500 (CDT) Received: from mail38-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail38-red-R.bigfish.com (Postfix) with ESMTP id 7ABCC2D379D for ; Tue, 20 Jul 2004 20:29:31 +0000 (UCT) Received: by mail38-red (MessageSwitch) id 1090355354129404_31918; Tue, 20 Jul 2004 20:29:14 +0000 (UCT) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mail38-red.bigfish.com (Postfix) with ESMTP id 665D52D32FE; Tue, 20 Jul 2004 20:29:02 +0000 (UCT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0dw-0008Pq-NV; Tue, 20 Jul 2004 15:51:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0TE-0006gA-GF for i-d-announce@megatron.ietf.org; Tue, 20 Jul 2004 15:40:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20428; Tue, 20 Jul 2004 15:40:10 -0400 (EDT) Message-Id: <200407201940.PAA20428@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Jul 2004 15:40:10 -0400 Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-33.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-BigFish: vpcs-201(z519i60eHz11e3IQdf8W11f4R14c3P13bfM122eH200bnz7R6ILzzzd6eJP1033ILz1IQ2IV) X-OriginalArrivalTime: 20 Jul 2004 20:29:37.0347 (UTC) FILETIME=[46B38130:01C46E98] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-33.txt Pages : 26 Date : 2004-7-20 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-33.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-33.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-33.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20155240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-33.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-33.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155240.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From nv33135@yahoo.com Wed Jul 21 01:36:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20099; Wed, 21 Jul 2004 01:36:10 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn9mH-0004vk-Bb; Wed, 21 Jul 2004 01:36:29 -0400 Received: from [218.12.34.234] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1Bn9ll-0000SI-FS; Wed, 21 Jul 2004 01:36:04 -0400 From: "Atualidade Brasileira:" To: dnsext-archive@ietf.org Subject: A esmola, "políticamente incorreta"? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Wed, 21 Jul 2004 01:36:04 -0400 X-Spam-Score: 24.7 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024

EnCastellano - LinkToFreeTranslator

Bom dia, amigos! A esmola, é humilhante ou indigna? Um tema sem dúvida polêmico, abordado por Adolpho Lindenberg. Para enviar sua valiosa opinião, ou simplesmente seu voto eletrônico, veja os links no final. Boa leitura, e bom debate! Atenciosamente, Sergio Lopes, ConstruNews.

Série Temas Patrulhados (9)

Intervencionismo estatal e fermentação revolucionária versus assistência particular e personalizada

Como podemos aceitar que a palavra "esmola" tenha se transformado em algo humilhante, indigno, praticamente excluído do debate em torno da assistência social?, pergunta Lindenberg

Clientelismo e ineficiência

* Os atuais programas governamentais de assistência social são burocráticos, clientelistas, politizados, demagógicos e ineficientes, ao contrário da assistência social cristã que é dignificante, personalizada, afável, caridosa, e, aliás, de acordo com o autêntico espírito brasileiro, afirma Adolpho Lindenberg em recente e "políticamente incorreto" artigo da Série Temas Patrulhados.

Fermentação temperamental agressiva

* O articulista acrescenta que o quadro de um Estado intervencionista e ineficiente se vê agravado pela fermentação revolucionária de agitadores, muitas vezes da "esquerda católica", que criam um clima temperamental de inconformidade agressiva, sempre propondo soluções que significam uma maior intervenção estatal.

Na esmola, duas belas atitudes

* Causa espanto a posição de tantos católicos quando bradam que "o pobre não precisa de esmolas, mas de justiça", constata Lindenberg, que responde: precisa de justiça, sim, mas precisa também de esmolas. Como nós, católicos, podemos aceitar que a palavra "esmola", e com ela a realidade que expressa, tenha se transformado em algo humilhante, indigno, praticamente excluído do debate em torno da assistência social?

Esmola material e esmola moral

* E não existe apenas a esmola material: há a esmola moral, o conselho, o afeto e o amparo dados por puro amor ao próximo, sem nenhuma retribuição e dirigidos tantas vezes a milionários angustiados e abatidos pelos revezes da vida.

Dar e receber esmolas, gestos que participam da vida divina

* A partir da difusão do Evangelho, progressivamente, os miseráveis, abandonados e carentes de toda espécie de bens, foram elevados, na consideração pública, à situação de irmãos d'Aquele que é a razão de nossas vidas e modelo de todas as virtudes. Dar e receber esmolas, tornaram-se, desde então, gestos que participam, num certo sentido, da vida divina.

Texto completo, gratuito, do artigo

* Para receber gratuitamente, por e-mail, o texto completo do artigo "Intervencionismo estatal e fermentação revolucionária versus assistência particular e personalizada" clique no seguinte link:

EsteArtigoCompletoGratuitamente

"Patrulhamento"

* Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza, "patrulha" ou encobre com um manto de silêncio as opiniões "politicamente incorretas", não afinadas com as ideologias de esquerda.

Links de opinião:

Gostaríamos muito de receber seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, conhecer sua valiosa opinião (seguem 10 opções):

* Lindenberg:Discrepo - OpiniãoReacionária - OpiniãoMuitoReacionáriaMesmo

* Lindenberg:Concordo - OpiniãoDeBomSenso - VerdadePoliticamenteIncorreta

* Lindenberg:EmTermos - OpiniãoUmPoucoReacionária - PrecisariaPensar

* Lindenberg:OutraOpinião (favor acrescentar um comentário, se achar conveniente)

Links gratuitos (e-Book e outros artigos):

EsteArtigoCompletoGratuitamente

E-BookGratuitoBr (em formato Word, com 11 artigos de Lindenberg)

Lindenberg:IntroduçãoGratuitaDoLivro (em formato Word, Introdução do livro "Os católicos e a economia de mercado")

ArtigosAnteriores - ProximosArtigos

Outros links:

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como adquirir o livro no Brasil)

RetirarDoAddressBook (para ser retirado imediatamente de nosso Address Book).

A difusão desta mensagem, com uma finalidade cultural e com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. Telefone de contato: (11) 9252 - 7873

 

 

 

From owner-namedroppers@ops.ietf.org Thu Jul 22 10:45:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26388 for ; Thu, 22 Jul 2004 10:45:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnejA-00017o-HV for namedroppers-data@psg.com; Thu, 22 Jul 2004 14:39:20 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bnej9-00017V-3z for namedroppers@ops.ietf.org; Thu, 22 Jul 2004 14:39:19 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 3657D1078D7; Thu, 22 Jul 2004 14:39:17 +0000 (GMT) Message-ID: <40FFD194.6070002@algroup.co.uk> Date: Thu, 22 Jul 2004 15:39:16 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 References: <40F7F935.7050204@algroup.co.uk> <40F813B4.9090004@dnss.ec> <40FBD032.3080504@algroup.co.uk> <007f01c46d9a$a0451690$970fa9c3@mobile666> In-Reply-To: <007f01c46d9a$a0451690$970fa9c3@mobile666> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > ----- Original Message ----- > From: "Ben Laurie" > To: "Roy Arends" > Cc: > Sent: Monday, July 19, 2004 3:44 PM > Subject: Re: draft-arends-dnsnr-00 > > > >>Roy Arends wrote: >> >> >>>Ben Laurie wrote: >>> >>> >>>>Roy Arends wrote: >>>> >>>> >>>>> This document describes the DNSNR Resource Record (RR) for the >>>>> Non-Repudiation (NR) of Existence service in the context of the DNS >>>>> Security Extensions (DNSSEC). The DNSNR is an alternative to NSEC > > or > >>>>> "Authenticated Denial of Existence" Resource Records. >>>> >>>>I would argue against the use of the term "non-repudiation" in any >>>>case (for detailed reasons, see >>>>http://www.apache-ssl.org/tech-legal.pdf) but in this particular case, >>>>regardless of its lack of merit, it has the opposite meaning to that >>>>intended - that is, you are trying to repudiate existence. >>> >>>As I understand, non-repudiation is a property achieved through >>>cryptographic methods which prevents denying having performed an action >>>related to the data. >>> >>>The DNSNR record prevents denying of having performed signing a record >>>set. >> >>I cannot see how it achieves this. Specifically, I can trivially have a >>DNSNR record without ever having signed any record sets at all (except >>the DNSNR record, of course). > > If you would have signed a record set, the DNSNR prevents you denying > having signed that record set. I don't see how - I could sign a DNSNR that denied the very record set I had actually signed. > If you would not have signed a record set, the DNSNR prevents you claiming > that you did. Again, I can sign the DNSNR without having signed the record set. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 22 10:52:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26748 for ; Thu, 22 Jul 2004 10:52:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bnet8-0002cz-CV for namedroppers-data@psg.com; Thu, 22 Jul 2004 14:49:38 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bnet7-0002ck-C1 for namedroppers@ops.ietf.org; Thu, 22 Jul 2004 14:49:37 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 943EBAC8B; Thu, 22 Jul 2004 16:49:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 92AE2AC8A; Thu, 22 Jul 2004 16:49:36 +0200 (CEST) Date: Thu, 22 Jul 2004 16:49:36 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: <40FFD194.6070002@algroup.co.uk> Message-ID: References: <40F7F935.7050204@algroup.co.uk> <40F813B4.9090004@dnss.ec> <40FBD032.3080504@algroup.co.uk> <007f01c46d9a$a0451690$970fa9c3@mobile666> <40FFD194.6070002@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 22 Jul 2004, Ben Laurie wrote: > Roy Arends wrote: > > > If you would have signed a record set, the DNSNR prevents you denying > > having signed that record set. > > I don't see how - I could sign a DNSNR that denied the very record set I > had actually signed. There are many ways of shooting yourself in the foot. The point is that someone can't shoot you in the foot. > > If you would not have signed a record set, the DNSNR prevents you claiming > > that you did. > > Again, I can sign the DNSNR without having signed the record set. Again, there are many ways of shooting yourself in the foot. If you would do so (I don't recommend it, this is an analogy and purely hypothetical), you are not complying with the DNSNR proposal. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 22 11:06:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27668 for ; Thu, 22 Jul 2004 11:06:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bnf76-0005GL-SD for namedroppers-data@psg.com; Thu, 22 Jul 2004 15:04:04 +0000 Received: from [149.8.64.10] (helo=mclmx.mail.saic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bnf75-0005G5-SO for namedroppers@ops.ietf.org; Thu, 22 Jul 2004 15:04:04 +0000 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Thu, 22 Jul 2004 11:03:47 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.6.45) with SMTP id M2004072211034727841 ; Thu, 22 Jul 2004 11:03:47 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <33RJ3K6F>; Thu, 22 Jul 2004 11:03:47 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE105208@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Roy Arends'" , Ben Laurie Cc: namedroppers@ops.ietf.org Subject: RE: draft-arends-dnsnr-00 Date: Thu, 22 Jul 2004 11:01:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy-- But as Ben said previously, >>>> I would argue against the use of the term "non-repudiation" >>>> in any case and although the examples he gives are unlikely and perhaps do correspond to shooting of appendages, they also (to me) show that a DNSNR does not provide non-repudiation for some possible (although unlikely) cases. Stating that someone is not complying with the DNSNR proposal does not mean that DNSNR provides a clear method, in the case of conflicting indicators, to prove in a way which cannot be repudiated that a record either was or was not signed. Wasn't that the point of this discussion? --Rip > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Roy Arends > Sent: Thursday, July 22, 2004 10:50 AM > To: Ben Laurie > Cc: namedroppers@ops.ietf.org > Subject: Re: draft-arends-dnsnr-00 > > > On Thu, 22 Jul 2004, Ben Laurie wrote: > > > Roy Arends wrote: > > > > > If you would have signed a record set, the DNSNR prevents > you denying > > > having signed that record set. > > > > I don't see how - I could sign a DNSNR that denied the very > record set I > > had actually signed. > > There are many ways of shooting yourself in the foot. The > point is that > someone can't shoot you in the foot. > > > > If you would not have signed a record set, the DNSNR > prevents you claiming > > > that you did. > > > > Again, I can sign the DNSNR without having signed the record set. > > Again, there are many ways of shooting yourself in the foot. > If you would > do so (I don't recommend it, this is an analogy and purely > hypothetical), > you are not complying with the DNSNR proposal. > > Roy > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 22 11:09:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28019 for ; Thu, 22 Jul 2004 11:09:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnfBM-00069Y-Mq for namedroppers-data@psg.com; Thu, 22 Jul 2004 15:08:28 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnfBL-000696-DT for namedroppers@ops.ietf.org; Thu, 22 Jul 2004 15:08:27 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 4981A1078DB; Thu, 22 Jul 2004 14:42:50 +0000 (GMT) Message-ID: <40FFD269.4030809@algroup.co.uk> Date: Thu, 22 Jul 2004 15:42:49 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Simon Josefsson Cc: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO References: <22801.1089992982@gromit.rfc1035.com> In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Simon Josefsson wrote: > Jim Reid writes: > > >>>>>>>"Ben" == Ben Laurie writes: >> >> Ben> I make it 4d99aa84d5d72b1b57e56a5b186a0c64.co.uk. (or >> Ben> 873bcdba87401b485022b8dcd4190e3e.co.uk. if the more correct >> Ben> "amazon.co.uk." is the string). >> >> >> Now, what if I have already registered that name and even gone >> >> as far as trademarking it. what happens ? >> >> Ben> Nothing - that name only appears in NSEC2 records - it would >> Ben> not be a trademark infringement for it to do so. >> >>Suppose I've just incorporated 873bcdba87401b485022b8dcd4190e3e >>Limited and registered that name as a trademark. Oh, and I want to >>register my company's name in co.uk. See you in court. :-) > > > One solution is to put NSECbis records in a separate namespace, e.g.: > > $ORIGIN co.uk. > 873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your delegation > 873bcdba87401b485022b8dcd4190e3e._no IN NSECbis 881345... ; for amazon.co.uk. > > This has other advantages: > > * There is no special parent/child behaviour for NSECbis that > complicate resolvers. > > * (Speculative and unbaked:) You could delegate the _no zone to > separate servers, which might have the computing capacity to > perform online signing of NSECbis. Or purely for administrative > purposes, to perhaps outsource the work of maintaining NSECbis to > someone else. There are some synchronization issues that need to > be studied here, though. > > I'm not sure what any obvious disadvantage would be. The only one I can think of is that it makes the name longer. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 22 11:21:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28727 for ; Thu, 22 Jul 2004 11:21:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnfLA-0007az-Qh for namedroppers-data@psg.com; Thu, 22 Jul 2004 15:18:36 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnfL9-0007ah-Hy for namedroppers@ops.ietf.org; Thu, 22 Jul 2004 15:18:35 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id C345EACF9; Thu, 22 Jul 2004 17:18:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id C20E7AC8D; Thu, 22 Jul 2004 17:18:34 +0200 (CEST) Date: Thu, 22 Jul 2004 17:18:34 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: "Loomis, Rip" Cc: Ben Laurie , namedroppers@ops.ietf.org Subject: RE: draft-arends-dnsnr-00 In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE105208@US-Columbia-CIST.mail.saic.com> Message-ID: References: <4E25ECBBC03F874CBAD03399254ADFDE105208@US-Columbia-CIST.mail.saic.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 22 Jul 2004, Loomis, Rip wrote: > Roy-- > But as Ben said previously, > >>>> I would argue against the use of the term "non-repudiation" > >>>> in any case > > and although the examples he gives are unlikely and perhaps > do correspond to shooting of appendages, they also (to me) > show that a DNSNR does not provide non-repudiation for some > possible (although unlikely) cases. The service offered with this method is a proof that a record exists, and in the context of DNSSEC: is signed. The 'action of signing' can not be repudiated. > Stating that someone is not complying with the DNSNR proposal does not > mean that DNSNR provides a clear method, in the case of conflicting > indicators, to prove in a way which cannot be repudiated that a record > either was or was not signed. That is true. Please help in clarifying the text so it complies with the service offered: authenticated denial. Or, at least suggest a different name. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 23 10:23:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27067 for ; Fri, 23 Jul 2004 10:23:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bo0ro-000Pgc-4r for namedroppers-data@psg.com; Fri, 23 Jul 2004 14:17:44 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bo0rn-000Pg2-3H for namedroppers@ops.ietf.org; Fri, 23 Jul 2004 14:17:43 +0000 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.12.11/8.12.11) with ESMTP id i6NEHcla066666 for ; Fri, 23 Jul 2004 10:17:39 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.0.6.2.20040723091320.02bdee68@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Fri, 23 Jul 2004 10:17:31 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSSEC implementation status ? Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.43 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable One of the agenda items at the WG meeting is to report on status/plans of DNSSECbis implementations. The purpose is to facilitate, collaboration and testing. I will be making the presentation, if you have any DNSSECbis related=20 implementation done or planning on one please send me an email about your work. Please use the following report format as a guideline: Name of effort: Reporter: Type: Servers: Authorative, Recursive Validating, End-resolver[1], Tools: Zone signer, Key Management[2], Trust Anchors[3], Other API: Exported or Internal Status: available, in testing, in development, in planning Documentation: Link: Other: [1] End-resolver is a resolver that does not answer queries on port 53 just issues them. (Similar functionality as nslookup and dig) [2] Key management refers to tools for zone operator to maintain and use keys. [3] Trust Anchors tools are tools that keep track of changes in KEYs at remote zones. Feel free to file as many reports as you like, I will summarize at the meeting. Most of the information I receive will be made public, unless you request otherwise. Thanks Olafur PS: Sample Report: Name: RB-TrustA Reporter: =D3lafur Gu=F0mundsson Type: Tool: Trust Anchor maintainer API: Exported Status: In development Documentation: Not yet Link: http://stora.ogud.com:/DNSSEC/RB-TrustA/ Other: Implements Revoke-bit semantics by periodically scanning trust anchors for changes, exports list of current Trust anchors. This list can be converted to configuration file segments for different Resolvers.=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 23 10:31:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27601 for ; Fri, 23 Jul 2004 10:31:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bo11r-00016a-8e for namedroppers-data@psg.com; Fri, 23 Jul 2004 14:28:07 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bo11p-00016H-ST for namedroppers@ops.ietf.org; Fri, 23 Jul 2004 14:28:06 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 5C1184FDBA; Fri, 23 Jul 2004 16:28:05 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id E98CA4FD9A; Fri, 23 Jul 2004 16:28:04 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i6NES4jR016650; Fri, 23 Jul 2004 16:28:04 +0200 Date: Fri, 23 Jul 2004 16:28:04 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Cc: agenda@ietf.org Subject: DNSSEXT draft agenda IETF 60 Message-Id: <20040723162804.0c3cb492.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000001 / 0.0 / 0.0 / disabled X-RIPE-Signature: fb9402aa57fc2acb0d9c2a915a75e41d X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Coleagues Here is an updated draft agenda, consider this the final draft. Note that we do probably not need 2.5 hours on thursday. We scheaduled in such a way that the room can be made available in case other groups need time. If I have made omissions, please let me know. --Olaf Kolkman DNSEXT co-chair. ------------------------------------------------------------ DRAFT DNSEXT Agenda IETF 60. We have two sessions. We try to get the DNSSEC work done in the firts session but may have to use the second session for continuation of the discussion. Monday Aug 2, 09:00-11:30 1st slot DNSSEC session - WG Administrivia (approx 10 min) + Session administration - Appointment Scribes - Agenda Bashing - Previous Minutes http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02219.html - Reid: DNS-MODA plug (approx 3 min, no discussion) - DNSSEC Deployment issues + Report on implementation + Key management topics (approx 60 minutes) - StJohns: draft-stjohns-dnssec-trustupdate-01 - Ihren: DNSSEC in-band key rollover (draft-kolkman-dnsext-dnssec-in-band-rollover-00) - Requirements for future work on Denial of Existence (approx 60 minutes) Loomis/Laurie: Requirements overview Possible transitions + draft-ietf-dnsext-dnssec-trans-00.txt Possible approaches + Arends: DNSNR draft-arends-dnsnr-00.txt + Laurie: NSEC2 http://www.links.org/dnssec/draft-laurie-dnsext-nsec2-00.txt - Wrapup (approx 10 minutes) This session is parallel to: APP apparea Applications Open Area Meeting INT dnsext DNS Extensions WG * IRTF mobopts IP Mobility Optimizations OPS multi6 Site Multihoming in IPv6 WG OPS hubmib Ethernet Interfaces and Hub MIB WG RTG manet Mobile Ad-hoc Networks WG SEC msec Multicast Security WG TSV xcon Centralized Conference WG -------------------- -------------------- -------------------- 2nd slot Thursday Aug 5, 9:00-10:15(!) Other DNSEXT extention work. - Schlyter: Report on RFC 3597 interoperability testing. http://www.rfc.se/interop3597 (approx 10 minutes) - Eastlake: draft-eastlake-tsig-sha-03.txt (approx 5 minutes) - Austein: draft-austein-dnsext-nsid-01.txt (approx 10 minutes) (Related to this work in DNSOP: draft-ietf-dnsop-serverid-02 ) - More WG Administrivia (approx 15 minutes) + Document Status + Charter Review - Open mike Possibly continuation of Monday morning discussions. This session is parallel to: APP atompub Atom Publishing Format and Protocol WG GEN newtrk New IETF Standards Track Discussion WG INT dnsext DNS Extensions WG * INT hip Host Identity Protocol WG RTG mpls Multi Protocol Label Switching WG SEC mass Message Authentication Signature Standards BOF SEC msec Multicast Security WG TSV tsvwg Transport Area Working Group ------------------------------------------------------------ $Id: agenda.txt,v 1.10 2004/07/23 14:23:59 olaf Exp $ ------------------------------------------------------------ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 23 13:06:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09457 for ; Fri, 23 Jul 2004 13:06:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bo3Ou-000PVF-LB for namedroppers-data@psg.com; Fri, 23 Jul 2004 17:00:04 +0000 Received: from [200.45.191.180] (helo=smtp-mx-02.ti.local) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bo3Os-000PUM-VQ for namedroppers@ops.ietf.org; Fri, 23 Jul 2004 17:00:03 +0000 Received: from mail pickup service by smtp-mx-02.ti.local with Microsoft SMTPSVC; Fri, 23 Jul 2004 13:59:43 -0300 Received: from qsmtp-mx-04.arnet.com.ar ([200.45.191.167]) by smtp-mx-02.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jul 2004 17:30:00 -0300 Received: (qmail 25062 invoked from network); 20 Jul 2004 20:27:28 -0000 Received: from unknown (HELO megatron.ietf.org) (132.151.6.71) by host191167.arnet.net.ar with SMTP; 20 Jul 2004 20:27:23 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0dx-0008Pq-E8; Tue, 20 Jul 2004 15:51:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0TE-0006gA-GF for i-d-announce@megatron.ietf.org; Tue, 20 Jul 2004 15:40:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20428; Tue, 20 Jul 2004 15:40:10 -0400 (EDT) Message-Id: <200407201940.PAA20428@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Jul 2004 15:40:10 -0400 Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-33.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-OriginalArrivalTime: 20 Jul 2004 20:30:00.0163 (UTC) FILETIME=[544CF330:01C46E98] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-33.txt Pages : 26 Date : 2004-7-20 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-33.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-33.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-33.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20155240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-33.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-33.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155240.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 23 13:19:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10109 for ; Fri, 23 Jul 2004 13:19:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bo3fX-0002eq-Cf for namedroppers-data@psg.com; Fri, 23 Jul 2004 17:17:15 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bo3fW-0002eU-5F for namedroppers@ops.ietf.org; Fri, 23 Jul 2004 17:17:14 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id A5EE610780D; Fri, 23 Jul 2004 17:17:12 +0000 (GMT) Message-ID: <41014817.4050904@algroup.co.uk> Date: Fri, 23 Jul 2004 18:17:11 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 References: <40F7F935.7050204@algroup.co.uk> <40F813B4.9090004@dnss.ec> <40FBD032.3080504@algroup.co.uk> <007f01c46d9a$a0451690$970fa9c3@mobile666> <40FFD194.6070002@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > On Thu, 22 Jul 2004, Ben Laurie wrote: > > >>Roy Arends wrote: >> >> >>>If you would have signed a record set, the DNSNR prevents you denying >>>having signed that record set. >> >>I don't see how - I could sign a DNSNR that denied the very record set I >>had actually signed. > > There are many ways of shooting yourself in the foot. The point is that > someone can't shoot you in the foot. Well, that's not what you said: "the DNSNR prevents you denying having signed that record set." If you want it to mean it prevents someone else denying it, I would argue even more strongly against the use of "non-repudiation" to describe this, since almost no-one would expect it to mean what you want it to mean! -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 23 19:27:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03866 for ; Fri, 23 Jul 2004 19:27:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bo9OH-000Aow-V3 for namedroppers-data@psg.com; Fri, 23 Jul 2004 23:23:49 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bo9OG-000AoP-IS for namedroppers@ops.ietf.org; Fri, 23 Jul 2004 23:23:48 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 500C0AC8B; Sat, 24 Jul 2004 01:23:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 35CD6AC8A; Sat, 24 Jul 2004 01:23:47 +0200 (CEST) Date: Sat, 24 Jul 2004 01:23:47 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: <41014817.4050904@algroup.co.uk> Message-ID: References: <40F7F935.7050204@algroup.co.uk> <40F813B4.9090004@dnss.ec> <40FBD032.3080504@algroup.co.uk> <007f01c46d9a$a0451690$970fa9c3@mobile666> <40FFD194.6070002@algroup.co.uk> <41014817.4050904@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 23 Jul 2004, Ben Laurie wrote: > Roy Arends wrote: > > > On Thu, 22 Jul 2004, Ben Laurie wrote: > > > > > >>Roy Arends wrote: > >> > >> > >>>If you would have signed a record set, the DNSNR prevents you denying > >>>having signed that record set. > >> > >>I don't see how - I could sign a DNSNR that denied the very record set I > >>had actually signed. > > > > There are many ways of shooting yourself in the foot. The point is that > > someone can't shoot you in the foot. > > Well, that's not what you said: "the DNSNR prevents you denying having > signed that record set." Ben. It is very simple: If _you_ state that _you_ signed record type AAAA and record type MX for a given name, while not actually signing record type AAAA and record type MX, that would be violating the spec. Just as you can write an implementation that publishes a CNAME and an A record type for a give name. Sure you can do it. But that would be violating the spec. > If you want it to mean it prevents someone else denying it, Not 'someone else', but anyone. > I would argue even more strongly against the use of "non-repudiation" to > describe this, since almost no-one would expect it to mean what you want > it to mean! That is arrogant. Let me ask you this, if you see a record type for Non Repudiation of existence of DNS data, what do you expect it to mean ? How is that different from what I actually wrote ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 23 20:08:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05303 for ; Fri, 23 Jul 2004 20:08:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BoA2Y-000IOh-96 for namedroppers-data@psg.com; Sat, 24 Jul 2004 00:05:26 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BoA2X-000IOQ-Bx for namedroppers@ops.ietf.org; Sat, 24 Jul 2004 00:05:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CFDD013DF4 for ; Sat, 24 Jul 2004 00:05:24 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: Message from Roy Arends of "Sat, 24 Jul 2004 01:23:47 +0200." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 24 Jul 2004 00:05:24 +0000 Message-Id: <20040724000524.CFDD013DF4@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > There are many ways of shooting yourself in the foot. The point is that > > > someone can't shoot you in the foot. > > > > Well, that's not what you said: "the DNSNR prevents you denying having > > signed that record set." > > Ben. It is very simple: well, really, actually, not. > If _you_ state that _you_ signed record type AAAA and record type MX for a > given name, while not actually signing record type AAAA and record type > MX, that would be violating the spec. thanks for bringing the discussion back to what i think is the main point. roy, can you explain what happens when someone hears a response that has various permutations of this spec-violation, or when a man-in-the-middle removes or replays (but doesn't forge or modify) any or each of these records. > Just as you can write an implementation that publishes a CNAME and an A > record type for a give name. Sure you can do it. But that would be > violating the spec. > > > I would argue even more strongly against the use of > > "non-repudiation" to describe this, since almost no-one would expect > > it to mean what you want it to mean! > > That is arrogant. yes. i agree with roy's use of this term. as someone who has often been criticised for how it was used in two other documents... http://sa.vix.com/~vixie/mailfrom.txt http://www.icann.org/committees/security/sac004.txt ...i really want to say, think carefully about the number of negatives in the terms "non-repudiation" and the like. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 23 20:32:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06208 for ; Fri, 23 Jul 2004 20:32:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BoAPy-000LnQ-1t for namedroppers-data@psg.com; Sat, 24 Jul 2004 00:29:38 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BoAPw-000LnA-Th for namedroppers@ops.ietf.org; Sat, 24 Jul 2004 00:29:37 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i6O0TYWE073259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 24 Jul 2004 00:29:35 GMT (envelope-from roy+dated+1093220974.1b6287@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i6O0TYgo076856 for ; Sat, 24 Jul 2004 01:29:34 +0100 (BST) (envelope-from roy+dated+1093220974.1b6287@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i6O0TYde076855 for namedroppers@ops.ietf.org; Sat, 24 Jul 2004 01:29:34 +0100 (BST) (envelope-from roy+dated+1093220974.1b6287@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 24 Jul 2004 01:29:33 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16641.44396.938491.414591@giles.gnomon.org.uk> Date: Sat, 24 Jul 2004 01:29:32 +0100 To: Roy Arends Cc: Ben Laurie , namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: References: <40F7F935.7050204@algroup.co.uk> <40F813B4.9090004@dnss.ec> <40FBD032.3080504@algroup.co.uk> <007f01c46d9a$a0451690$970fa9c3@mobile666> <40FFD194.6070002@algroup.co.uk> <41014817.4050904@algroup.co.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Roy" == Roy Arends writes: Roy> Ben. It is very simple: Roy> If _you_ state that _you_ signed record type AAAA and record Roy> type MX for a given name, while not actually signing record Roy> type AAAA and record type MX, that would be violating the Roy> spec. I'm going to have to agree with Ben here. For it to consitute non-repudiation as commonly understood, then doing as you describe would have to be provable by a third party by means of the cryptographic protocol, not merely a violation of the specification. Non-repudiation of signing would mean that if you signed something you can't later deny that you've signed it. Or rather, that if you try, a third party can prove that you're lying. But that's a defining property of signing and noone would explicitly state it; anyone can check the signature and prove that you did indeed sign the data. (Here "you" actually means someone who has access to your private key, but that's an implicit assumption in these things.) But that's not what we're taling about, I think. What we're talking about is signing some statement (some kind of NSEC++ record) that asserts that a record doesn't exist. It's just signing a negative statement; it's not asserting that you didn't sign something; and it has nothing to do with either non-repudiation or repudiability. Indeed (not that it's relevant to the argument) but you *might* have signed such a record in the past, that doesn't mean you can't now sign a statement to the effect that the record no longer exists. I am not a cyptologist, but AIUI, non-repudiation means that some other party (either the other party in the transaction, or some third party) is able to prove that the transaction did take place. FWIW, the converse, repudiability, means that if you and I engage in a cryptographic transaction, no third party observer (and perhaps even neither of us) has evidence that would prove that the transaction actually took place. I really don't see either non-repudiation or repudiablity as being relevent to the protocols we're discussing here. We're simply talking about making a signed statement that a particular record does not exist. -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 23 22:22:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10395 for ; Fri, 23 Jul 2004 22:22:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BoC7i-000D9p-Bx for namedroppers-data@psg.com; Sat, 24 Jul 2004 02:18:54 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BoC7f-000D9T-Ac for namedroppers@ops.ietf.org; Sat, 24 Jul 2004 02:18:51 +0000 Received: from [192.168.1.13] ([::ffff:68.48.24.54]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 23 Jul 2004 22:18:50 -0400 id 00151E67.4101C70A.00002F1E In-Reply-To: <16641.44396.938491.414591@giles.gnomon.org.uk> References: <40F7F935.7050204@algroup.co.uk> <40F813B4.9090004@dnss.ec> <40FBD032.3080504@algroup.co.uk> <007f01c46d9a$a0451690$970fa9c3@mobile666> <40FFD194.6070002@algroup.co.uk> <41014817.4050904@algroup.co.uk> <16641.44396.938491.414591@giles.gnomon.org.uk> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Roy Arends , namedroppers@ops.ietf.org, Ben Laurie From: David Blacka Subject: Re: draft-arends-dnsnr-00 Date: Fri, 23 Jul 2004 22:18:49 -0400 To: Roy Badami X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jul 23, 2004, at 8:29 PM, Roy Badami wrote: >>>>>> "Roy" == Roy Arends writes: > > Roy> Ben. It is very simple: > > Roy> If _you_ state that _you_ signed record type AAAA and record > Roy> type MX for a given name, while not actually signing record > Roy> type AAAA and record type MX, that would be violating the > Roy> spec. > > I'm going to have to agree with Ben here. For it to consitute > non-repudiation as commonly understood, then doing as you describe > would have to be provable by a third party by means of the > cryptographic protocol, not merely a violation of the specification. Good lord, people. You are arguing about the *name* of Roy's proposal. Can't we be a little more productive and, say, suggest an alternate name? And perhaps discuss the *content* of the proposal? -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 24 04:30:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05912 for ; Sat, 24 Jul 2004 04:30:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BoHqX-000D0L-V9 for namedroppers-data@psg.com; Sat, 24 Jul 2004 08:25:33 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BoHqW-000D07-Qp for namedroppers@ops.ietf.org; Sat, 24 Jul 2004 08:25:33 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id F31B5AC8B; Sat, 24 Jul 2004 10:25:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id F1D47AC8A; Sat, 24 Jul 2004 10:25:30 +0200 (CEST) Date: Sat, 24 Jul 2004 10:25:30 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: David Blacka Cc: Roy Badami , namedroppers@ops.ietf.org, Ben Laurie Subject: Re: draft-arends-dnsnr-00 In-Reply-To: Message-ID: References: <40F7F935.7050204@algroup.co.uk> <40F813B4.9090004@dnss.ec> <40FBD032.3080504@algroup.co.uk> <007f01c46d9a$a0451690$970fa9c3@mobile666> <40FFD194.6070002@algroup.co.uk> <41014817.4050904@algroup.co.uk> <16641.44396.938491.414591@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 23 Jul 2004, David Blacka wrote: > > On Jul 23, 2004, at 8:29 PM, Roy Badami wrote: > > >>>>>> "Roy" == Roy Arends writes: > > > > Roy> Ben. It is very simple: > > > > Roy> If _you_ state that _you_ signed record type AAAA and record > > Roy> type MX for a given name, while not actually signing record > > Roy> type AAAA and record type MX, that would be violating the > > Roy> spec. > > > > I'm going to have to agree with Ben here. For it to consitute > > non-repudiation as commonly understood, then doing as you describe > > would have to be provable by a third party by means of the > > cryptographic protocol, not merely a violation of the specification. > > Good lord, people. You are arguing about the *name* of Roy's proposal. > Can't we be a little more productive and, say, suggest an alternate > name? And perhaps discuss the *content* of the proposal? Thank you. Meanwhile, to avoid further distraction by and discussion on the name, I'll change it to NSEC3. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 24 04:30:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05930 for ; Sat, 24 Jul 2004 04:30:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BoHst-000DBm-Qn for namedroppers-data@psg.com; Sat, 24 Jul 2004 08:27:59 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BoHss-000DBY-T5 for namedroppers@ops.ietf.org; Sat, 24 Jul 2004 08:27:59 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 343B4AC8B; Sat, 24 Jul 2004 10:27:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 33172AC8A; Sat, 24 Jul 2004 10:27:58 +0200 (CEST) Date: Sat, 24 Jul 2004 10:27:58 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: <20040724000524.CFDD013DF4@sa.vix.com> Message-ID: References: <20040724000524.CFDD013DF4@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 24 Jul 2004, Paul Vixie wrote: > > If _you_ state that _you_ signed record type AAAA and record type MX for a > > given name, while not actually signing record type AAAA and record type > > MX, that would be violating the spec. > > thanks for bringing the discussion back to what i think is the main point. > roy, can you explain what happens when someone hears a response that has > various permutations of this spec-violation, or when a man-in-the-middle > removes or replays (but doesn't forge or modify) any or each of these > records. No problem, will do. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 24 19:28:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19599 for ; Sat, 24 Jul 2004 19:28:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BoVpm-000Dns-Pz for namedroppers-data@psg.com; Sat, 24 Jul 2004 23:21:42 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BoVpl-000Dnd-Uj for namedroppers@ops.ietf.org; Sat, 24 Jul 2004 23:21:41 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5310A13DE2 for ; Sat, 24 Jul 2004 23:21:41 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: Message from Roy Badami of "Sat, 24 Jul 2004 01:29:32 +0100." <16641.44396.938491.414591@giles.gnomon.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 24 Jul 2004 23:21:41 +0000 Message-Id: <20040724232141.5310A13DE2@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > I am not a cyptologist, but AIUI, non-repudiation means that some > other party (either the other party in the transaction, or some third > party) is able to prove that the transaction did take place. No. Close, though. Non-repudiation means being able to prove that a third party can't prove that a transaction did not take place. Count the negations. > ... > I really don't see either non-repudiation or repudiablity as being > relevent to the protocols we're discussing here. We're simply talking > about making a signed statement that a particular record does not > exist. Count the negations, and please stop blaming Arends for excluding a middle. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 25 10:53:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12985 for ; Sun, 25 Jul 2004 10:53:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BokHA-0002jI-Kl for namedroppers-data@psg.com; Sun, 25 Jul 2004 14:46:56 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BokH7-0002iz-Na for namedroppers@ops.ietf.org; Sun, 25 Jul 2004 14:46:53 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 251CD107B14 for ; Sun, 25 Jul 2004 14:46:52 +0000 (GMT) Message-ID: <4103C7DB.3070108@algroup.co.uk> Date: Sun, 25 Jul 2004 15:46:51 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: DNSEXT WG Subject: NSEC2 01 X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit An updated version of the NSEC2 I-D can be found at: http://www.links.org/dnssec/draft-laurie-dnsext-nsec2-01.txt Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 25 12:26:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16164 for ; Sun, 25 Jul 2004 12:26:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BollW-000F5b-He for namedroppers-data@psg.com; Sun, 25 Jul 2004 16:22:22 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BollV-000F5J-CQ for namedroppers@ops.ietf.org; Sun, 25 Jul 2004 16:22:21 +0000 Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i6PGMKRX023330; Sun, 25 Jul 2004 12:22:20 -0400 (EDT) Received: from egyptian-gods.mit.edu (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id i6PGMJoM005966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Jul 2004 12:22:19 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i6PGMI6n001241; Sun, 25 Jul 2004 12:22:18 -0400 Subject: Re: draft-arends-dnsnr-00 From: Greg Hudson To: Paul Vixie Cc: namedroppers@ops.ietf.org In-Reply-To: <20040724232141.5310A13DE2@sa.vix.com> References: <20040724232141.5310A13DE2@sa.vix.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1090772537.16991.78.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 25 Jul 2004 12:22:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2004-07-24 at 19:21, Paul Vixie wrote: > No. Close, though. Non-repudiation means being able to prove that > a third party can't prove that a transaction did not take place. Count > the negations. Source? Googling around yields definitions like: "Nonrepudiation is a way to guarantee that the sender of a message cannot later deny having sent the message and that the recipient cannot deny having received the message." (http://www.webopedia.com/TERM/N/nonrepudiation.html) and In general, nonrepudiation is the ability to ensure that a party to a contract or a communication cannot deny the authenticity of their signature on a document or the sending of a message that they originated. (http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci761640,00.html) These definitions agree with my understanding from cryptography courses, Schneier, et al. Your definition puzzles me. Non-repudiation would seem to be a sensical property for financial transactions; it doesn't seem terribly relevant to DNS. (Apologies for perpetuating the discussion over the least important aspect of the draft. nsecN for some value of N seems like a fine name--nsec2 seems to make the most sense for external consumption, nsec3 for internal communication. I don't know which the IETF generally favors. The proposal itself seems like a nice way of integrating hashes into nsec records without mandating that everyone use them, but of course people have pointed out that hashes may not be terribly effective at preventing zone traversal.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 25 20:46:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06650 for ; Sun, 25 Jul 2004 20:46:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BotXT-0002tc-L7 for namedroppers-data@psg.com; Mon, 26 Jul 2004 00:40:23 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BotXS-0002rp-OH for namedroppers@ops.ietf.org; Mon, 26 Jul 2004 00:40:22 +0000 Received: by sa.vix.com (Postfix, from userid 716) id 49B2713E05; Mon, 26 Jul 2004 00:40:22 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 References: <40F7F935.7050204@algroup.co.uk> <40F813B4.9090004@dnss.ec> <40FBD032.3080504@algroup.co.uk> <007f01c46d9a$a0451690$970fa9c3@mobile666> <40FFD194.6070002@algroup.co.uk> <41014817.4050904@algroup.co.uk> <16641.44396.938491.414591@giles.gnomon.org.uk> From: Paul Vixie Date: 26 Jul 2004 00:40:22 +0000 In-Reply-To: Message-ID: Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka writes: > Good lord, people. You are arguing about the *name* of Roy's proposal. > Can't we be a little more productive and, say, suggest an alternate > name? And perhaps discuss the *content* of the proposal? we could do that, and we're apparently (as in NSEC3) going to do that. however, based on the disagreements about the meaning of the name roy chose, i think that there's still disagreement about what kind of negative proofs ("should the middle be excluded?") people actually think is needed. in other words, the disagreement about the name could be the tip of the iceberg. -- Paul Vixie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 26 04:14:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08226 for ; Mon, 26 Jul 2004 04:14:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp0WH-0009CQ-PF for namedroppers-data@psg.com; Mon, 26 Jul 2004 08:07:37 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp0WG-0009C9-Ne for namedroppers@ops.ietf.org; Mon, 26 Jul 2004 08:07:36 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 70F4E55E3D; Mon, 26 Jul 2004 09:47:10 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 256D655E39; Mon, 26 Jul 2004 09:47:10 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i6Q7lA1o009006; Mon, 26 Jul 2004 09:47:10 +0200 Date: Mon, 26 Jul 2004 09:47:09 +0200 From: "Olaf M. Kolkman" To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 Message-Id: <20040726094709.1ddf51a9.olaf@ripe.net> In-Reply-To: References: Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.007151 / 0.0 / 0.0 / disabled X-RIPE-Signature: cfc6b5d42c4eb299cf3455160cc22855 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would have liked to keep this genie in its bottle but it occurs that Roy's proposal is a mixture of NSEC2 and OPT-IN specs. I would say that the same security properties of OPT-IN apply to the Roy's proposal. I.e. the record provides proof that a certain part of the namescpace is insecure. In that part of the insecure namespace you can happily spoof names away or spoof a microzoft.com response. If we want to have both obscured names and "non-secured" intervals in your zone, so that during initial deployment you only have to create and sign a handful of NSEC variants than Roy's proposal is worth investigating. If you want a choice between "fully secured" zone with obfuscated NSECs and a zone with "insecure ranges" with obfuscated NSECs than NSEC2 with an "OPT-IN" type flag seems to be the way forward. --Olaf (no hats) PS. For a name: Hashed Insecure Interval: HII RR ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 26 05:03:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09939 for ; Mon, 26 Jul 2004 05:03:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp1L2-000GJG-N1 for namedroppers-data@psg.com; Mon, 26 Jul 2004 09:00:04 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp1L1-000GIV-4J for namedroppers@ops.ietf.org; Mon, 26 Jul 2004 09:00:03 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 7E567AC8B; Mon, 26 Jul 2004 10:43:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 77D8AAC8A; Mon, 26 Jul 2004 10:43:00 +0200 (CEST) Date: Mon, 26 Jul 2004 10:43:00 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: <20040726094709.1ddf51a9.olaf@ripe.net> Message-ID: References: <20040726094709.1ddf51a9.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,OPT_IN, OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 26 Jul 2004, Olaf M. Kolkman wrote: > I would have liked to keep this genie in its bottle but it occurs that > Roy's proposal is a mixture of NSEC2 and OPT-IN specs. I would say > that the same security properties of OPT-IN apply to the Roy's > proposal. The NSEC2 specs in my proposal are different, but in general, yes, hashed names and OPT-IN. > I.e. the record provides proof that a certain part of the > namescpace is insecure. In that part of the insecure namespace you can > happily spoof names away or spoof a microzoft.com response. Opt-in is an option. > If we want to have both obscured names and "non-secured" intervals in > your zone, so that during initial deployment you only have to create > and sign a handful of NSEC variants than Roy's proposal is worth > investigating. > > If you want a choice between "fully secured" zone with obfuscated NSECs > and a zone with "insecure ranges" with obfuscated NSECs than NSEC2 with > an "OPT-IN" type flag seems to be the way forward. I don't understand what you are suggesting, since you start with the notion that NSEC3 is a mixture of NSEC2 and OPT-IN, and you end with the notion that NSEC2 with OPT-IN is different then NSEC3 (If/If). Leaving opt-in aside for the moment, lets compare NSEC2 and NSEC3. NSEC3 is backwards compatible with NSEC (using hash value 0), allowing operators to first switch to DNSSEC-ter at some point in time, and after that, whitch to hashed ownernames. NSEC2 is either-or. There is no bw compatibility with NSEC2. If an operator wants to switch to plain labels, not only does it need to switch to NSEC, also it needs to switch to DNSSEC-bis. NSEC3 does not 'flatten' empty-non-terminals, where-as NSEC2 emulates empty non-terminals with an extra EXIST record type. This is because NSEC3 hashes individual labels, where NSEC2 hashes owner-names. NSEC3 does not include 'hash-iterations' since the gain in obscuring does not outweigh the additional cost in authoritative nameservers. In general, the purpose of both records are the same: increase the cost of zone-enumeration. NSEC3 has NSEC2 properties. Additionally it is bw compatible with NSEC, allows OPT-IN and does not need extra records like NSECINFO and EXIST. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 26 05:19:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10436 for ; Mon, 26 Jul 2004 05:19:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp1aG-000Ib4-Ke for namedroppers-data@psg.com; Mon, 26 Jul 2004 09:15:48 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp1aF-000Iap-7C for namedroppers@ops.ietf.org; Mon, 26 Jul 2004 09:15:47 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i6Q8kSBP074959 for ; Mon, 26 Jul 2004 10:46:28 +0200 (CEST) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) with ESMTP id i6Q8kRVb027872 for ; Mon, 26 Jul 2004 10:46:27 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) id i6Q8kRj6027871 for namedroppers@ops.ietf.org; Mon, 26 Jul 2004 10:46:27 +0200 Date: Mon, 26 Jul 2004 10:46:27 +0200 From: Miek Gieben To: namedroppers@ops.ietf.org Subject: Re: DNSSEXT draft agenda IETF 60 Message-ID: <20040726084627.GB27267@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <20040723162804.0c3cb492.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040723162804.0c3cb492.olaf@ripe.net> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 23 Jul, @16:28, Olaf wrote in "DNSSEXT draft agenda IETF 60 ..."] > Monday Aug 2, 09:00-11:30 1st slot > DNSSEC session > > > - WG Administrivia (approx 10 min) > + Session administration > - Appointment Scribes > - Agenda Bashing > - Previous Minutes > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02219.html > > - Reid: DNS-MODA plug (approx 3 min, no discussion) Does this item belong in a technical oriented meeting? Esp. when there is also no discussion possible? Regards, Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 26 05:50:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11577 for ; Mon, 26 Jul 2004 05:50:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp24Q-000MoC-Jd for namedroppers-data@psg.com; Mon, 26 Jul 2004 09:46:58 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp24O-000Mnt-Vo for namedroppers@ops.ietf.org; Mon, 26 Jul 2004 09:46:57 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 8D495107814; Mon, 26 Jul 2004 09:46:55 +0000 (GMT) Message-ID: <4104D30E.50709@algroup.co.uk> Date: Mon, 26 Jul 2004 10:46:54 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Roy Arends Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 References: <20040726094709.1ddf51a9.olaf@ripe.net> In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,OPT_IN, OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > On Mon, 26 Jul 2004, Olaf M. Kolkman wrote: > > >>I would have liked to keep this genie in its bottle but it occurs that >>Roy's proposal is a mixture of NSEC2 and OPT-IN specs. I would say >>that the same security properties of OPT-IN apply to the Roy's >>proposal. > > > The NSEC2 specs in my proposal are different, but in general, yes, hashed > names and OPT-IN. > > >>I.e. the record provides proof that a certain part of the >>namescpace is insecure. In that part of the insecure namespace you can >>happily spoof names away or spoof a microzoft.com response. > > > Opt-in is an option. > > >>If we want to have both obscured names and "non-secured" intervals in >>your zone, so that during initial deployment you only have to create >>and sign a handful of NSEC variants than Roy's proposal is worth >>investigating. >> >>If you want a choice between "fully secured" zone with obfuscated NSECs >>and a zone with "insecure ranges" with obfuscated NSECs than NSEC2 with >>an "OPT-IN" type flag seems to be the way forward. > > > I don't understand what you are suggesting, since you start with the > notion that NSEC3 is a mixture of NSEC2 and OPT-IN, and you end with the > notion that NSEC2 with OPT-IN is different then NSEC3 (If/If). > > Leaving opt-in aside for the moment, lets compare NSEC2 and NSEC3. > > NSEC3 is backwards compatible with NSEC (using hash value 0), allowing > operators to first switch to DNSSEC-ter at some point in time, and after > that, whitch to hashed ownernames. NSEC2 is either-or. There is no bw > compatibility with NSEC2. If an operator wants to switch to plain labels, > not only does it need to switch to NSEC, also it needs to switch to > DNSSEC-bis. I do not propose that NSEC2 should _replace_ NSEC, I propose that an operator can choose which of the two record types is supported. > NSEC3 does not 'flatten' empty-non-terminals, where-as NSEC2 emulates > empty non-terminals with an extra EXIST record type. This is because NSEC3 > hashes individual labels, where NSEC2 hashes owner-names. I am not wedded to the idea that the whole owner name should be hashed, but there are at least two considerations here: a) Hashing individual labels will make the records _much_ bigger. b) EXIST is only needed if the zone is more than one name deep (i.e. names within the zone contain dots), which strikes me as a rare situation. > NSEC3 does not include 'hash-iterations' since the gain in obscuring does > not outweigh the additional cost in authoritative nameservers. Of course, you can set it to 1 in NSEC2 if you believe this. > In general, the purpose of both records are the same: increase the cost of > zone-enumeration. > > NSEC3 has NSEC2 properties. Additionally it is bw compatible with NSEC, > allows OPT-IN and does not need extra records like NSECINFO and EXIST. NSECINFO does not appear in NSEC2-01. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 26 06:12:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12490 for ; Mon, 26 Jul 2004 06:12:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp2P4-0000LH-Md for namedroppers-data@psg.com; Mon, 26 Jul 2004 10:08:18 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp2P2-0000Ki-QB for namedroppers@ops.ietf.org; Mon, 26 Jul 2004 10:08:17 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i6QA8FqJ009770 for ; Mon, 26 Jul 2004 11:08:15 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: DNSSEXT draft agenda IETF 60 In-Reply-To: Message from Miek Gieben of "Mon, 26 Jul 2004 10:46:27 +0200." <20040726084627.GB27267@atoom.net> Date: Mon, 26 Jul 2004 11:08:15 +0100 Message-ID: <9769.1090836495@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Miek" == Miek Gieben writes: >> - Reid: DNS-MODA plug (approx 3 min, no discussion) Miek> Does this item belong in a technical oriented meeting? Miek> Esp. when there is also no discussion possible? Well the WG chairs seem to think so... :-) FYI, all I'll be doing is announcing the time and place of a meeting in the Sheraton for those who want to know more about DNS-MODA. The meeting is open to everyone and it will have plenty of time for discussion. [You can even bring your own black helicopters. :-)] If my slot in the WG agenda lasts as long as 3 minutes, it'll be a miracle. A discussion about DNS-MODA would not be appropriate in the WG. However an announcement about it is. Consider this DNS-MODA event as a sort of unofficial BoF. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 26 06:30:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12970 for ; Mon, 26 Jul 2004 06:30:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp2g4-0002mB-6P for namedroppers-data@psg.com; Mon, 26 Jul 2004 10:25:52 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp2g3-0002ln-37 for namedroppers@ops.ietf.org; Mon, 26 Jul 2004 10:25:51 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i6QAPlLQ076123 for ; Mon, 26 Jul 2004 12:25:47 +0200 (CEST) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) with ESMTP id i6QAPjlr030664 for ; Mon, 26 Jul 2004 12:25:45 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) id i6QAPjjQ030663 for namedroppers@ops.ietf.org; Mon, 26 Jul 2004 12:25:45 +0200 Date: Mon, 26 Jul 2004 12:25:45 +0200 From: Miek Gieben To: namedroppers@ops.ietf.org Subject: Re: DNSSEXT draft agenda IETF 60 Message-ID: <20040726102544.GA30628@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <20040726084627.GB27267@atoom.net> <9769.1090836495@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9769.1090836495@gromit.rfc1035.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 26 Jul, @12:08, Jim wrote in "Re: DNSSEXT draft agenda IETF ..."] > >>>>> "Miek" == Miek Gieben writes: > FYI, all I'll be doing is announcing the time and place of a meeting > in the Sheraton for those who want to know more about DNS-MODA. The > meeting is open to everyone and it will have plenty of time for > discussion. [You can even bring your own black helicopters. :-)] If my > slot in the WG agenda lasts as long as 3 minutes, it'll be a miracle. A > discussion about DNS-MODA would not be appropriate in the WG. However > an announcement about it is. Consider this DNS-MODA event as a sort of > unofficial BoF. ah, ok. I can live with that ;-) grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 26 06:40:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13452 for ; Mon, 26 Jul 2004 06:40:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp2oK-0003uJ-VK for namedroppers-data@psg.com; Mon, 26 Jul 2004 10:34:24 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp2oJ-0003tz-C9 for namedroppers@ops.ietf.org; Mon, 26 Jul 2004 10:34:23 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 8F0D6AC8B; Mon, 26 Jul 2004 12:34:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 8DC48AC8A; Mon, 26 Jul 2004 12:34:22 +0200 (CEST) Date: Mon, 26 Jul 2004 12:34:22 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: <4104D30E.50709@algroup.co.uk> Message-ID: References: <20040726094709.1ddf51a9.olaf@ripe.net> <4104D30E.50709@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 26 Jul 2004, Ben Laurie wrote: > I do not propose that NSEC2 should _replace_ NSEC, I propose that an > operator can choose which of the two record types is supported. I understand that. But both record types exist in different versions of DNSSEC. To avoid switching back to previous versions of DNSSEC I included bw compatibility. I would not encourage retaining NSEC and NSECX in a single version of DNSSEC. > > NSEC3 does not 'flatten' empty-non-terminals, where-as NSEC2 emulates > > empty non-terminals with an extra EXIST record type. This is because NSEC3 > > hashes individual labels, where NSEC2 hashes owner-names. > > I am not wedded to the idea that the whole owner name should be hashed, > but there are at least two considerations here: > > a) Hashing individual labels will make the records _much_ bigger. > > b) EXIST is only needed if the zone is more than one name deep (i.e. > names within the zone contain dots), which strikes me as a rare situation. The tradeoff is as follows: For one label deep, both proposals have the same cost. NSEC3 hashes one label, NSEC2 uses a single hash. For the 'rare situation' of more labels deep, NSEC3 has a larger ownername due to multiple hashes, while NSEC2 has additional EXIST, RRSIG(EXIST), NSEC2, RRSIG(NSEC2). The thing to consider is that with NSEC2, empty-non-terminals disappear and are now emulated by EXIST records (which are non-empty). I won't use the hash-truncation argument, since it is presumed controversial, and can be applied to both proposals. > > NSEC3 does not include 'hash-iterations' since the gain in obscuring does > > not outweigh the additional cost in authoritative nameservers. > > Of course, you can set it to 1 in NSEC2 if you believe this. If an authoritative nameserver receives a query for a non-existent name, it has to iterate the hash function on the QNAME until it can include the overlapping NSEC2, right ? To me, that is a DoS factor. > > In general, the purpose of both records are the same: increase the cost of > > zone-enumeration. > > > > NSEC3 has NSEC2 properties. Additionally it is bw compatible with NSEC, > > allows OPT-IN and does not need extra records like NSECINFO and EXIST. > > NSECINFO does not appear in NSEC2-01. That is an improvement, but from the abstract of NSEC2-01: This document proposes an alternate scheme which hides owner names while permitting authenticated denial of existence of non-existent names. The scheme uses three new RR types: NSECINFO, NSEC2 and EXIST. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 27 03:20:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24546 for ; Tue, 27 Jul 2004 03:20:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpMB5-000233-A2 for namedroppers-data@psg.com; Tue, 27 Jul 2004 07:15:11 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpMB3-00022f-Tm for namedroppers@ops.ietf.org; Tue, 27 Jul 2004 07:15:10 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 5A8ED4E7A1; Tue, 27 Jul 2004 09:15:09 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 79F674E684 for ; Tue, 27 Jul 2004 09:15:07 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i6R7F61o022094 for ; Tue, 27 Jul 2004 09:15:06 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id i6R7F6b6004522 for namedroppers@ops.ietf.org; Tue, 27 Jul 2004 09:15:06 +0200 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkkKl-000OKE-DK for namedroppers@ops.ietf.org; Wed, 14 Jul 2004 14:02:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6EE1uM01168; Wed, 14 Jul 2004 17:01:57 +0300 Date: Wed, 14 Jul 2004 17:01:56 +0300 (EEST) From: Pekka Savola To: dnsop@lists.uoregon.edu Cc: namedroppers@ops.ietf.org, Subject: dnsop-ipv6-dns-issues: handling of additional data and TTL w/ caching Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.039748 / 0.0 / 0.0 / disabled X-RIPE-Signature: fb74f81ad34662cbe2577d9a95e6d214 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: This post needed manual approval. Either because it was posted by a non-subscriber or because it contained to many characters (> 20000). With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please fix your subscription addresses or shorten your postings by adding links instead of attachments ] Hi, (also to dnsext WG) Thomas Narten provided extensive feedback on draft-ietf-dnsop-ipv6-dns-issues at IESG evaluation, and I've tried to address his comments (see the I-D tracker) in: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-08pre-diff.html http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-08pre.txt but there are still a few where it might be useful to get feedback from the WG(s). Most of the discussion was on section 4.4 on the handling of additional data -- a subject that was already discussed briefly on the list around May 6, but did not have a clear conclusion (thread below): http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00406.html I've tried to summarize the discussion below *) Now, Thomas brought up a lot of the same issues at IESG evaluation, and I thought we should try again to see if there could be some consensus on how to move forward. ... I think we have achieved at least the follows (please yell if not the case): a) If some critical additional data RRsets wouldn't fit, you set the TC bit even if some RRsets did fit. b) If some courtesy additional data RRsets wouldn't fit, you never set the TC bit, but rather remove (at least some of) the courtesy RRsets. c) DNS servers should implement sanity checks on the resulting glue, e.g., to disable circular dependencies. Then the responding servers can use at-or-below-a-zone-cut criterion to determine whether the additional data is critical or not. Now, there are still (IMHO) many open issues: 1) if some critical additional data RRsets would fit, but some wouldn't, and TC has to be set (see above), should one rather remove the additional data that did fit, keep it, or leave unspecified? 2) if some courtesy additional data RRsets would fit, but some wouldn't, and some will have to be removed from the response (no TC is set, see above), what to do -- remove all courtesy RRsets, keep all that fit, or leave unspecified? 3) is it acceptable to use the transport used in the DNS query as a hint which records to keep if not removing all the RRsets, if: a) having to decide which critical additional data to keep, or b) having to decide which courtesy additional data to keep? 4) (this issue was discussed in section 4.5) if one RRset has TTL of 100 seconds, and another the TTL of 300 seconds, what should the caching server do after 100 seconds? Keep returning just one RRset when returning additional data, or discard the other RRset from the cache? 5) How do we move forward from here? If we manage to get to some form of consensus, how do we record it: a) just in draft-ietf-dnsop-ipv6-dns-issues (note that it's Informational category only!), b) a separate BCP or similar by DNSEXT WG(?), clarifying and giving recommendations, c) something else, what? Thoughts, opinions, etc.? Fire away! (I'm trying to submit a revised document prior to the cut-off in any case, no matter how this turns out..) A few of my personal thoughts below the summary. *) a summary attempt of the past discussion below. ======== Edward Lewis (on dnsop) thought that omitting vs including courtesy additional data was a tradeoff at the server end (issue about handling the new query vs potentially misleading the client), and that TC bit should only be set if critical additional data was left behind. Robert Elz thought that the servers could add also add full RRsets, even if not all of them, if they want to. Similarly, he would rather return only part of the courtesy data than set the TC bit. He was of two minds about whether to set TC bit when all of courtesy additional data won't fit (but slightly leaning on TC bit, except if some additional data could fit and be included in a round-robin fashion); Robert also called for measurements on this. Paul Vixie thought that just simply setting TC bit if anything doesn't fit is a good idea if we don't have measurements to justify another kind of approach. Matt Larson commented on the definition of glue; the responding server can know whether the data is critical just by looking whether it's at-or-below-a-zone-cut. Masataka Ohta commented that this isn't sufficient if e.g. "org" zone is served by an "edu" server and vice versa. Mark Andrews rebutted that we don't have to support all the combinations if it makes managing the DNS impossible; DNS server software have included checks to avoid circular dependencies. Masataka Ohta also participated in the discussion, and Andreas Gustafsson clarified Paul Vixie's comment. ========= As for my personal take, if interested: My argument is that it would be best to return everything, or as little as possible. Not whatever you think you feel like you want to send. The reasoning here is that that if the user/application is interested in both A and AAAA records (this doesn't matter if (s)he's only interested in one), the DNS should either try to ensure (as far as possible) it's giving a full view, or just basically say to the user, "query yourself what you want, here's the critical info you need for those queries". This is based on the assumption that if the DNS servers start second-guessing what kind of information the end-user would prefer (e.g., by looking at the transport used), it's likely going to go wrong because the DNS server asking for the records from the second-guessing DNS server is likely going to be acting as a recursive resolver, and it doesn't really indicate *at all* which IP version the application wants to prefer (or not), or which kind IP version is available in the first place. So, relating to the questions above: 1) not much preference here 2) remove all courtesy data 3) I'd rather not to look at the transport used, but 3.a) would be acceptable, 3.b) not (per 2) 4) I'd prefer discarding all the RRsets from the cache when the one with the shortest TTL one times out, this ensures an "everything or nothing" approach. 5) A separate document might be good so that this doesn't get lost within an Informational document. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 27 04:00:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26385 for ; Tue, 27 Jul 2004 04:00:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpMqK-0007F0-Ub for namedroppers-data@psg.com; Tue, 27 Jul 2004 07:57:48 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpMqK-0007Eh-3i for namedroppers@ops.ietf.org; Tue, 27 Jul 2004 07:57:48 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 280B655E7D; Tue, 27 Jul 2004 09:26:09 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id BD73051FD4; Tue, 27 Jul 2004 09:26:08 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i6R7Q81o025663; Tue, 27 Jul 2004 09:26:08 +0200 Date: Tue, 27 Jul 2004 09:26:08 +0200 From: "Olaf M. Kolkman" To: Jim Reid , Miek Gieben Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEXT draft agenda IETF 60 Message-Id: <20040727092608.72db8803.olaf@ripe.net> In-Reply-To: <9769.1090836495@gromit.rfc1035.com> References: <20040726084627.GB27267@atoom.net> <9769.1090836495@gromit.rfc1035.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 67d8a14393d6e71a96e2b443ed333d3d X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 26 Jul 2004 11:08:15 +0100 Jim Reid wrote: > >>>>> "Miek" == Miek Gieben writes: > > >> - Reid: DNS-MODA plug (approx 3 min, no discussion) > > Miek> Does this item belong in a technical oriented meeting? > Miek> Esp. when there is also no discussion possible? > > Well the WG chairs seem to think so... :-) > "DNS-MODA info-meeting plug" or "DNS-MODA announcement" would have been a better title for this agenda item. Apologies, the venom is as alsways in the detail. -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 27 06:04:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02326 for ; Tue, 27 Jul 2004 06:04:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpOkq-000NI3-Cy for namedroppers-data@psg.com; Tue, 27 Jul 2004 10:00:16 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpOkp-000NHe-8n for namedroppers@ops.ietf.org; Tue, 27 Jul 2004 10:00:15 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 9F1864E2A3; Tue, 27 Jul 2004 12:00:14 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 460BF4E1B1 for ; Tue, 27 Jul 2004 12:00:14 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i6RA0E1o017810 for ; Tue, 27 Jul 2004 12:00:14 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id i6RA0E27010718 for namedroppers@ops.ietf.org; Tue, 27 Jul 2004 12:00:14 +0200 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpOaX-000LVl-9P for namedroppers@ops.ietf.org; Tue, 27 Jul 2004 09:49:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6R9nZi19483; Tue, 27 Jul 2004 12:49:35 +0300 Date: Tue, 27 Jul 2004 12:49:35 +0300 (EEST) From: Pekka Savola To: namedroppers@ops.ietf.org Cc: dnsop@lists.uoregon.edu Subject: getaddrinfo/TTL and resolver application-interface Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.064703 / 0.0 / 0.0 / disabled X-RIPE-Signature: 3a08da49736f0f6659ff7b393660f04a X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: This post needed manual approval. Either because it was posted by a non-subscriber or because it contained to many characters (> 20000). With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please fix your subscription addresses or shorten your postings by adding links instead of attachments ] Hi, draft-gieben-resolver-application-interface-00.txt sketches what kind of information the application and the resolver could have through an interface. This has been discussed in dnsext at least in Feb 2004. What has been the outcome? The reason why I got interested was because section 8.2 of draft-ietf-dnsop-ipv6-dns-issues-08.txt (see below) shows that the application should be able to be aware of the TTL of the records, easily, so that it could discard expired records from the memory if it's built around in such a way that it would be feasible to do so. As it is, the applications typically query a name when they start and use it forever, irregardless of the TTL. (And if the application-resolver interface needs work in any case....) IMHO, it seem to be worth adding the TTL information to getaddrinfo() functions. from draft-ietf-dnsop-ipv6-dns-issues-08.txt: 8.2 Renumbering Procedures and Applications' Use of DNS One of the most difficult problems of systematic IP address renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that an application which looks up a DNS name disregards information such as TTL, and uses the result obtained from DNS as long as it happens to be stored in the memory of the application. For applications which run for a long time, this could be days, weeks or even months; some applications may be clever enough to organize the data structures and functions in such a manner that look-ups get refreshed now and then. While the issue appears to have a clear solution, "fix the applications", practically this is not reasonable immediate advice; the TTL information is not typically available in the APIs and libraries (so, the advice becomes "fix the applications, APIs and libraries"), and a lot more analysis is needed on how to practically go about to achieve the ultimate goal of avoiding using the names longer than expected. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 27 07:18:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05634 for ; Tue, 27 Jul 2004 07:18:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpPw6-0006q0-W7 for namedroppers-data@psg.com; Tue, 27 Jul 2004 11:15:58 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpPvx-0006ob-SS for namedroppers@ops.ietf.org; Tue, 27 Jul 2004 11:15:50 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i6RB6XqY095388; Tue, 27 Jul 2004 13:06:33 +0200 (CEST) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) with ESMTP id i6RB6WXY015397; Tue, 27 Jul 2004 13:06:32 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) id i6RB6V8s015393; Tue, 27 Jul 2004 13:06:31 +0200 Date: Tue, 27 Jul 2004 13:06:31 +0200 From: Miek Gieben To: Pekka Savola Cc: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Subject: Re: getaddrinfo/TTL and resolver application-interface Message-ID: <20040727110631.GB14975@atoom.net> Mail-Followup-To: Pekka Savola , namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 27 Jul, @11:49, Pekka wrote in "getaddrinfo/TTL and resolver a ..."] > Hi, > > draft-gieben-resolver-application-interface-00.txt sketches what kind > of information the application and the resolver could have through an > interface. This has been discussed in dnsext at least in Feb 2004. > What has been the outcome? nothing yet, we had a lot of discussion about it, but nothing materialized out of it. Personally I think some other questions also need to be answered, like: o what service does the DNS actually provide? (it's a naming service, but application seem to want to know more and more about the resolution process. Esp. with DNSSEC). o where do applications start and resolvers end? A seen from the text below, apps now want to know TTLs. Where does it stop? o Each "application" (IPSEC for instance) has different (security) needs, and has a different set of "local policy" rules. What kind of interface is needed to allow for an application to make it's own policy decisions? Following this line of thinking we could come to the conclussion that an application wants to know the entire resolving chain, from the root down to the leave node. But when your local resolver does caching this might now be available... so there you go.... > The reason why I got interested was because section 8.2 of > draft-ietf-dnsop-ipv6-dns-issues-08.txt (see below) shows that the > application should be able to be aware of the TTL of the records, > easily, so that it could discard expired records from the memory if > it's built around in such a way that it would be feasible to do so. > As it is, the applications typically query a name when they start and > use it forever, irregardless of the TTL. (And if the > application-resolver interface needs work in any case....) > > IMHO, it seem to be worth adding the TTL information to getaddrinfo() > functions. grtz, --Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 27 11:00:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19308 for ; Tue, 27 Jul 2004 11:00:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpTLm-000Icg-Es for namedroppers-data@psg.com; Tue, 27 Jul 2004 14:54:42 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpTLl-000IcN-KH for namedroppers@ops.ietf.org; Tue, 27 Jul 2004 14:54:41 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6REptK8028719 for ; Tue, 27 Jul 2004 10:51:55 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAf3aOe4; Tue, 27 Jul 04 10:51:51 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id i6RErJVS006195; Tue, 27 Jul 2004 10:53:19 -0400 (EDT) Date: Tue, 27 Jul 2004 10:53:19 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Ben Laurie cc: DNSEXT WG Subject: Re: NSEC2 01 In-Reply-To: <4103C7DB.3070108@algroup.co.uk> Message-ID: References: <4103C7DB.3070108@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk General comments on the doc: I'd like to see a higher-level discussion of the fundamental changes being made here: in particular, I was confused by the first sentence of Section 2: "The NSEC2 resource record lists ...: the SHA-1 hash of the owner name of the next RRset in the canonical ordering of the zone." This does not make it clear that you're discarding all sense of canonical ordering EXCEPT of the NSEC2 records, and that the NSEC2 ordering is based on the canonical order of the hashed name, not the actual owner name I see no discussion saying that hash algorithm, salt, and iterations are zone properties. The document needs to describe how to change these, and if the only method is to make the zone insecure for an interval, that limitation needs to be explained. Section 4 still mentions NSECINFO. The doc should probably explain why a validator will always know what hash, salt, etc. to use and why NSECINFO or extra NSEC2 queries aren't needed. That discussion should consider that a validator does not always know what zone an answer is in (see the DS grandparent problem). I'm not convinced that the wildcard discussion/example is correct. Perhaps Ed Lewis or Bob Halley can comment? Nits: The example in 2.4 looks wrong: wouldn't the NSEC2 chain have to contain the example.com zone apex, too? The IANA section is woefully inadequate, but this can be fixed later. Can we reuse the hash registry from DS, or do we really need a new one? The date header needs to be updated, except on the first page. The first citation can be updated to RFC3755. Section 2.1.3, paragraph on domain name compression: Section 4 of RFC3597 recommends that this text remain. Perhaps cite 3597. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 27 11:42:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23175 for ; Tue, 27 Jul 2004 11:42:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpU3Q-000Oez-AR for namedroppers-data@psg.com; Tue, 27 Jul 2004 15:39:48 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpU3P-000Oej-Ei for namedroppers@ops.ietf.org; Tue, 27 Jul 2004 15:39:47 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6RFb0Lq009356 for ; Tue, 27 Jul 2004 11:37:00 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAXjaqks; Tue, 27 Jul 04 11:36:48 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id i6RFc3s5008538; Tue, 27 Jul 2004 11:38:03 -0400 (EDT) Date: Tue, 27 Jul 2004 11:38:02 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Roy Arends cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Avoiding the terminology discussion entirely... I'm confused about how DNSNR is supposed to work with hashed next names. Perhaps I'm missing something. I'd like to be enlightened. It looks like you're continuing to use DNSNR/NSEC3 owner names which match "actual owner names", to borrow Ben's terminology. For example (and I'd love to see an example with hashed owner names in the doc): example.com. 86400 IN DNSNR ? 1 34abc (hash(34abc+alpha)) types alfa.example.com. 86400 IN DNSNR ? 1 34abc (hash(34abc+beta)) types beta.example.com. 86400 IN DNSNR ? 1 34abc (hash(34abc+apex)) types (Which ignores the authoritative-only bit and doesn't say how much of the next name you're hashing, since I don't understand that part of the discussion.) What answer is given in response to a query for c.example.com? The beta DNSNR tells me nothing, since I can't tell what name was used to create the hash, and I can't tell if c.example.com would be covered by the DNSNR or not. In other matters, I find the discussion of the authoritative only bit in 2.1.1 confusing, if not misleading. If you want to not have DNSNRs for unsecure delegations (or optionally not have them), just say that. Make it clear whether the authoritative only bit is a per-zone thing or applies per-span, like opt-in. And the incomplete citation in the first paragraph of 2.1.4 is likely to be inconsistent with not requiring DNSNRs at each name (including those unsecure delegations). Also, the presentation format of the hash value is inconsistent between 2.1.2 (third paragraph) and 2.2. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 27 12:48:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28035 for ; Tue, 27 Jul 2004 12:48:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpV4H-0006Rf-K2 for namedroppers-data@psg.com; Tue, 27 Jul 2004 16:44:45 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpV4G-0006RO-Ar for namedroppers@ops.ietf.org; Tue, 27 Jul 2004 16:44:44 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 343DFAC8D; Tue, 27 Jul 2004 18:44:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 2E41BAC8B; Tue, 27 Jul 2004 18:44:43 +0200 (CEST) Date: Tue, 27 Jul 2004 18:44:43 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Samuel Weiler Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 27 Jul 2004, Samuel Weiler wrote: > Avoiding the terminology discussion entirely... thanks > I'm confused about how DNSNR is supposed to work with hashed next > names. Perhaps I'm missing something. I'd like to be enlightened. > > It looks like you're continuing to use DNSNR/NSEC3 owner names which > match "actual owner names", to borrow Ben's terminology. For example > (and I'd love to see an example with hashed owner names in the doc): Examples will be in -01. > example.com. 86400 IN DNSNR ? 1 34abc (hash(34abc+alpha)) types > alfa.example.com. 86400 IN DNSNR ? 1 34abc (hash(34abc+beta)) types > beta.example.com. 86400 IN DNSNR ? 1 34abc (hash(34abc+apex)) types > > (Which ignores the authoritative-only bit and doesn't say how much of > the next name you're hashing, since I don't understand that part of > the discussion.) > > What answer is given in response to a query for c.example.com? The > beta DNSNR tells me nothing, since I can't tell what name was used to > create the hash, and I can't tell if c.example.com would be covered by > the DNSNR or not. Assume a hash function that hashes hash[34abc]: G39291 (this is a hash over the salt value) hash[34abc+www]: A38565 hash[34abc+mail]: Q83881 hash[34abc+test]: L21772 and the following records in zone example.com: example.com SOA ... example.com NS ... example.com A ... example.com DNSKEY ... mail.example.com MX ... test.example.com HINFO ... www.example.com A ... After DNSNR/NSEC3 processing (probably part of 'zone-signing') the following NSEC3 records are added: A38565.example.com NSEC3 1 3 34abc G39291.example.com A G39291.example.com NSEC3 1 3 34abc L21772.example.com SOA A NS DNSKEY RRSIG NSEC3 L21772.example.com NSEC3 1 3 34abc Q83881.example.com HINFO RRSIG NSEC3 Q83881.example.com NSEC3 1 3 34abc A38565.example.com MX RRSIG NSEC3 A query for 'c.example.com', say type A returns ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;c.example.com. IN A ;; AUTHORITY SECTION: example.com SOA example.com ... example.com RRSIG SOA ... L21772.example.com NSEC3 1 3 34abc Q83881.example.com HINFO RRSIG NSEC3 L21772.example.com RRSIG NSEC3 To check if this NSEC3 record in the authority section covers 'c.example.com', the 'c' labels is hashed. hash[34abc+c]: P44889 Indeed, P44889.example.com is covered by L21772.example.com NSEC3 record. It is within the interval of L21772 -- Q83881 provided by NSEC3. > In other matters, I find the discussion of the authoritative only bit > in 2.1.1 confusing, if not misleading. If you want to not have DNSNRs > for unsecure delegations (or optionally not have them), just say > that. I'll try to clarify that. > Make it clear whether the authoritative only bit is a per-zone > thing or applies per-span, like opt-in. Per-span, I'll make that clear. > And the incomplete citation in the first paragraph of 2.1.4 is likely to > be inconsistent with not requiring DNSNRs at each name (including those > unsecure delegations). I'll update that. > Also, the presentation format of the hash value is inconsistent > between 2.1.2 (third paragraph) and 2.2. I don't see that, could you give me a pointer ? Thanks, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 27 12:50:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28192 for ; Tue, 27 Jul 2004 12:50:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpV8D-0006uv-JY for namedroppers-data@psg.com; Tue, 27 Jul 2004 16:48:49 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpV8C-0006uf-Df for namedroppers@ops.ietf.org; Tue, 27 Jul 2004 16:48:48 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i6RGm4C0009117 for ; Tue, 27 Jul 2004 12:48:04 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i6RGlXma002265 for ; Tue, 27 Jul 2004 12:47:33 -0400 (EDT) From: "Scott Rose" To: "DNSEXT WG" Subject: RE: NSEC2 01 Date: Tue, 27 Jul 2004 12:47:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Samuel Weiler > > I'm not convinced that the wildcard discussion/example is correct. > Perhaps Ed Lewis or Bob Halley can comment? > The draft authors would be better able to answer, but from my take- I'm guessing it's the part about response construction. In the example, I don't know why 2) non-existance of b.c.d.e. is there. Shouldn't the EXIST RR and subsequent NSEC2 RR show who the closest encloser is? That's how the current DNSSECbis spec does it. The server only needs to provide: 1. proof that the exact name doesn't exist 2. proof that there isn't a wildcard at the closest encloser. One that could have been expanded to provide a postive response. In this case, there is a EXIST RR to show the closest encloser. In some cases, that isn't necessary, as there will be RRs at the closest encloser. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 27 15:16:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08623 for ; Tue, 27 Jul 2004 15:16:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpXMF-000PVU-78 for namedroppers-data@psg.com; Tue, 27 Jul 2004 19:11:27 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpXMD-000PVB-Rn for namedroppers@ops.ietf.org; Tue, 27 Jul 2004 19:11:26 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6RJ8dmR005165 for ; Tue, 27 Jul 2004 15:08:39 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAqlayVj; Tue, 27 Jul 04 15:08:01 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id i6RJ8ixB017822; Tue, 27 Jul 2004 15:08:45 -0400 (EDT) Date: Tue, 27 Jul 2004 15:08:44 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Roy Arends cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thanks for the clarifications. And thanks for your note on Monday comparing NSEC2 and NSEC3. I'm looking forward to reading -01. Perhaps the reason I was confused starts with this line in Section 2: The DNSNR resource record lists RR types present at the DNSNR RR's ownername. If the DNSNR owner name is a hash, this isn't quite true. And this line in 2.1.4: The value of the Next Owner Name field in the last DNSNR record in the zone is the name of the zone apex (the ownername of the zone's SOA RR). Which implies that you're retaining the old (non-hashed) canonical ordering. Perhaps this doc needs the same thing I suggested for NSEC2, a high-level description of what's changing. It needs to be very, very explicit that you may or may not have NSEC3's at the same names as other records. Like his doc, there needs to be a discussion of what happens when the salt or hash algorithms change. > Per-span, I'll make that clear. You need to be explicit, then, that it's per-span in the (possibly) hashed namespace, which means the names covered by a single NSEC3 will vary depending on the hash algorithm and salt chosen. If you have some spans opt-in and some opt-out, this means the names in the "protected" space will vary depending on the salt and hash algorithm. This is a very interesting property, though it makes my head spin. Thinking about "perfect hash functions" from the land of data structures is leading me to wonder if one can create a hash algorithm and salt such that you can force a set of names (ie. all of the unsecured delegations in your zone) to be in one span, so you can mark only that one span as opt-in yet secure the rest of the zone. > > Also, the presentation format of the hash value is inconsistent > > between 2.1.2 (third paragraph) and 2.2. > > I don't see that, could you give me a pointer ? I think I misread this the first time, and then I didn't even correctly describe the problem I thought I saw. (I thought 2.1.2 said the salt was presented in base32.) In any case, the third paragraph of 2.1.2 is still unclear. It reads as: ... the hash function .... is presented by a base32 value. I think you mean that the owner name and next owner name fields are in base32, but that's not what the sentence says. (Since the hash function field is an unsigned integer, per 2.2.) Again, I'm looking forward to seeing the next version. I'd also really like to see a discussion of wildcard handling, as Ben suggested. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 27 17:42:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15207 for ; Tue, 27 Jul 2004 17:42:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpZa9-000A8S-1l for namedroppers-data@psg.com; Tue, 27 Jul 2004 21:33:57 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpZa8-000A80-1Y for namedroppers@ops.ietf.org; Tue, 27 Jul 2004 21:33:56 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6RLV9gT014834 for ; Tue, 27 Jul 2004 17:31:09 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAOKaa6C; Tue, 27 Jul 04 17:30:59 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id i6RLWMa4024457; Tue, 27 Jul 2004 17:32:22 -0400 (EDT) Date: Tue, 27 Jul 2004 17:32:22 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: DNSEXT WG cc: Edward Lewis Subject: RE: NSEC2 01 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I'm not convinced that the wildcard discussion/example is correct. > > I'm guessing it's the part about response construction. In the > example, I don't know why 2) non-existance of b.c.d.e. is there. > Shouldn't the EXIST RR and subsequent NSEC2 RR show who the closest > encloser is? That's how the current DNSSECbis spec does it. The > server only needs to provide: I thought any label stopped wildcard processing. Meaning you'd have to prove that a.b.c.d.e isn't there (Section 5, item a) and that there's no *.b.c.d.e (not listed), but that the other items listed in Section 5 don't need to be proven. I'm not certain about this, which is why I wanted our wildcard experts to speak up. I also don't understand where EXIST records must be inserted into a zone. Perhaps the document editor would clarify this? For what it's worth, Section 3 probably needs to say something about the EXIST RR presentation format. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 28 03:52:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11959 for ; Wed, 28 Jul 2004 03:52:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bpj8B-0001Ag-O6 for namedroppers-data@psg.com; Wed, 28 Jul 2004 07:45:43 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bpj8A-0001AB-1l for namedroppers@ops.ietf.org; Wed, 28 Jul 2004 07:45:42 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 80239AC8D; Wed, 28 Jul 2004 09:45:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 7469EAC8B; Wed, 28 Jul 2004 09:45:39 +0200 (CEST) Date: Wed, 28 Jul 2004 09:45:39 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Samuel Weiler Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 27 Jul 2004, Samuel Weiler wrote: > Thanks for the clarifications. And thanks for your note on Monday > comparing NSEC2 and NSEC3. I'm looking forward to reading -01. > > Perhaps the reason I was confused starts with this line in Section 2: > > The DNSNR resource record lists RR types present at the DNSNR RR's > ownername. Ah yes, I tried to generalise. I will rewrite that. > If the DNSNR owner name is a hash, this isn't quite true. And this > line in 2.1.4: > > The value of the Next Owner Name field in the > last DNSNR record in the zone is the name of the zone apex (the > ownername of the zone's SOA RR). > > Which implies that you're retaining the old (non-hashed) canonical > ordering. Yes. The paragraph you are referring to starts with "If the Hash Function Field has value 0,", which means that the ownernames of the NSEC3 records are not hashed. > Perhaps this doc needs the same thing I suggested for > NSEC2, a high-level description of what's changing. It needs to be > very, very explicit that you may or may not have NSEC3's at the same > names as other records. Okay. > Like his doc, there needs to be a discussion > of what happens when the salt or hash algorithms change. The revision will be similar to dnssec-bis-proto o Zone signing - Including NSEC3 RRs in a Zone - Example of a Secure Zone o Serving - Including NSEC3 RRs In a Response - Example DNSSEC-ter Responses o Resolving - Response Caching o Authenticating DNS Responses - Authenticated Denial of Existence - Authentication Example > > Per-span, I'll make that clear. > > You need to be explicit, then, that it's per-span in the (possibly) > hashed namespace, which means the names covered by a single NSEC3 will > vary depending on the hash algorithm and salt chosen. If you have > some spans opt-in and some opt-out, this means the names in the > "protected" space will vary depending on the salt and hash algorithm. > This is a very interesting property, though it makes my head spin. My apologies, it is Per-Zone. Per-span does not work. Due to the pre-image resistence of hash-functions it would be hard to augur which span covers what qname, therefor the property needs to be applied to all NSEC3 in a zone, not independantly. Plain ownernames (as opposed to hashed owner names) do not have pre-image resistance, so the requirement could be relaxed here, but then this proposal becomes very complex. I'll make it explicitly "Per-Zone". > Thinking about "perfect hash functions" from the land of data > structures is leading me to wonder if one can create a hash algorithm > and salt such that you can force a set of names (ie. all of the > unsecured delegations in your zone) to be in one span, so you can mark > only that one span as opt-in yet secure the rest of the zone. This is very hard, due to the same issues as I've written above. A workaround can be to query twice, but that is very ugly. It is far more easy to declare it per-zone and be done with. If that would impose irreconcilable constraints to a security policy, then the alternative would be to not use it at all. > > > Also, the presentation format of the hash value is inconsistent > > > between 2.1.2 (third paragraph) and 2.2. > > > > I don't see that, could you give me a pointer ? > > I think I misread this the first time, and then I didn't even > correctly describe the problem I thought I saw. (I thought 2.1.2 > said the salt was presented in base32.) In any case, the third > paragraph of 2.1.2 is still unclear. It reads as: > > ... the hash function .... is presented by a base32 value. > > I think you mean that the owner name and next owner name fields are in > base32, but that's not what the sentence says. (Since the hash > function field is an unsigned integer, per 2.2.) Ah, thanks. Will fix. > Again, I'm looking forward to seeing the next version. I'd also > really like to see a discussion of wildcard handling, as Ben > suggested. The wildcard handling in Bens draft is needed because NSEC2 obscures empty-non-terminals, and therefor introduces EXIST. That makes handling of wildcards different then current NSEC. NSEC3 handles wildcard exactly as NSEC does, since empty non-terminals are not obscured. I will put in a note saying that, but I do not see the purpose of discussing wildcard handling when it is exactly as NSEC. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 28 15:13:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26812 for ; Wed, 28 Jul 2004 15:13:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BptkT-000Bku-In for namedroppers-data@psg.com; Wed, 28 Jul 2004 19:05:57 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BptkA-000BiZ-DW for namedroppers@ops.ietf.org; Wed, 28 Jul 2004 19:05:38 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i6SJ5X9a022817 for ; Wed, 28 Jul 2004 21:05:34 +0200 (CEST) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) with ESMTP id i6SJ5WQM022786 for ; Wed, 28 Jul 2004 21:05:32 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) id i6SJ5Veq022785 for namedroppers@ops.ietf.org; Wed, 28 Jul 2004 21:05:31 +0200 Date: Wed, 28 Jul 2004 21:05:31 +0200 From: Miek Gieben To: namedroppers Subject: dictionary attack on nameservers Message-ID: <20040728190530.GA22758@atoom.net> Mail-Followup-To: namedroppers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello, After seeing much discussion about NSEC2/3 and God knows what, I deceided to try something completely different. How long would it take to do a dictionary attack on the .NL zone? And thereby receiving almost the entire .NL zone without doing an actual AXFR (nor walking the NSEC chain if NL would do DNSSEC). I've downloaded 2 dictionary files (apt-get install wdutch wbritish-large). These are my dictionaries to attack a nameserver. The dutch and british dictionary contain around 220,000 words. A word generator could also be written, which would generate sensible (would be) domain names. Another small (perl) program walks through theses words. and queries a NL nameserver. NX domain replies are stored in a seperate file, valid replies are stored in another. Thus I've written 2 trivial tools in about half an hour, I downloaded some dictionaries and I was ready to query a NL server. Total preparation time: 1 hour. [ I only tried the NL dictionary, I'm to impatient to wait a whole day to try all my words... So the calculations may be a bit off, but general picture should still be correct. ] Next I fired up the tool and waited. After 46 minutes the whole NL dictionary was used up. And I had a partial NL zone. Some numbers: started: 10:32 finished: 11:18 total running time: 46 minutes 229360 words in 46 minutes, 4986 words/minute. This yieled 44886 domain names. Which is a succes rate of 19.57% (estimate) (of the 229360 words) (there are lies and there is statistics, but 20% of 4986 is about 1000. So you get about 1000 valid domains/minute by doing this). NL has 1 million domain names, so this gives me only about 5 percent of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~= 15 hours), I should get almost the whole NL zone. I haven't look into this but 80%, maybe 90% sure looks feasible. And the better the dictionary, the better the results of course. Also the attack is highly parallel, 2 computers querying 2 different nameserves, would cut this time in half. So within a day you can get an AXFR of any zone out there (the bigger the zone, the more hits you get, the more accurate your "AXFR" will be). So my question right now is: Why is so much effort pumped in to a new NSEC solution for DNSSEC when people can walk DNS zones so easily right now? Btw, I will be happy to try this out on other TLD's out there :-) Regards, Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 28 16:16:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01973 for ; Wed, 28 Jul 2004 16:16:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpulE-000Iox-F3 for namedroppers-data@psg.com; Wed, 28 Jul 2004 20:10:48 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bpul3-000Ini-S1 for namedroppers@ops.ietf.org; Wed, 28 Jul 2004 20:10:38 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i6SKAbrc009668 for ; Wed, 28 Jul 2004 20:10:37 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i6SKAbu9009665 for namedroppers@ops.ietf.org; Wed, 28 Jul 2004 20:10:37 GMT Date: Wed, 28 Jul 2004 20:10:37 +0000 From: bmanning@vacation.karoshi.com To: namedroppers Subject: Re: dictionary attack on nameservers Message-ID: <20040728201037.GB9629@vacation.karoshi.com.> References: <20040728190530.GA22758@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040728190530.GA22758@atoom.net> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > So within a day you can get an AXFR of any zone out there (the bigger > the zone, the more hits you get, the more accurate your "AXFR" will > be). So my question right now is: > > Why is so much effort pumped in to a new NSEC solution for DNSSEC when > people can walk DNS zones so easily right now? GACK!!! would you stop telling people how some of us enumerate thier zones when AXFR is blocked and they don't make the zone contents available in other ways (ftp for example). :) --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 28 16:28:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02501 for ; Wed, 28 Jul 2004 16:28:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bpuyv-000KM8-P1 for namedroppers-data@psg.com; Wed, 28 Jul 2004 20:24:57 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bpuyl-000KL9-2v for namedroppers@ops.ietf.org; Wed, 28 Jul 2004 20:24:47 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6SKM0SU016290 for ; Wed, 28 Jul 2004 16:22:00 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAotaOZF; Wed, 28 Jul 04 16:21:58 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id i6SKNNAw022694; Wed, 28 Jul 2004 16:23:23 -0400 (EDT) Date: Wed, 28 Jul 2004 16:23:23 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Miek Gieben cc: namedroppers Subject: Re: dictionary attack on nameservers In-Reply-To: <20040728190530.GA22758@atoom.net> Message-ID: References: <20040728190530.GA22758@atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Good work. Interesting result. > 229360 words in 46 minutes, 4986 words/minute. > > This yieled 44886 domain names. Which is a succes rate of 19.57% > (estimate) (of the 229360 words) > > (there are lies and there is statistics, but 20% of 4986 is about > 1000. So you get about 1000 valid domains/minute by doing this). > > > NL has 1 million domain names, so this gives me only about 5 percent > of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~= > 15 hours), I should get almost the whole NL zone. This logic is bogus. The density of hits with dictionary words is probably greater than the density of hits with other namespaces (like pairs of words). While 240K names yielded 45K hits, you'll have to try far more than 5M names to hit all 1M names in the zone. For example, if you test the set of all dictionary names with 123 concatenated onto them, (ie. mortgage123.nl), you'll test the same number of names as you did in your experiment so far, but get far, far fewer hits. Even so, some of those names exist in the zone, and absent some a priori method of predicting which ones do, you have to test them all to find which ones do. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 28 17:09:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05069 for ; Wed, 28 Jul 2004 17:09:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpvdL-00003K-4b for namedroppers-data@psg.com; Wed, 28 Jul 2004 21:06:43 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpvcW-000Pv2-BF for namedroppers@ops.ietf.org; Wed, 28 Jul 2004 21:05:52 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i6SL5mUw023685 for ; Wed, 28 Jul 2004 23:05:48 +0200 (CEST) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) with ESMTP id i6SL5lu7025054 for ; Wed, 28 Jul 2004 23:05:47 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) id i6SL5lhJ025051 for namedroppers@ops.ietf.org; Wed, 28 Jul 2004 23:05:47 +0200 Date: Wed, 28 Jul 2004 23:05:47 +0200 From: Miek Gieben To: namedroppers Subject: Re: dictionary attack on nameservers Message-ID: <20040728210546.GA24838@atoom.net> Mail-Followup-To: namedroppers References: <20040728190530.GA22758@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 28 Jul, @22:23, Samuel wrote in "Re: dictionary attack on names ..."] > Good work. Interesting result. > > > 229360 words in 46 minutes, 4986 words/minute. > > > > This yieled 44886 domain names. Which is a succes rate of 19.57% > > (estimate) (of the 229360 words) > > > > (there are lies and there is statistics, but 20% of 4986 is about > > 1000. So you get about 1000 valid domains/minute by doing this). > > > > > > NL has 1 million domain names, so this gives me only about 5 percent > > of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~= > > 15 hours), I should get almost the whole NL zone. > > This logic is bogus. The density of hits with dictionary words is well, as I said, statistics == lies. The main point of my post is that I can enumerate (for +/- 90%) a zone in 24 hours, even if AXFR is blocked. [ The people interested in this kind of information certainly don't mind they can only get 90%. And btw, you really have a hard time blocking this... ] So do we want nsec2/3/X to close down the remaining 10% or do we say: we can live with enumeration in DNSSEC because even in the DNS people can walk our zone? grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 28 17:09:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05090 for ; Wed, 28 Jul 2004 17:09:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpvdZ-000068-3K for namedroppers-data@psg.com; Wed, 28 Jul 2004 21:06:57 +0000 Received: from [192.114.22.3] (helo=odyssey.isoc.org.il) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpvcT-000Puj-HC for namedroppers@ops.ietf.org; Wed, 28 Jul 2004 21:05:50 +0000 Received: from [127.0.0.1] (barvaz.cc.biu.ac.il [132.70.10.1]) by odyssey.isoc.org.il (8.12.9/8.12.6) with ESMTP id i6SL5dU7004811; Thu, 29 Jul 2004 00:05:39 +0300 Message-ID: <41081522.5000001@isoc.org.il> Date: Thu, 29 Jul 2004 00:05:38 +0300 From: Doron Shikmoni User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miek Gieben CC: namedroppers Subject: Re: dictionary attack on nameservers References: <20040728190530.GA22758@atoom.net> In-Reply-To: <20040728190530.GA22758@atoom.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Miek Gieben wrote: >NL has 1 million domain names, so this gives me only about 5 percent >of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~= >15 hours), I should get almost the whole NL zone. > Could you please explain how you infer this? Thanks, Doron -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 28 17:24:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06468 for ; Wed, 28 Jul 2004 17:23:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpvqA-0001ho-M1 for namedroppers-data@psg.com; Wed, 28 Jul 2004 21:19:58 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bpvq0-0001gb-5Z for namedroppers@ops.ietf.org; Wed, 28 Jul 2004 21:19:48 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.191); Wed, 28 Jul 2004 14:19:47 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 Jul 2004 14:19:47 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 Jul 2004 14:19:46 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 28 Jul 2004 14:19:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: dictionary attack on nameservers Date: Wed, 28 Jul 2004 14:19:45 -0700 Message-ID: Thread-Topic: dictionary attack on nameservers Thread-Index: AcR054bmb1warlaxS/yMXaG85l6szgAAMFSA From: "Christian Huitema" To: "Miek Gieben" , "namedroppers" X-OriginalArrivalTime: 28 Jul 2004 21:19:16.0089 (UTC) FILETIME=[89797690:01C474E8] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > [ The people interested in this kind of information certainly don't > mind they can only get 90%. And btw, you really have a hard time > blocking this... ] There are many other ways to achieve this result. You could also bang your dutch dictionary words one by one against a bunch of search engines, and parse the pages for HTTP URL that belong to the .NL domain. You will very quickly get several thousand names, including the likes of "example123.nl"... -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 28 19:06:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13880 for ; Wed, 28 Jul 2004 19:06:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpxRV-000Dxg-5d for namedroppers-data@psg.com; Wed, 28 Jul 2004 23:02:37 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpxRJ-000DvW-Q5 for namedroppers@ops.ietf.org; Wed, 28 Jul 2004 23:02:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0145C13DF0 for ; Wed, 28 Jul 2004 23:02:25 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Miek Gieben of "Wed, 28 Jul 2004 21:05:31 +0200." <20040728190530.GA22758@atoom.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 28 Jul 2004 23:02:24 +0000 Message-Id: <20040728230225.0145C13DF0@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk miek wrote: > ..., I should get almost the whole NL zone. I haven't look into this > but 80%, maybe 90% sure looks feasible. And the better the dictionary, > the better the results of course. Also the attack is highly parallel, > 2 computers querying 2 different nameserves, would cut this time in > half. actually, if you have bind8 or bind9 and if your operating system has kernel-visible pthreads, you can parallelize using the "irs" interface. see "bind8/contrib/manyhosts/" for an example of how altavista used to postprocess its web logs back in the days before google. (so, you don't actually need two computers to parallelize this function.) > So within a day you can get an AXFR of any zone out there (the bigger > the zone, the more hits you get, the more accurate your "AXFR" will > be). So my question right now is: > > Why is so much effort pumped in to a new NSEC solution for DNSSEC when > people can walk DNS zones so easily right now? all i can say is, humans are involved, and humans love complexity, and humans hate to be told that they're solving the wrong problem. let's have a look at the ol' archives, shall we? From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC Date: Sat, 22 May 2004 16:34:39 +0000 ... What *I* think, since you mentioned it, is that TLD holders who fear enumeration think that restricting AXFR is actually preventing enumeration, and that if they'd spend a few years in the trenches against spammers and data miners they would come to the conclusion that "all useful malevolent forms of enumeration are already possible and are already being done" and would then conclude that a one-decade DNSSEC is better than a two-decade DNSSEC, given that all other things are equal. or, even more succinct: From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC Date: Sun, 23 May 2004 21:28:02 +0000 > I am illustrating that Paul cannot enumerate the zone either > accurately or completely. i never said i could. what i said was that i could get a complete useful enumeration, containing everything a spammer or marketroid would need in order to make "the bad use" of whois that ccTLD's supposedly don't want made. yet, interest in NSEC2 (and now NSEC3) persists. thank you for proving that useful enumeration does not depend on AXFR or NSEC, but i think that the proponents of NSEC2 (and now NSEC3) believed my assertions on this point and will not be swayed by your evidence. they do not doubt that "all useful enumerations are already possible", but they live in a world where they have to be seen "doing something about the problem". because of the way IETF works, that probably means "we all have to be seen doing something about the problem" even though, as first stated, and now proven, there either is no problem, or the problem doesn't come from NSEC. > Btw, I will be happy to try this out on other TLD's out there :-) i suggest that you do them all. it won't change anything -- we'll still rush headlong into another decade of incremental complexity in dnssec -- but it will be satisfying to have the true purpose of that complexity exposed in advance, for all to see. note-- ISC will begin work on NSEC3 as soon as there's funding/interest in it. the views expressed here are personal, and do not reflect isc's commitment to implement whatever the community decides upon. paul -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 28 22:16:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23196 for ; Wed, 28 Jul 2004 22:16:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq0N5-0009am-OM for namedroppers-data@psg.com; Thu, 29 Jul 2004 02:10:15 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq0Mu-0009ZE-FD for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 02:10:04 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id D77D01C0BF; Thu, 29 Jul 2004 11:04:33 +0900 (JST) To: miekg@atoom.net Cc: pekkas@netcore.fi, namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface In-Reply-To: Your message of "Tue, 27 Jul 2004 13:06:31 +0200" <20040727110631.GB14975@atoom.net> References: <20040727110631.GB14975@atoom.net> X-Mailer: Cue version 0.8 (040717-1035/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040729020433.D77D01C0BF@coconut.itojun.org> Date: Thu, 29 Jul 2004 11:04:33 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > [On 27 Jul, @11:49, Pekka wrote in "getaddrinfo/TTL and resolver a ..."] > > Hi, > > > > draft-gieben-resolver-application-interface-00.txt sketches what kind > > of information the application and the resolver could have through an > > interface. This has been discussed in dnsext at least in Feb 2004. > > What has been the outcome? > > nothing yet, we had a lot of discussion about it, but nothing > materialized out of it. > > Personally I think some other questions also need to be answered, > like: > > o what service does the DNS actually provide? > (it's a naming service, but application seem to want to know > more and more about the resolution process. Esp. with DNSSEC). > > o where do applications start and resolvers end? > A seen from the text below, apps now want to know TTLs. Where > does it stop? > > o Each "application" (IPSEC for instance) has different (security) needs, > and has a different set of "local policy" rules. What kind of > interface is needed to allow for an application to make it's > own policy decisions? > > Following this line of thinking we could come to the conclussion that > an application wants to know the entire resolving chain, from the root > down to the leave node. But when your local resolver does caching > this might now be available... so there you go.... > > > The reason why I got interested was because section 8.2 of > > draft-ietf-dnsop-ipv6-dns-issues-08.txt (see below) shows that the > > application should be able to be aware of the TTL of the records, > > easily, so that it could discard expired records from the memory if > > it's built around in such a way that it would be feasible to do so. > > As it is, the applications typically query a name when they start and > > use it forever, irregardless of the TTL. (And if the > > application-resolver interface needs work in any case....) > > > > IMHO, it seem to be worth adding the TTL information to getaddrinfo() > > functions. I object to change getaddrinfo(). getaddrinfo() deployment is ongoing and i do not want two variants of getaddrinfo - one with TTL, one without TTL, depending on platforms. it just leads to confusion with small benefit just for the sake of small set of users. if a user wants TTL info, she can use getrrsetbyname(). itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 03:08:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20758 for ; Thu, 29 Jul 2004 03:08:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq4xE-000N7K-6o for namedroppers-data@psg.com; Thu, 29 Jul 2004 07:03:52 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq4x3-000N3G-I1 for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 07:03:41 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id D4CD1AC8D; Thu, 29 Jul 2004 09:03:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id CEF80AC8B; Thu, 29 Jul 2004 09:03:39 +0200 (CEST) Date: Thu, 29 Jul 2004 09:03:39 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Miek Gieben Cc: namedroppers Subject: Re: dictionary attack on nameservers In-Reply-To: <20040728210546.GA24838@atoom.net> Message-ID: References: <20040728190530.GA22758@atoom.net> <20040728210546.GA24838@atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 28 Jul 2004, Miek Gieben wrote: > The main point of my post is that I can enumerate (for +/- 90%) a zone > in 24 hours, even if AXFR is blocked. > > [ The people interested in this kind of information certainly don't > mind they can only get 90%. And btw, you really have a hard time > blocking this... ] > > So do we want nsec2/3/X to close down the remaining 10% or do we say: > we can live with enumeration in DNSSEC because even in the DNS people > can walk our zone? I have seen no claims that NSEC2/3/X can prevent zone walking or enumeration. The goal is to make zone walking more expensive. The lock on my front door does not prevent break-ins. Its goal is to make break-ins more expensive. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 03:53:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24304 for ; Thu, 29 Jul 2004 03:53:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq5fe-0001mC-Fa for namedroppers-data@psg.com; Thu, 29 Jul 2004 07:49:46 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq5fT-0001kz-8c for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 07:49:35 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i6T7nYYk004194 for ; Thu, 29 Jul 2004 09:49:34 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i6T7nX910804 for ; Thu, 29 Jul 2004 09:49:33 +0200 (MEST) Message-Id: <200407290749.i6T7nX910804@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers Subject: Re: dictionary attack on nameservers In-reply-to: Your message of "Wed, 28 Jul 2004 23:05:47 +0200." <20040728210546.GA24838@atoom.net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10801.1091087372.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Thu, 29 Jul 2004 09:49:33 +0200 From: Peter Koch X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Miek Gieben wrote: > The main point of my post is that I can enumerate (for +/- 90%) a zone > in 24 hours, even if AXFR is blocked. thanks for this effort, hard data is a Good Thing. > [ The people interested in this kind of information certainly don't > mind they can only get 90%. And btw, you really have a hard time > blocking this... ] "The people" have different reasons, some of them want a 100% copy and some of them want near-realtime "diffs". And it's always the last 10% that makes 90% of the price ... -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 04:11:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25127 for ; Thu, 29 Jul 2004 04:11:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq5vz-00048n-Ke for namedroppers-data@psg.com; Thu, 29 Jul 2004 08:06:39 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq5vo-00047p-Kv for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 08:06:28 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i6T86OGh032027 for ; Thu, 29 Jul 2004 10:06:24 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i6T86OEX032026 for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 10:06:24 +0200 (CEST) (envelope-from ted) Message-Id: <200407290806.i6T86OEX032026@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Thu, 29 Jul 2004 10:06:24 +0200 In-Reply-To: "Roy Arends's message as of Jul 29, 9:10" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers Subject: Re: dictionary attack on nameservers X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Roy Arends, on Jul 29, 9:10, in "Re: dictionary attac ..."] > I have seen no claims that NSEC2/3/X can prevent zone walking or > enumeration. The goal is to make zone walking more expensive. > > The lock on my front door does not prevent break-ins. Its goal is to make > break-ins more expensive. When talking "more expensive", it is relevant to weight: 1. how much more expensive 2. the cost of the lock 3. the value of what is being protected ad 1. It has being shown (several times) that (90-99%) zone enumeration without AXFR is simple and dirt cheap. Most of us know that both spammers and domainname-traders are doing this already for years on a daily basis with all TLDs that have blocked AXFR. ad 2. The cost of the proposed lock (NSEC2/3/X) means a new protocol change, which is rather expensive. ad 3. We are talking about the protection of one little aspect (100 against 99% enumeration) of otherwise public information. It has also been argued ((several times) that for most, if not all, evil usage of zone-enumeration 90+ % enumeration suffices. To me it seems that in this case the weighting is completely out of balance. Regards, -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 04:18:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25491 for ; Thu, 29 Jul 2004 04:18:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq63o-0004pc-Jr for namedroppers-data@psg.com; Thu, 29 Jul 2004 08:14:44 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq63e-0004p4-3U for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 08:14:34 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i6T8E7J6004414; Thu, 29 Jul 2004 01:14:07 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i6T8DxJR028685; Thu, 29 Jul 2004 10:14:01 +0200 (MEST) Date: Thu, 29 Jul 2004 00:49:41 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface To: Jun-ichiro itojun Hagino Cc: miekg@atoom.net, pekkas@netcore.fi, namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu In-Reply-To: "Your message with ID" <20040729020433.D77D01C0BF@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I object to change getaddrinfo(). getaddrinfo() deployment is ongoing > and i do not want two variants of getaddrinfo - one with TTL, one > without TTL, depending on platforms. it just leads to confusion > with small benefit just for the sake of small set of users. > if a user wants TTL info, she can use getrrsetbyname(). AFAIK getrrsetbyname() isn't a standard so I don't know how good portability one can get for applications using it. On the other hand, introducing an new ai_ttl field at the end of struct addrinfo can be done without any effect on binaries (since the field offsets of the other fields do not change, and freeaddrinfo() will free the correct size structure). Applications which want to use ai_ttl would then do call getaddrinfo... #ifdef _GETADDRINFO_AI_TTL ttl = ai->ai_tll; #else ttl = 30; /* Or some other constant */ #endif While this is more painful than if we'd included ai_ttl from the start, it seems to be less painful than standardizing getrrsetbyname() to ensure portability of that interface across platforms. Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 04:22:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25812 for ; Thu, 29 Jul 2004 04:22:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq68d-0005IZ-FK for namedroppers-data@psg.com; Thu, 29 Jul 2004 08:19:43 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq68S-0005HL-Ow for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 08:19:33 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i6T8JTKr032157 for ; Thu, 29 Jul 2004 10:19:29 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i6T8JTJw032156 for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 10:19:29 +0200 (CEST) (envelope-from ted) Message-Id: <200407290819.i6T8JTJw032156@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Thu, 29 Jul 2004 10:19:29 +0200 In-Reply-To: "Peter Koch's message as of Jul 29, 9:54" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers Subject: Re: dictionary attack on nameservers X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Peter Koch, on Jul 29, 9:54, in "Re: dictionary attac ..."] > "The people" have different reasons, some of them want a 100% copy and some > of them want near-realtime "diffs". And it's always the last 10% that makes > 90% of the price ... I am probably naive, so please enlighten me: for what "people" would this last few percents (which probably consists mainly of short-lived bogus domains like spammer1234.tld) be of such high interest? Certainly not for the spammer, domainname-grabber, data-miner, etc type of "people"? Regards, -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 04:32:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26313 for ; Thu, 29 Jul 2004 04:32:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq6IY-0006I9-N4 for namedroppers-data@psg.com; Thu, 29 Jul 2004 08:29:58 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq6IO-0006H9-1Z for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 08:29:48 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i6T8TVrc011292; Thu, 29 Jul 2004 08:29:31 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i6T8TULK011289; Thu, 29 Jul 2004 08:29:30 GMT Date: Thu, 29 Jul 2004 08:29:30 +0000 From: bmanning@vacation.karoshi.com To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC implementation status ? Message-ID: <20040729082930.GB11253@vacation.karoshi.com.> References: <6.1.0.6.2.20040723091320.02bdee68@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.0.6.2.20040723091320.02bdee68@localhost> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > One of the agenda items at the WG meeting is to report on status/plans > of DNSSECbis implementations. The purpose is to facilitate, collaboration > and testing. > I will be making the presentation, if you have any DNSSECbis related > implementation done or planning on one please send me an email about > your work. along these lines, if there folks who wish to discuss or participate in impromptu interoperability testing, a room is available -outside- the normal IETF agenda for more in-depth interactions. For details, please let me know. --bill manning -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 04:46:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27005 for ; Thu, 29 Jul 2004 04:46:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq6Wh-0007mK-7g for namedroppers-data@psg.com; Thu, 29 Jul 2004 08:44:35 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq6WW-0007kg-8T for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 08:44:24 +0000 Received: from wds1.nominet.org.uk (wds1.dhcp.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id 5FF92E7E4D; Thu, 29 Jul 2004 09:44:23 +0100 (BST) In-Reply-To: <200407290806.i6T86OEX032026@open.nlnetlabs.nl> To: namedroppers Cc: ted@NLnetLabs.nl (Ted Lindgreen) Subject: Re: dictionary attack on nameservers MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Jay Daley Date: Thu, 29 Jul 2004 09:44:52 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 07/29/2004 09:44:53 AM, Serialize complete at 07/29/2004 09:44:53 AM Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Folks Ted wrote on 29/07/2004 09:06:24: > ad 1. It has being shown (several times) that (90-99%) zone > enumeration without AXFR is simple and dirt cheap. I'm sorry to be picky but I don't think the above is true. When people register a name they use a name from a pool of possible names. As a zone grows in size people begin to exhaust the easy pools and so need to invent new pools. So the initial pools are often very short names (2, 3, 4 characters) generic words (eg music, buses, teeth) organisation/personal names but as these grow people start to invent new ones generic hyphen generic generic plus number and so on. So the smaller a zone is, the easier it is to enumerate. For small zones I can well believe a high percentage is possible. However as zones grow the problem can get significantly harder. If someone really has done this against a large zone then please let us know. If you want to test it against ours then please let me know so that we can prepare for it. Jay -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 04:54:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27362 for ; Thu, 29 Jul 2004 04:54:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq6ey-0008mV-2w for namedroppers-data@psg.com; Thu, 29 Jul 2004 08:53:08 +0000 Received: from [193.0.3.25] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq6em-0008kM-Sr for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 08:52:57 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 85C2339949D; Thu, 29 Jul 2004 10:52:56 +0200 (CEST) Message-ID: <4108BAE7.3040704@ripe.net> Date: Thu, 29 Jul 2004 10:52:55 +0200 From: "Olaf M. Kolkman" User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miek Gieben Cc: namedroppers Subject: Re: dictionary attack on nameservers References: <20040728190530.GA22758@atoom.net> <20040728210546.GA24838@atoom.net> In-Reply-To: <20040728210546.GA24838@atoom.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >So do we want nsec2/3/X to close down the remaining 10% or do we say: >we can live with enumeration in DNSSEC because even in the DNS people >can walk our zone? > > That is exactly what I think we should do first. Get the requirements on which this comunity wants to base its developments and then make the tradeoffs. See http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01237.html --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 05:08:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27896 for ; Thu, 29 Jul 2004 05:08:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq6sC-000AYu-5D for namedroppers-data@psg.com; Thu, 29 Jul 2004 09:06:48 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq6rc-000AUf-Jt for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 09:06:12 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id D09B8AC8D; Thu, 29 Jul 2004 11:06:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id C4135AC8B; Thu, 29 Jul 2004 11:06:11 +0200 (CEST) Date: Thu, 29 Jul 2004 11:06:11 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: "Olaf M. Kolkman" Cc: namedroppers Subject: consensus first, was Re: dictionary attack on nameservers In-Reply-To: <4108BAE7.3040704@ripe.net> Message-ID: References: <20040728190530.GA22758@atoom.net> <20040728210546.GA24838@atoom.net> <4108BAE7.3040704@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 29 Jul 2004, Olaf M. Kolkman wrote: > >So do we want nsec2/3/X to close down the remaining 10% or do we say: > >we can live with enumeration in DNSSEC because even in the DNS people > >can walk our zone? > > > > > > That is exactly what I think we should do first. Get the requirements > on which this comunity wants to base its developments and then make the > tradeoffs. > > See > http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01237.html The important thing is to get consensus within the WG on a few points. Most importantly: o Will current deployment plans for dnssec-bis be hurdled with nsec++. o Will deployment be feasible with dnssec-bis for _large_ tlds. If either one is a yes, lets drop nsec+. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 05:08:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27920 for ; Thu, 29 Jul 2004 05:08:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq6rg-000AVB-Vn for namedroppers-data@psg.com; Thu, 29 Jul 2004 09:06:16 +0000 Received: from [192.134.4.10] (helo=mx1.nic.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq6rV-000ATY-Hc for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 09:06:05 +0000 Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id E1D6A940A2 for ; Thu, 29 Jul 2004 11:06:04 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id E53C29406A for ; Thu, 29 Jul 2004 11:06:03 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id i6T963jI1126052 for ; Thu, 29 Jul 2004 11:06:03 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id C8F86102B6; Thu, 29 Jul 2004 11:06:03 +0200 (CEST) Date: Thu, 29 Jul 2004 11:06:03 +0200 From: Stephane Bortzmeyer To: namedroppers Subject: Re: dictionary attack on nameservers Message-ID: <20040729090603.GA26384@nic.fr> References: <20040728190530.GA22758@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040728190530.GA22758@atoom.net> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Jul 28, 2004 at 09:05:31PM +0200, Miek Gieben wrote a message of 68 lines which said: > I've downloaded 2 dictionary files (apt-get install wdutch > wbritish-large). Do note that this attack works well against ccTLD (where almost all the domain names are in the national(s) language(s) or in english) but not against gTLD, where domain names are in hundreds of different languages or are made by companies like Interbrand and do not appear in any dictionary. > NL has 1 million domain names, so this gives me only about 5 percent > of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~= > 15 hours), I should get almost the whole NL zone. I am very skeptical about that. The remaining domain names are the most difficult to guess (Huitema's attack would be better because you can match on a partial word.) > this but 80%, maybe 90% sure looks feasible. I do not believe it. > Btw, I will be happy to try this out on other TLD's out there :-) Do not hesitate to try with ".fr", which is much smaller, and tell us the percentage you get with the wfrench dictionary in Debian. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 05:14:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28241 for ; Thu, 29 Jul 2004 05:14:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq6y7-000BK5-PB for namedroppers-data@psg.com; Thu, 29 Jul 2004 09:12:55 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq6xw-000BIy-RZ for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 09:12:45 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 0B168E7E8A; Thu, 29 Jul 2004 10:12:43 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Message-Id: <20040729091243.0B168E7E8A@mx1.nominet.org.uk> Date: Thu, 29 Jul 2004 10:12:43 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Miek Gieben writes: > Why is so much effort pumped in to a new NSEC solution for DNSSEC when > people can walk DNS zones so easily right now? I can't speak for everyone, but we (Nominet) are advised that we have a responsibility to protect the confidentiality of data in the .uk zones, even if this cannot be done perfectly. Also, I use to think that, even if "NSEC+" were available, that NSEC was sufficient for {in-addr,ipv6,e164}.arpa. Now I'm not so sure. While any one zone in these hierarchies is trivially enumerable w/o NSEC, the elaboration of the aggregate trees is a bigger problem which is considerably reduced by NSEC. (Okay, maybe not so hard to elaborate e164.arpa yet by any means . . .) The reverse trees and enum may prove to be killer apps for NSEC+. Peter Koch > the last 10% that makes 90% of the price ... I think this is also a good summation. Regards Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 05:28:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28605 for ; Thu, 29 Jul 2004 05:28:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq7BQ-000CnR-FJ for namedroppers-data@psg.com; Thu, 29 Jul 2004 09:26:40 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq7BF-000CmV-MR for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 09:26:29 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id EA7B6AC8D; Thu, 29 Jul 2004 11:26:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id E9544AC8B; Thu, 29 Jul 2004 11:26:28 +0200 (CEST) Date: Thu, 29 Jul 2004 11:26:28 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Ted Lindgreen Cc: namedroppers Subject: Re: dictionary attack on nameservers In-Reply-To: <200407290806.i6T86OEX032026@open.nlnetlabs.nl> Message-ID: References: <200407290806.i6T86OEX032026@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 29 Jul 2004, Ted Lindgreen wrote: > [Quoting Roy Arends, on Jul 29, 9:10, in "Re: dictionary attac ..."] > > > I have seen no claims that NSEC2/3/X can prevent zone walking or > > enumeration. The goal is to make zone walking more expensive. > > > > The lock on my front door does not prevent break-ins. Its goal is to make > > break-ins more expensive. > > When talking "more expensive", it is relevant to weight: I did not say that the goals justify the means, nolo contendere on the validity of the details you have provided. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 05:30:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28690 for ; Thu, 29 Jul 2004 05:30:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq7D5-000CwO-IY for namedroppers-data@psg.com; Thu, 29 Jul 2004 09:28:23 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq7Cu-000CvM-Ny for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 09:28:13 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i6T9S9Vr032780 for ; Thu, 29 Jul 2004 11:28:09 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i6T9S9pV032779 for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 11:28:09 +0200 (CEST) (envelope-from ted) Message-Id: <200407290928.i6T9S9pV032779@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Thu, 29 Jul 2004 11:28:08 +0200 In-Reply-To: "Jay Daley's message as of Jul 29, 10:47" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers Subject: Re: dictionary attack on nameservers X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Jay Daley, on Jul 29, 10:47, in "Re: dictionary attac ..."] > If someone really has done this against a large zone then please let us > know. If you want to test it against ours then please let me know so that > we can prepare for it. I am not sure what you call "a large zone", so also not if .nl qualifies (it is in the top-5 or so of largest zones, but, of course, much smaller than .com). The .nl domain has some 1.3M delegations, some 30k domains are newly registered and some 5k are released per month (from data over the first few months of 2004). I know of a number of registrars who keep daily updated, and very accurate lists of registrered and returned domain names. For .nl and also for other TLDs. These guys use various techniques to keep their lists accurate and up-to-date. Although highly effective, these techniques are neither complicated, nor costly for the registrar. However, their load the .nl nameservers is significant, and thus one can easily see and determime who/what is causing it in the nameserver-traces which we routinely investigate in our testlab. As for your second question: I do not think that any preparation by your side is needed for us to "attack" your TLD, as the load of our "attack" on the .nl zone was not even noticed (but will, of course, be clearly visible in the nameserver-traces). Regards, -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 05:35:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28873 for ; Thu, 29 Jul 2004 05:35:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq7J3-000Dec-7B for namedroppers-data@psg.com; Thu, 29 Jul 2004 09:34:33 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq7Is-000Dcy-CV for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 09:34:22 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 8FAA1E7E5D; Thu, 29 Jul 2004 10:34:21 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: <200407290806.i6T86OEX032026@open.nlnetlabs.nl> Message-Id: <20040729093421.8FAA1E7E5D@mx1.nominet.org.uk> Date: Thu, 29 Jul 2004 10:34:21 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ted@NLnetLabs.nl (Ted Lindgreen) writes: > When talking "more expensive", it is relevant to weight: > > 1. how much more expensive > 2. the cost of the lock > 3. the value of what is being protected > > ad 1. It has being shown (several times) that (90-99%) zone > enumeration without AXFR is simple and dirt cheap. > Most of us know that both spammers and domainname-traders > are doing this already for years on a daily basis with > all TLDs that have blocked AXFR. > > ad 2. The cost of the proposed lock (NSEC2/3/X) means a new > protocol change, which is rather expensive. > > ad 3. We are talking about the protection of one little aspect > (100 against 99% enumeration) of otherwise public > information. It has also been argued ((several times) that > for most, if not all, evil usage of zone-enumeration 90+ % > enumeration suffices. > > To me it seems that in this case the weighting is completely out > of balance. There's a time consideration which this analysis doesn't take into account: If `perfect' snapshots (less negligible effects due to routine IXFRs) of the owner names in zones can be obtained frequently and with low latency, then new possibilites become available. It's one thing to have a photo; another to have a film. Regards Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 06:28:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00866 for ; Thu, 29 Jul 2004 06:28:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq85a-000JOi-7U for namedroppers-data@psg.com; Thu, 29 Jul 2004 10:24:42 +0000 Received: from [192.134.4.10] (helo=mx1.nic.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq85P-000JNp-Be for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 10:24:31 +0000 Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id B0BDF94018; Thu, 29 Jul 2004 12:24:30 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 92BEF94015; Thu, 29 Jul 2004 12:24:29 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id i6TAOTjI1150776; Thu, 29 Jul 2004 12:24:29 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 39F9C102B7; Thu, 29 Jul 2004 12:24:29 +0200 (CEST) Date: Thu, 29 Jul 2004 12:24:29 +0200 From: Stephane Bortzmeyer To: Paul Vixie Cc: namedroppers Subject: Re: dictionary attack on nameservers Message-ID: <20040729102429.GB26384@nic.fr> References: <20040728190530.GA22758@atoom.net> <20040728230225.0145C13DF0@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040728230225.0145C13DF0@sa.vix.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Jul 28, 2004 at 11:02:24PM +0000, Paul Vixie wrote a message of 83 lines which said: > i never said i could. what i said was that i could get a > complete useful enumeration, containing everything a spammer or > marketroid would need in order to make "the bad use" of whois > that ccTLD's supposedly don't want made. Getting domain names for spamming is one bad use, and one for which probably 50 % of the zone would be more than enough. But there are other bad uses (reverse cybersquatting is a good example, when big corporations try to find domain names looking like their trademarks in order to harass the holder). And they typically require more than 50 % of the zone. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 06:32:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01111 for ; Thu, 29 Jul 2004 06:32:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq8BD-000K1a-5a for namedroppers-data@psg.com; Thu, 29 Jul 2004 10:30:31 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq8B2-000K0k-B9 for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 10:30:20 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i6TAUGZi033735 for ; Thu, 29 Jul 2004 12:30:16 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i6TAUGjH033734 for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 12:30:16 +0200 (CEST) (envelope-from ted) Message-Id: <200407291030.i6TAUGjH033734@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Thu, 29 Jul 2004 12:30:16 +0200 In-Reply-To: "Geoffrey Sisson's message as of Jul 29, 11:36" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Geoffrey Sisson, on Jul 29, 11:36, in "Re: dictionary attac ..."] > There's a time consideration which this analysis doesn't take into > account: If `perfect' snapshots (less negligible effects due to routine > IXFRs) of the owner names in zones can be obtained frequently and with > low latency, then new possibilites become available. > > It's one thing to have a photo; another to have a film. I am affraid I have lost it now, please enlighten me: 1. the argument against enumeration is the European (and/or other) privacy legislation; 2. it is clear that 99% enumeration on a daily basis is currently practice (perhaps not desirable, but real practice); 3. NSEC may provide for 100% correct snapshots, valid in the interval between zone-updates. Do I correctly understand that you are saying that 2 is "a photo" and 3 is "a film"? And with that, must I understand the privacy-lawyer's opinion that for information, which is in the DNS for deliberate publication, "filmshots at zone-update intervals" are unacceptable, while "daily photo's" are current practice? I am affraid I have really lost it... -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 06:39:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01542 for ; Thu, 29 Jul 2004 06:39:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq8IH-000KvP-LP for namedroppers-data@psg.com; Thu, 29 Jul 2004 10:37:49 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq8I6-000KuF-Un for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 10:37:39 +0000 Received: from wds1.nominet.org.uk (wds1.dhcp.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id 5CCC1E7EB6; Thu, 29 Jul 2004 11:37:38 +0100 (BST) In-Reply-To: <200407290928.i6T9S9pV032779@open.nlnetlabs.nl> MIME-Version: 1.0 To: ted@NLnetLabs.nl (Ted Lindgreen) Cc: namedroppers Subject: Re: dictionary attack on nameservers X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Jay Daley Date: Thu, 29 Jul 2004 11:38:07 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 07/29/2004 11:38:08 AM, Serialize complete at 07/29/2004 11:38:08 AM Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ted Ted wrote on 29/07/2004 10:28:08: > I am not sure what you call "a large zone", so also not if .nl > qualifies (it is in the top-5 or so of largest zones, but, of > course, much smaller than .com). > The .nl domain has some 1.3M delegations, some 30k domains are > newly registered and some 5k are released per month (from data > over the first few months of 2004). That will do. > > I know of a number of registrars who keep daily updated, and > very accurate lists of registrered and returned domain names. > For .nl and also for other TLDs. > > These guys use various techniques to keep their lists accurate > and up-to-date. Although highly effective, these techniques are > neither complicated, nor costly for the registrar. > However, their load the .nl nameservers is significant, and thus > one can easily see and determime who/what is causing it in the > nameserver-traces which we routinely investigate in our testlab. With respect this is still anecdotal. Where is the real data? i.e. "By dictionary attack X managed to guess Y% of the 1.3m names". Jay -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 08:02:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05648 for ; Thu, 29 Jul 2004 08:02:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq9YH-00043L-RV for namedroppers-data@psg.com; Thu, 29 Jul 2004 11:58:25 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq9Y6-00042O-T7 for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 11:58:15 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i6TBwA9b034595 for ; Thu, 29 Jul 2004 13:58:10 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i6TBwAUa034594 for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 13:58:10 +0200 (CEST) (envelope-from ted) Message-Id: <200407291158.i6TBwAUa034594@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Thu, 29 Jul 2004 13:58:10 +0200 In-Reply-To: "Jay Daley's message as of Jul 29, 12:40" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers Subject: Re: dictionary attack on nameservers X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Jay Daley, on Jul 29, 12:40, in "Re: dictionary attac ..."] > > I know of a number of registrars who keep daily updated, and > > very accurate lists of registrered and returned domain names. > > For .nl and also for other TLDs. > > > > These guys use various techniques to keep their lists accurate > > and up-to-date. Although highly effective, these techniques are > > neither complicated, nor costly for the registrar. > > However, their load the .nl nameservers is significant, and thus > > one can easily see and determime who/what is causing it in the > > nameserver-traces which we routinely investigate in our testlab. > > With respect this is still anecdotal. Where is the real data? i.e. "By > dictionary attack X managed to guess Y% of the 1.3m names". Dear Jay, Thank you for calling our work "anecdotal". You dispute the existance of cybersquatters, spammers, etc. using fairly accurate lists of existing domainnames. You even dispute the possibility of those techniques, and want us to come up with a full quantitative analysis of one such technique. However, NLnet Labs is not founded (nor funded) to prove the obvious, and therefore we will not waste more time this than we have done already. For us it suffices, that: 1. with very little work we could do a dictionary attack on .nl, revieling the number of domainnames we expected (feared); 2. from work with/at the .nl registry and registrars we know that a number of registrars maintain accurate and uptodate lists of many TLDs, despite that most of these TLDs have closed AXFR many years ago; 3. from work in our testlab with traces of .nl nameservers we have seen how some of those registrars obtain part of the info in 2; 4. from other postings in this thread it is clear that others have seen various other methods to obtain good lists of registered domainnames in the current DNS even when AXFR is blocked. If you can prove, or at least provide reasonable evidence, that in a world where above already takes place, NSEC2/3/X versus NSEC makes enough of a difference to necessitate a redo of the protocol, please do so. Sofar, I've only heard about "some privacy-laywer's opinion", vague "new possibilities" that perfect against 99% accuraty could allow for (ghost-hunting), and thirdly, fear that nameservers could suffer overload from NSEC walking (which is provably incorrect: the current attack-techniques impose already a much greater load, plus that just making the zone file available via ftp is even more effective). Please explain to us why NSEC2/3/X is REALLY needed, instead of asking us to prove the obvious. -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 08:24:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06611 for ; Thu, 29 Jul 2004 08:24:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq9u7-0006zL-7Q for namedroppers-data@psg.com; Thu, 29 Jul 2004 12:20:59 +0000 Received: from [203.217.30.81] (helo=shitei.mindrot.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq9tw-0006xm-6D for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 12:20:48 +0000 Received: from mindrot.org (unknown [172.29.84.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shitei.mindrot.org (Postfix) with ESMTP id 76DF527C187; Thu, 29 Jul 2004 22:18:50 +1000 (EST) Message-ID: <4108EB24.9000504@mindrot.org> Date: Thu, 29 Jul 2004 22:18:44 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040629) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Arends Cc: Miek Gieben , namedroppers Subject: Re: dictionary attack on nameservers References: <20040728190530.GA22758@atoom.net> <20040728210546.GA24838@atoom.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > I have seen no claims that NSEC2/3/X can prevent zone walking or > enumeration. The goal is to make zone walking more expensive. > > The lock on my front door does not prevent break-ins. Its goal is to make > break-ins more expensive. This is a false analogy: the people who want to enumerate DNS zones wouldn't be spending their own money - they have zombies and botnets to do the work for them. -d -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 08:47:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07849 for ; Thu, 29 Jul 2004 08:47:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqAFE-0009O7-OS for namedroppers-data@psg.com; Thu, 29 Jul 2004 12:42:48 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqAF3-0009Lx-Fk for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 12:42:37 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id A62391FE74; Thu, 29 Jul 2004 13:42:36 +0100 (BST) Date: Thu, 29 Jul 2004 13:42:34 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ted Lindgreen , namedroppers Cc: Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: <87042250088FAB50D2B95475@[192.168.100.27]> In-Reply-To: <200407291158.i6TBwAUa034594@open.nlnetlabs.nl> References: <200407291158.i6TBwAUa034594@open.nlnetlabs.nl> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 29 July 2004 13:58 +0200 Ted Lindgreen wrote: > Please explain to us why NSEC2/3/X is REALLY needed, instead of > asking us to prove the obvious. Sorry, unless I'm dropping mail message you have not shown that over x% of the zone file can be obtained through dictionary attacks in a small amount of time, where x is a large number (let's say 90% or 95%). Mark Gieben acknowledged this in the post where he said "Statistics==Lies". You have merely shown where x is a small number, it can be obtained, and extrapolated. For the reasons posted on this list, and which indeed should be obvious, if you can find (say) 25% if (say) 10 hours, that by no means suggest you can find 90% in less than 40 hours. The reasons for the requirement for non-traversal of zones (NSEC2/NSEC3) have been expounded at great length; I don't see any purpose in repeating them again. As far as I can tell, the w/g reached consensus that there was a requirement (perhaps not one you have) but that it would not form part of DNSSECbis. You have neither demonstrated that that requirement has gone away (as even if you could demonstrate the .NL zone file can be recovered 100% accurately by dictionary attack in a small amount of time, that does not necessarily extinguish a requirement elsewhere - see comment on .com), nor have you demonstrated that your original thesis (that nearly all of the zone contents could be retrieved by dictionary attack) is true. If it's true that you don't have the resources or appetite to perform your statistical test, can I suggest you post your perl programs and methodology in detail, and let someone else demonstrate whether or not a dictionary attack can actually reveal let's say over 95% of a zone file, and the number of queries it took. The whole thesis of those proposing NSEC2/3 has been that DNSSEC should not make the situation substantially WORSE. If it is the case that existing attacks are just as easy to perform by the attacker as NSEC enumeration, then that would have some weight. We already know dictionary attacks cannot in the general case yield a complete zone. Your suggestion that they can yield a nearly complete zone (for values of nearly like 95%) for effort comparable with an NSEC enumeration is at the moment not supported by any data I have yet seen - if it is incorrect, it's probably also disprovable. If you are going to claim you have a new argument based on new data, please supply that data, not go half way then claim you are neither "founded or funded" to produce the relevant results. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 08:47:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07867 for ; Thu, 29 Jul 2004 08:47:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqAG3-0009VL-HK for namedroppers-data@psg.com; Thu, 29 Jul 2004 12:43:39 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqAFs-0009Tq-SS for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 12:43:29 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 1C9721FE74; Thu, 29 Jul 2004 13:43:28 +0100 (BST) Date: Thu, 29 Jul 2004 13:43:26 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Damien Miller , Roy Arends Cc: Miek Gieben , namedroppers , Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: <449E26FD9F3A55514799A61A@[192.168.100.27]> In-Reply-To: <4108EB24.9000504@mindrot.org> References: <20040728190530.GA22758@atoom.net> <20040728210546.GA24838@atoom.net> <4108EB24.9000504@mindrot.org> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 29 July 2004 22:18 +1000 Damien Miller wrote: > This is a false analogy: the people who want to enumerate DNS zones > wouldn't be spending their own money - they have zombies and botnets to > do the work for them. Though TBF that is the case for both dictionary attacks AND nsec enumerations. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 08:51:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08076 for ; Thu, 29 Jul 2004 08:51:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqAJR-000A7j-SN for namedroppers-data@psg.com; Thu, 29 Jul 2004 12:47:09 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqAJH-000A4z-04 for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 12:46:59 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 28B6419BAAA; Thu, 29 Jul 2004 08:38:42 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id BE0C619B984; Thu, 29 Jul 2004 08:38:41 -0400 (EDT) Received: from [192.136.136.102] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id E2892CF394; Thu, 29 Jul 2004 08:46:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20040729020433.D77D01C0BF@coconut.itojun.org> References: <20040727110631.GB14975@atoom.net> <20040729020433.D77D01C0BF@coconut.itojun.org> Date: Thu, 29 Jul 2004 08:39:25 -0400 To: itojun@itojun.org (Jun-ichiro itojun Hagino) From: Edward Lewis Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface Cc: miekg@atoom.net, pekkas@netcore.fi, namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm not sure who, but apparently someone wrote this to some mailing list at some time in the past. >> > The reason why I got interested was because section 8.2 of >> > draft-ietf-dnsop-ipv6-dns-issues-08.txt (see below) shows that the >> > application should be able to be aware of the TTL of the records, >> > easily, so that it could discard expired records from the memory if >> > it's built around in such a way that it would be feasible to do so. Please recall that the purpose of the TTL is for cache coherency, not a statement on the quality nor timeliness of the data in DNS. Similarly, the validity periods expressed in the signature records are not statements on the validity of the data, but the validity of the ancillary security data. "Expired records" is a concept alien to DNS. (A zone may be expired to a slave server.) >> > As it is, the applications typically query a name when they start and >> > use it forever, irregardless of the TTL. (And if the >> > application-resolver interface needs work in any case....) DNS is designed to be timeless service. It's up to applications to be as dynamic as they want to be. If applications assume incorrectly about the DNS, havoc will ensue. Applications should not assume anything about the timers and clocks inside DNS. OT: In my pre-DNS days, I once made my own simple lookup system. The app looked up a name, got the address, and tried to complete the handshake of the transport layer. If that failed, the app would then report back to the lookup system that the address was bad. When the app wanted to connect again, it would lookup the name until a new address was registered. If no address was received, it would set a timer and try again later. This was mostly event driven, not timer-based - accomplishing what seems to be desired above without needing to pass timer information across the lookup service interface. My point is - applications developers ought to rely on DNS at it's service's face value, not by inferring anything in the ancillary data. If application developers try to read between the lines, we muddle the architecture of the Internet and will end up with a "house of cards." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 09:03:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08816 for ; Thu, 29 Jul 2004 09:03:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqAVs-000CYZ-Ur for namedroppers-data@psg.com; Thu, 29 Jul 2004 13:00:00 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqAVi-000CU9-3s for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 12:59:50 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i6TCxkCY035171 for ; Thu, 29 Jul 2004 14:59:46 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i6TCxkEd035170 for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 14:59:46 +0200 (CEST) (envelope-from ted) Message-Id: <200407291259.i6TCxkEd035170@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Thu, 29 Jul 2004 14:59:45 +0200 In-Reply-To: "Alex Bligh's message as of Jul 29, 14:42" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers Subject: Re: dictionary attack on nameservers X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Alex Bligh, on Jul 29, 14:42, in "Re: dictionary attac ..."] > The reasons for the requirement for non-traversal of zones (NSEC2/NSEC3) > have been expounded at great length; I don't see any purpose in repeating > them again. As far as I can tell, the w/g reached consensus that there was > a requirement (perhaps not one you have) but that it would not form part of > DNSSECbis. I'm affraid you are misinformed: the w/g has NOT yet reached consensus on this a requirement. Discussing and, if necessary, then formulating such a requirement is a task the w/g still has to do. The (rough) consensus that was reached, and perhaps confused you, was that the w/g would discuss this topic at some later time, and not as part of the DNSSECbis document set. -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 09:19:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09719 for ; Thu, 29 Jul 2004 09:19:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqAl5-000Es2-AU for namedroppers-data@psg.com; Thu, 29 Jul 2004 13:15:43 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqAku-000EqS-Iu for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 13:15:32 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 3E04E19B86D; Thu, 29 Jul 2004 09:06:18 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 913CB19BAB2; Thu, 29 Jul 2004 09:06:16 -0400 (EDT) Received: from [192.136.136.102] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 1816ACF394; Thu, 29 Jul 2004 09:14:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <449E26FD9F3A55514799A61A@[192.168.100.27]> References: <20040728190530.GA22758@atoom.net> <20040728210546.GA24838@atoom.net> <4108EB24.9000504@mindrot.org> <449E26FD9F3A55514799A61A@[192.168.100.27]> Date: Thu, 29 Jul 2004 09:14:32 -0400 To: namedroppers From: Edward Lewis Subject: Re: dictionary attack on nameservers Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm afraid that I think arguing over the feasibility of dictionary attacks, "privacy," and the motivation for and threat of DNS data mining is not getting us very far. Thanks to Miek for taking a stab at enumerating the effort to dictionary-attack a zone. But to really make it convincing, I'd like to see an attack carried out and compare the results to the real zone. Only when we hit a high percentage of the names (65%, 80%, 90%) would I be really interested in the measure of resources needed to pull it off. But I stress that it's a bit of red herring (non-topic). As far as the issue of zone enumeration, my thoughts fall into this: 1) When DNSSEC originated, zone enumeration was not a threat. Because of this, I think DNSSECbis, meeting other goals, is done and ready to be published as a doc set. If operators aren't happy with it, they can treat the doc set the same way they treated RFC 2065 and RFC 2535. 2) I do think zone enumeration is a nuisance. I wouldn't rate it a threat to DNS, nor would I rate it a desired feature. I applaud anyone's initiative to study the issue and propose a means to accomplish all of what DNS and DNSSEC stands for while preventing zone enumeration. I don't blame all network malfeasance (e.g., spam) on zone enumeration though. Zone enumeration just one element. But still, the DNS ought to limit it's network slag. (Slag is a waste product in steel production. Olafur reminds me now and then that I need to avoid obscure words...;)) 3) Zone enumeration is not a privacy issue. Data in the DNS is not private, but bulk access to it can be a problem. The situation is like a company on-line phone list. I can ask for the number of one person, but not the organizational structure of the company. Don't think of that as a privacy concern though - thing of it as an abuse of the service. DNS is lookup, not search. DNS ought not ever encourage a "search" of it's data store. Not because of privacy, but because we don't want mission creep. 4) The way I see NSEC is that we started out with the goal of pre-computed, fairly-fine-grained authenticated denial statements. We accomplished this in a manner that made zone enumeration possible. It would have been nice to not make zone enumeration possible, but it is a by product. (Much like autos do not want to emit carbon monoxide - but in order to achieve transportation within the other restrictions, it happens.) 5) The way I see "improvements" to NSEC in this manner is like a second generation engineering effort. (Like electric cars.) It would have been real nice to not need to remove zone enumeration - either be declaring it a non-issue or by not having engendered it in the first place. IMHO - we ought not fight the efforts to find a better version of NSEC. But, at the same time, the effort to find a better NSEC ought not stand in the way of getting DNSSECbis fielded. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 09:26:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10023 for ; Thu, 29 Jul 2004 09:26:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqAsd-000FlH-UW for namedroppers-data@psg.com; Thu, 29 Jul 2004 13:23:31 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqAsK-000FjI-SY for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 13:23:13 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 4AA674E00D; Thu, 29 Jul 2004 15:23:12 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A13444E03E for ; Thu, 29 Jul 2004 15:23:09 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i6TDN9x0015002 for ; Thu, 29 Jul 2004 15:23:09 +0200 Received: (from olaf@localhost) by cow.ripe.net (8.12.10/8.12.6) id i6TDN9kx023947 for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 15:23:09 +0200 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq8Hl-000Ks9-1K for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 10:37:17 +0000 Received: from wds1.nominet.org.uk (wds1.dhcp.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id 33B88E7EC8; Thu, 29 Jul 2004 11:37:16 +0100 (BST) In-Reply-To: <200407290928.i6T9S9pV032779@open.nlnetlabs.nl> To: ted@NLnetLabs.nl (Ted Lindgreen) Cc: namedroppers Subject: Re: dictionary attack on nameservers MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "Jay Daley" Date: Thu, 29 Jul 2004 11:37:45 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 07/29/2004 11:37:46 AM, Serialize complete at 07/29/2004 11:37:46 AM Content-Type: text/plain; charset="US-ASCII" X-RIPE-Spam-Level: * X-RIPE-Spam-Status: U 0.499996 / 1.1 / 0.0 / disabled X-RIPE-Signature: 7dbd6262bedd6ba0784803443369ffa7 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: This post needed manual approval. Either because it was posted by a non-subscriber or because it contained to many characters (> 20000). With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please fix your subscription addresses or shorten your postings by adding links instead of attachments ] Ted Ted wrote on 29/07/2004 10:28:08: > I am not sure what you call "a large zone", so also not if .nl > qualifies (it is in the top-5 or so of largest zones, but, of > course, much smaller than .com). > The .nl domain has some 1.3M delegations, some 30k domains are > newly registered and some 5k are released per month (from data > over the first few months of 2004). That will do. > > I know of a number of registrars who keep daily updated, and > very accurate lists of registrered and returned domain names. > For .nl and also for other TLDs. > > These guys use various techniques to keep their lists accurate > and up-to-date. Although highly effective, these techniques are > neither complicated, nor costly for the registrar. > However, their load the .nl nameservers is significant, and thus > one can easily see and determime who/what is causing it in the > nameserver-traces which we routinely investigate in our testlab. With respect this is still anecdotal. Where is the real data? i.e. "By dictionary attack X managed to guess Y% of the 1.3m names". Jay -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 09:37:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10624 for ; Thu, 29 Jul 2004 09:37:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqB3g-000H51-32 for namedroppers-data@psg.com; Thu, 29 Jul 2004 13:34:56 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqB3V-000H38-Bd for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 13:34:45 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 669C0AC8D; Thu, 29 Jul 2004 15:34:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 656D6AC8B; Thu, 29 Jul 2004 15:34:44 +0200 (CEST) Date: Thu, 29 Jul 2004 15:34:44 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Damien Miller Cc: namedroppers Subject: Re: dictionary attack on nameservers In-Reply-To: <4108EB24.9000504@mindrot.org> Message-ID: References: <20040728190530.GA22758@atoom.net> <20040728210546.GA24838@atoom.net> <4108EB24.9000504@mindrot.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 29 Jul 2004, Damien Miller wrote: > Roy Arends wrote: > > > I have seen no claims that NSEC2/3/X can prevent zone walking or > > enumeration. The goal is to make zone walking more expensive. > > > > The lock on my front door does not prevent break-ins. Its goal is to make > > break-ins more expensive. > > This is a false analogy: the people who want to enumerate DNS zones > wouldn't be spending their own money - they have zombies and botnets to > do the work for them. I was referring to expensive as cost in general (i.e. time, effort, etc) not just valuta. I did not specify if investment were direct, or by proxy. The general approach for defense against attack vectors is to increase their cost. Making attack vectors impossible is Deity. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 11:44:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19323 for ; Thu, 29 Jul 2004 11:44:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqD0L-00055W-N5 for namedroppers-data@psg.com; Thu, 29 Jul 2004 15:39:37 +0000 Received: from [129.9.82.74] (helo=fxodpr13.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqCzW-0004yA-3z for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 15:38:46 +0000 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id i6TFci0f012950 for ; Thu, 29 Jul 2004 11:38:44 -0400 (EDT) Received: from unknown(53.231.71.24) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAM_aOsz; Thu, 29 Jul 04 11:38:44 -0400 Received: from odconpr2-hme0.oddc.chrysler.com ([127.0.0.1]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2004072911384311673 ; Thu, 29 Jul 2004 11:38:43 -0400 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by odconpr2-hme0.oddc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004072911384303957 ; Thu, 29 Jul 2004 11:38:43 -0400 Received: from shsecpr1-ce0.shdc.chrysler.com (shsecpr1-ce0.shdc.chrysler.com [53.231.128.176]) by odmrspr2-hme0.oddc.chrysler.com (8.12.11/8.12.10/daimlerchrysler-relay-1.1-kcd) with SMTP id i6TFVlBh029408; Thu, 29 Jul 2004 11:32:23 -0400 (EDT) Received: from wokcdts1.is.chrysler.com ([53.230.102.252]) by shsecpr1-ce0.shdc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004072911322300142 ; Thu, 29 Jul 2004 11:32:23 -0400 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.252]) by wokcdts1.is.chrysler.com (8.11.7+Sun/8.9.1) with ESMTP id i6TFWMr11365; Thu, 29 Jul 2004 11:32:22 -0400 (EDT) Message-ID: <41091886.1040205@daimlerchrysler.com> Date: Thu, 29 Jul 2004 11:32:22 -0400 From: Kevin Darcy User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface References: <20040727110631.GB14975@atoom.net> <20040729020433.D77D01C0BF@coconut.itojun.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > I'm not sure who, but apparently someone wrote this to some mailing > list at some time in the past. > >>> > The reason why I got interested was because section 8.2 of >>> > draft-ietf-dnsop-ipv6-dns-issues-08.txt (see below) shows that the >>> > application should be able to be aware of the TTL of the records, >>> > easily, so that it could discard expired records from the memory if >>> > it's built around in such a way that it would be feasible to do so. >> > > Please recall that the purpose of the TTL is for cache coherency, not > a statement on the quality nor timeliness of the data in DNS. I would argue that if an application is using the results of a previous DNS lookup which it has stored in memory, then that is "caching" by any meaningful definition of the term. And if an app is caching, we should provide a way for the app to do so in a coherent manner. This implies making the TTL visible. Whether this is in getaddrinfo() or some other API, I'm not qualified to comment. Like others, I've had problems with apps that "lock on" to a particular IP address. Particularly in dynamically load-balanced scenarios. - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 11:44:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19361 for ; Thu, 29 Jul 2004 11:44:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqD2q-0005UV-4D for namedroppers-data@psg.com; Thu, 29 Jul 2004 15:42:12 +0000 Received: from [196.4.160.222] (helo=mercury.is.co.za) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqD2e-0005Rn-Rh for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 15:42:01 +0000 Received: from hypatia.dns.net (c19-rba-51.dial-up.net [196.39.10.179]) by mercury.is.co.za (Postfix) with ESMTP id C8917E2074; Thu, 29 Jul 2004 17:41:56 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i6T7uLu12271; Thu, 29 Jul 2004 09:56:21 +0200 Date: Thu, 29 Jul 2004 09:56:21 +0200 From: Andras Salamon To: Miek Gieben Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Message-ID: <20040729075621.GC11948@dns.net> References: <20040728190530.GA22758@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040728190530.GA22758@atoom.net> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_06_12,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Jul 28, 2004 at 09:05:31PM +0200, Miek Gieben wrote: > How long would it take > to do a dictionary attack on the .NL zone? Thanks for reporting this experiment, very interesting. > Next I fired up the tool and waited. After 46 minutes the whole NL > dictionary was used up. > NL has 1 million domain names, so this gives me only about 5 percent > of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~= > 15 hours), I should get almost the whole NL zone. I don't understand your extrapolation here. Given a reasonably large dictionary you obtained 5% of the domain names. How do you propose obtaining the other 95%, or even 80% of the rest? Do you have another dictionary that is likely to give you a 20% hit rate _and_ coverage of the rest of the namespace? You could certainly create a new dictionary of, say, 500K words formed by adding the English dictionary to the Dutch one, and adding common domain suffixes like 123 or prefixes like 0800. If you then take the concatenation of every string in this dictionary with every other string (as well as insertion of '-' between the strings), you get a dictionary of 2*250*10^9 (500 billion) possible domain names. However, you are going to get at most a 10^6/(5*10^11) = 2*10^(-6) hit rate for this dictionary even with 100% coverage. So you would get at most 100*5*(10^3)*2*10^(-6) = 1 domain name per 100 minutes even with 100% coverage. If you parallelise, say 100 queries at a time, that's still only 1 name per minute. Hence, this method is not likely to help those "direct marketers" who are looking out for the new names being registered (this was cited by people on this list as a bogey man). This method will only help those who want a rough list once (and are prepared to wait several months and generate around 50TB of network traffic to build it, at 100 bytes per query). I wager that right now someone wanting to find domains will find it more cost-efficient to simply scan web server logs, running a spider on search engine results, or doing in-addr.arpa lookups based on assigned netblocks. Obtaining 5% of a zone through an efficient method of guessing is interesting. However, I am not sure this is sufficient in itself to argue that limiting zone walking is inherently useless. On the other hand, if enough people really want a list of domains badly enough to waste 50TB, 500bn DNS queries and several months gathering it, then I think it would be better for the network as a whole for the registries to consider either selling the data or making it freely available. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 12:03:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20783 for ; Thu, 29 Jul 2004 12:03:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqDJS-00080m-E1 for namedroppers-data@psg.com; Thu, 29 Jul 2004 15:59:22 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqDIy-0007vb-EK for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 15:58:52 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 329D319BAD8; Thu, 29 Jul 2004 11:50:33 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id A700C19BAD0; Thu, 29 Jul 2004 11:50:32 -0400 (EDT) Received: from [192.136.136.102] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 44598CF394; Thu, 29 Jul 2004 11:58:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <41091886.1040205@daimlerchrysler.com> References: <20040727110631.GB14975@atoom.net> <20040729020433.D77D01C0BF@coconut.itojun.org> <41091886.1040205@daimlerchrysler.com> Date: Thu, 29 Jul 2004 11:58:50 -0400 To: Kevin Darcy From: Edward Lewis Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface Cc: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:32 -0400 7/29/04, Kevin Darcy wrote: >I would argue that if an application is using the results of a previous DNS >lookup which it has stored in memory, then that is "caching" by any meaningful >definition of the term. And if an app is caching, we should provide a way for >the app to do so in a coherent manner. This implies making the TTL visible. >Whether this is in getaddrinfo() or some other API, I'm not qualified to >comment. Yes, it is caching by the application and it is up to the application to decide how long it will internally cache the data. (Will SSH close a connection after 8 hours because it feels the original lookup data is no longer fresh enough?) The DNS TTL though is not a good measure of freshness - by that I mean freshness at the authoritative source. E.g., on one run an SSH client might get an address via a cache that had to get a fresh authoritative answer. In this case, the DNS TTL might be 10800. On a later run, the same client may get the same address - but following an HTTP client lookup by an hour. In this case, the TTL is now 7200. What does that mean to the SSH client, other than the data was sitting in an intermediary for an hour? It says nothing about the freshness of the data at the origin. (Note that the client can't determine that it was sitting in the intermediary - there's no indication of how far a TTL has ticked down in a reply. It might be that the source has lowered the TTL. Also, even if the application can be made to decide that it wants fresher data - it can't force the cache to get it. The app would have to do it's own query iteration.) >Like others, I've had problems with apps that "lock on" to a particular IP >address. Particularly in dynamically load-balanced scenarios. I've seen that. I attribute it to poor application design, not a limitation of the interface to DNS (or other lookup service). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 12:50:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24305 for ; Thu, 29 Jul 2004 12:50:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqE2h-000DSZ-Ds for namedroppers-data@psg.com; Thu, 29 Jul 2004 16:46:07 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqE2W-000DRa-OB for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 16:45:56 +0000 Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i6TGhr9Q002027; Thu, 29 Jul 2004 12:43:53 -0400 (EDT) Received: from egyptian-gods.mit.edu (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id i6TGhqoM016221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jul 2004 12:43:52 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i6TGhoKM025714; Thu, 29 Jul 2004 12:43:50 -0400 Subject: Re: dictionary attack on nameservers From: Greg Hudson To: Jay Daley Cc: namedroppers In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1091119430.16991.246.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 29 Jul 2004 12:43:50 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2004-07-29 at 04:44, Jay Daley wrote: > > ad 1. It has being shown (several times) that (90-99%) zone > > enumeration without AXFR is simple and dirt cheap. > > I'm sorry to be picky but I don't think the above is true. Your subsequent analysis only addresses dictionary attacks. But other attacks have been mentioned here (web-crawling, PTR walking), although we don't really have numbers on how effective any of the attacks are. (As many people have pointed out, "a dictionary attack got me 5% in a short amount of time" doesn't really prove or even suggest anything.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 12:55:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24578 for ; Thu, 29 Jul 2004 12:55:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqE94-000EK6-Ju for namedroppers-data@psg.com; Thu, 29 Jul 2004 16:52:42 +0000 Received: from [129.46.51.58] (helo=numenor.qualcomm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqE8t-000EIg-Tc for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 16:52:32 +0000 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i6TGqP1i027164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jul 2004 09:52:26 -0700 (PDT) Received: from [10.30.5.39] (vpn-10-50-0-118.qualcomm.com [10.50.0.118]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i6TGqMIb000551; Thu, 29 Jul 2004 09:52:23 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <20040729091243.0B168E7E8A@mx1.nominet.org.uk> References: <20040729091243.0B168E7E8A@mx1.nominet.org.uk> Date: Thu, 29 Jul 2004 09:52:21 -0700 To: geoff@nominet.org.uk (Geoffrey Sisson), namedroppers@ops.ietf.org From: Ted Hardie Subject: Re: dictionary attack on nameservers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:12 AM +0100 7/29/04, Geoffrey Sisson wrote: >Miek Gieben writes: > >> Why is so much effort pumped in to a new NSEC solution for DNSSEC when >> people can walk DNS zones so easily right now? > >I can't speak for everyone, but we (Nominet) are advised that we have >a responsibility to protect the confidentiality of data in the .uk zones, >even if this cannot be done perfectly. Can you clarify this? Previous messages from Jay seemed to indicate that the data which was sensitive was actually the data in whois, and the DNS protection was needed to prevent a zone-walk from highlighting domain targets for whois. If I have that wrong, I would appreciate a clarification. For those not following CRISP, by the way, iris-core, iris-beep, and iris-dreg are now all in the RFC editor queue. IRIS has facilities that allow registries to handle administrative queries in ways whois does not. Shifting from whois to iris may solve this problem without going back to the design phase yet again in DNSSEC. regards, Ted Hardie >Also, I use to think that, even if "NSEC+" were available, that NSEC >was sufficient for {in-addr,ipv6,e164}.arpa. Now I'm not so sure. >While any one zone in these hierarchies is trivially enumerable w/o >NSEC, the elaboration of the aggregate trees is a bigger problem which >is considerably reduced by NSEC. (Okay, maybe not so hard to elaborate >e164.arpa yet by any means . . .) The reverse trees and enum may prove >to be killer apps for NSEC+. > >Peter Koch > >> the last 10% that makes 90% of the price ... > >I think this is also a good summation. > >Regards > >Geoff > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 13:20:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26227 for ; Thu, 29 Jul 2004 13:20:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqEVi-000I8x-Vt for namedroppers-data@psg.com; Thu, 29 Jul 2004 17:16:06 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqEVW-000I6b-Uf for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 17:15:55 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i6TGkxY5037871; Thu, 29 Jul 2004 18:46:59 +0200 (CEST) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) with ESMTP id i6TGkvLe021350; Thu, 29 Jul 2004 18:46:57 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) id i6TGkurI021349; Thu, 29 Jul 2004 18:46:56 +0200 Date: Thu, 29 Jul 2004 18:46:56 +0200 From: Miek Gieben To: Andras Salamon Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Message-ID: <20040729164656.GA20883@atoom.net> Mail-Followup-To: Andras Salamon , namedroppers@ops.ietf.org References: <20040728190530.GA22758@atoom.net> <20040729075621.GC11948@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040729075621.GC11948@dns.net> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 29 Jul, @09:56, Andras wrote in "Re: dictionary attack on names ..."] > On Wed, Jul 28, 2004 at 09:05:31PM +0200, Miek Gieben wrote: > > How long would it take > > to do a dictionary attack on the .NL zone? > > Thanks for reporting this experiment, very interesting. > > > Next I fired up the tool and waited. After 46 minutes the whole NL > > dictionary was used up. > > NL has 1 million domain names, so this gives me only about 5 percent > > of the NL zone. But to put it bluntly: if I wait 20 * 46 minutes (~= > > 15 hours), I should get almost the whole NL zone. > > I don't understand your extrapolation here. Given a reasonably large that's probably because the extrapolation is mathematical nonsense. The point I was making is that: 1) with no effort at all, I can get a listing zones, with more effort I can probably get a longer listing. 2) those people who think enumeration is going to be a problem in DNSSEC are saying/claiming enumeration isn't a problem in the DNS? > dictionary you obtained 5% of the domain names. How do you propose > obtaining the other 95%, or even 80% of the rest? modifying John the Ripper to attack a nameserver instead of a local passwd file? I've played with john the ripper a few years ago, it's lots of fun to run the incremental mode on a passwd file :-) That said. I'm way too lazy to do this. My point is/was that there are other ways to get a zone, besides AXFR and NSEC walking. > I wager that right now someone wanting to find domains will find it more > cost-efficient to simply scan web server logs, running a spider on search > engine results, or doing in-addr.arpa lookups based on assigned netblocks. I agree. And with some windows zombie hosts on the Internet this will all go a lot faster still. So dictionary attacks + spidering web logs + google attacks + in-addr.arpa lookups will get you 80%/90% of a zone? > Obtaining 5% of a zone through an efficient method of guessing is > interesting. However, I am not sure this is sufficient in itself to > argue that limiting zone walking is inherently useless. > > On the other hand, if enough people really want a list of domains badly > enough to waste 50TB, 500bn DNS queries and several months gathering > it, then I think it would be better for the network as a whole for who says this isn't happening right now? If someone really wants to know I propose the following experiment (for a TLD). * Measure your current nameserver load * Put your zone on a anonymous FTP site * Measure your nameserver load again If the load is lower I'm right, if the load is higher some else is right :-) > the registries to consider either selling the data or making it freely > available. wonderfull idea, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 14:15:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29057 for ; Thu, 29 Jul 2004 14:15:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqFNF-000OlE-8C for namedroppers-data@psg.com; Thu, 29 Jul 2004 18:11:25 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqFMg-000Ohl-8u for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 18:10:50 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i6TIAkqJ016879; Thu, 29 Jul 2004 19:10:48 +0100 (BST) To: Stephane Bortzmeyer cc: namedroppers Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Stephane Bortzmeyer of "Thu, 29 Jul 2004 11:06:03 +0200." <20040729090603.GA26384@nic.fr> Date: Thu, 29 Jul 2004 19:10:46 +0100 Message-ID: <16878.1091124646@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Stephane" == Stephane Bortzmeyer writes: Stephane> Do note that this attack works well against ccTLD (where Stephane> almost all the domain names are in the national(s) Stephane> language(s) or in english) but not against gTLD, where Stephane> domain names are in hundreds of different languages or Stephane> are made by companies like Interbrand and do not appear Stephane> in any dictionary. Most languages used on the internet have on-line dictionaries. Lists of brand names, trademarks and so on can be obtained too. These can easily be compiled into the dictionary used for doing the zone enumeration or whatever. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 14:16:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29108 for ; Thu, 29 Jul 2004 14:16:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqFKf-000OPQ-6n for namedroppers-data@psg.com; Thu, 29 Jul 2004 18:08:45 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqFKR-000ONw-Kg for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 18:08:32 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i6TI8FqJ016867; Thu, 29 Jul 2004 19:08:15 +0100 (BST) To: Jay Daley cc: namedroppers , ted@NLnetLabs.nl (Ted Lindgreen) Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Jay Daley of "Thu, 29 Jul 2004 09:44:52 BST." Date: Thu, 29 Jul 2004 19:08:15 +0100 Message-ID: <16866.1091124495@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Jay" == Jay Daley writes: Jay> When people register a name they use a name from a pool of Jay> possible names. As a zone grows in size people begin to Jay> exhaust the easy pools and so need to invent new pools. So Jay> the initial pools are often Jay> very short names (2, 3, 4 characters) Jay> generic words (eg music, buses, teeth) Jay> organisation/personal names Jay> but as these grow people start to invent new ones Jay> generic hyphen generic Jay> generic plus number Jay> and so on. Jay> So the smaller a zone is, the easier it is to enumerate. Nope. The smaller the zone, the easier it may be to enumerate with a stupid dictionary attack. A serious attempt at enumeration wouldn't just do a simple dictionary attack: it would try "generic hyphen generic", "generic plus string of digits" and so on. This is no different from how most password crackers work. The dumb ones just use a dictionary. The clever ones also try manipulations on the names in the dictionary: obvious suffixes and prefixes, reversed names, etc, etc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 14:24:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29588 for ; Thu, 29 Jul 2004 14:24:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqFVp-000PyA-7X for namedroppers-data@psg.com; Thu, 29 Jul 2004 18:20:17 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqFVW-000Pt8-5q for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 18:19:58 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i6TIJuqJ016893; Thu, 29 Jul 2004 19:19:56 +0100 (BST) To: geoff@nominet.org.uk (Geoffrey Sisson) cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from geoff@nominet.org.uk (Geoffrey Sisson) of "Thu, 29 Jul 2004 10:12:43 BST." <20040729091243.0B168E7E8A@mx1.nominet.org.uk> Date: Thu, 29 Jul 2004 19:19:56 +0100 Message-ID: <16892.1091125196@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Geoffrey" == Geoffrey Sisson writes: Geoffrey> Also, I use to think that, even if "NSEC+" were Geoffrey> available, that NSEC was sufficient for Geoffrey> {in-addr,ipv6,e164}.arpa. Now I'm not so sure. These trees are trivially enumerated now. Since they have a well-known and regular name space, enumerating them is a no-brainer. No variant of NSEC is going to make enumeration of these zones harder. Or easier. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 15:24:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03822 for ; Thu, 29 Jul 2004 15:24:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqGQz-0007AU-Kn for namedroppers-data@psg.com; Thu, 29 Jul 2004 19:19:21 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqGQp-00079V-0b for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 19:19:11 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id B6E461FE74; Thu, 29 Jul 2004 20:19:07 +0100 (BST) Date: Thu, 29 Jul 2004 20:19:04 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jim Reid , Geoffrey Sisson Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: In-Reply-To: <16892.1091125196@gromit.rfc1035.com> References: <16892.1091125196@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 29 July 2004 19:19 +0100 Jim Reid wrote: > These trees are trivially enumerated now. Since they have a well-known > and regular name space, enumerating them is a no-brainer. No variant of > NSEC is going to make enumeration of these zones harder. Or easier. I am not sure enumerating ipv6.arpa necessarily has to be trivial (if there are large delegations) but AFAICS you are right with the others. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 15:24:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03864 for ; Thu, 29 Jul 2004 15:24:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqGSz-0007Pu-Lf for namedroppers-data@psg.com; Thu, 29 Jul 2004 19:21:25 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqGSp-0007Nv-0K for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 19:21:15 +0000 Received: from wds1.nominet.org.uk (wds1.dhcp.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id 4F0FEE7E4A; Thu, 29 Jul 2004 20:21:14 +0100 (BST) In-Reply-To: <16866.1091124495@gromit.rfc1035.com> To: Jim Reid Cc: namedroppers Subject: Re: dictionary attack on nameservers MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 18, 2003 Message-ID: From: "Jay Daley" Date: Thu, 29 Jul 2004 20:21:44 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 07/29/2004 08:21:45 PM, Serialize complete at 07/29/2004 08:21:45 PM Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Jim wrote on 29/07/2004 07:08:15 pm: > Nope. The smaller the zone, the easier it may be to enumerate with a > stupid dictionary attack. A serious attempt at enumeration wouldn't > just do a simple dictionary attack: it would try "generic hyphen > generic", "generic plus string of digits" and so on. This is no > different from how most password crackers work. The dumb ones just use > a dictionary. The clever ones also try manipulations on the names in > the dictionary: obvious suffixes and prefixes, reversed names, etc, > etc. That is precisely my point. As the register grows the namespace becomes more complex, which then leads to searching ever increasing numbers of possiblities for ever decreasing results. This appears at first sight to be a limiting function and what we are all arguing about it where that limit is. My view, as expressed before is that 99% is wildly optimistic. Jay -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 16:02:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05647 for ; Thu, 29 Jul 2004 16:02:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqH2R-000C14-P4 for namedroppers-data@psg.com; Thu, 29 Jul 2004 19:58:03 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqH2G-000Bxr-NH for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 19:57:53 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i6TJvoqJ017058; Thu, 29 Jul 2004 20:57:51 +0100 (BST) To: "Jay Daley" cc: namedroppers Subject: Re: dictionary attack on nameservers In-Reply-To: Message from "Jay Daley" of "Thu, 29 Jul 2004 20:21:44 BST." Date: Thu, 29 Jul 2004 20:57:50 +0100 Message-ID: <17057.1091131070@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Jay" == Jay Daley writes: Jay> That is precisely my point. As the register grows the Jay> namespace becomes more complex, which then leads to searching Jay> ever increasing numbers of possiblities for ever decreasing Jay> results. This appears at first sight to be a limiting Jay> function and what we are all arguing about it where that Jay> limit is. I'm not sure that either is the case. Dictionary attacks will mean zone enumeration is always successful, if not always complete. There are other ways of enumerating a zone that have been mentioned in this list a while ago. Zone enumeration is already going on. And presumably the results of that are "good enough" for whoever is doing the enumeration, whether they're getting 1% or 100% of the zone. It would be good to know how effective a concerted dictionary attack would be on some TLD. But I don't see this making much of a difference to the wider debate. Those who oppose NSEC because of the zone enumeration issues are unlikely to change their minds if a decent dictionary attack -- just one means of enumerating a zone remember -- yields 80% or 90% or 100% of the zone. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 16:37:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07752 for ; Thu, 29 Jul 2004 16:37:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqHYW-000GGJ-R8 for namedroppers-data@psg.com; Thu, 29 Jul 2004 20:31:12 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqHYE-000GDC-1v for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 20:30:54 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 91CE819B525; Thu, 29 Jul 2004 16:22:31 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 1F98919B4D5; Thu, 29 Jul 2004 16:22:31 -0400 (EDT) Received: from [192.136.136.102] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id F358ACF394; Thu, 29 Jul 2004 16:30:52 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 29 Jul 2004 16:30:51 -0400 To: Roy Arends From: Edward Lewis Subject: Re: draft-arends-dnsnr-00 Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I hope there's time to talk about this in San Diego (outside the meeting) - reading the doc and the ensuing thread has given me a headache. ;) I thought the draft was introducing a new requirement for authoritative non-existence, not needing to cover unsecured delegation points. I thought this was about lightening the load on "widely delegated" zones (eliminating the need to include "NXT's" for un-DS'd delegations). But the thread started on this non-repudiation thing I couldn't make heads of tails of. To someone - you're right. To many negatives in the there somewhere. Of course I can sign "www.example.com A" and *then* sign a statement that I didn't - and still be valid. It's okay so long as I remove the "www.example.com A" when I sign again. ;) And, through the magic of caching, both statements can be floating in the ether simultaneously. And that's why the non-repudiation stuff makes no sense to me. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 16:48:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08336 for ; Thu, 29 Jul 2004 16:48:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqHmr-000Hqi-H0 for namedroppers-data@psg.com; Thu, 29 Jul 2004 20:46:01 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqHmg-000HoN-Py for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 20:45:51 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i6TKjhgD027722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 29 Jul 2004 20:45:49 GMT (envelope-from roy+dated+1093725943.d364f5@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i6TKjhnT043989 for ; Thu, 29 Jul 2004 21:45:43 +0100 (BST) (envelope-from roy+dated+1093725943.d364f5@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i6TKjhCs043988 for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 21:45:43 +0100 (BST) (envelope-from roy+dated+1093725943.d364f5@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 29 Jul 2004 21:45:40 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16649.25075.560757.20484@giles.gnomon.org.uk> Date: Thu, 29 Jul 2004 21:45:39 +0100 To: Alex Bligh Cc: Jim Reid , Geoffrey Sisson , namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: References: <16892.1091125196@gromit.rfc1035.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Alex" == Alex Bligh writes: Alex> I am not sure enumerating ipv6.arpa necessarily has to be Alex> trivial (if there are large delegations) but AFAICS you are Alex> right with the others. I don't think large delegations make a difference. You can distiniguish empty non-terminals from non-existent domains. So when you walk the tree you stop descending only when you get NXDOMAIN. If you get no records back, but no error, then you know there's something below that point in the tree, and carry on descending. -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 17:31:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10660 for ; Thu, 29 Jul 2004 17:31:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqIRJ-000MoX-2a for namedroppers-data@psg.com; Thu, 29 Jul 2004 21:27:49 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqIR8-000MnD-E9 for namedroppers@ops.ietf.org; Thu, 29 Jul 2004 21:27:38 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 9B8FA1FE74; Thu, 29 Jul 2004 22:27:37 +0100 (BST) Date: Thu, 29 Jul 2004 22:27:34 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jim Reid , Jay Daley Cc: namedroppers , Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: <3D96637F4022B14BE90F2D9E@[192.168.100.27]> In-Reply-To: <17057.1091131070@gromit.rfc1035.com> References: <17057.1091131070@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 29 July 2004 20:57 +0100 Jim Reid wrote: > I'm not sure that either is the case. Dictionary attacks will mean > zone enumeration is always successful, if not always complete. A successful but necessarily incomplete zone enumeration is in my book an oxymoron. I am pointing that out not as a cheap shot, but because enumeration (at least in my book and I think that of those with the enumeration problem) means the ability to gain a complete or an almost complete zone through iteration, and we might as well each try and understand what terminology the other is using. I do not think there is any dispute that it is possible (without even having access to nameservers for the the zone) to get a list of domains, a substantial number of which will be in the zonefile, with that set itself representing a material portion of the zonefile, for many (but not all) zonefiles, whether that's by dictionary attack or by textual search of referring entities (web pages / in-addr.arpa). But that does not equate to enumeration which (using our terminology) is a) complete (or very nearly so); and b) sourced by the organization serving the zone Seems to me there is a lot of argument here backed by little hard data. It would be good if (without trashing an xTLDs nameservers) there was some statistical evidence of what % accuracy/completeness a proposed attack gave. Let me suggest: Accuracy% = 100 * ( [PositivelyDiscoveredEntries] - [FalsePositives]) --------------------------------------------------- TotalEntries as a metric. Let's bear in mind NSEC as is is 100% assuming an enumeration can be done between zone updates. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 29 21:20:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23236 for ; Thu, 29 Jul 2004 21:20:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqM01-000PcL-GG for namedroppers-data@psg.com; Fri, 30 Jul 2004 01:15:53 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqLzq-000PbC-Gx for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 01:15:42 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 8214219B504; Thu, 29 Jul 2004 21:07:16 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id D626F19B49C; Thu, 29 Jul 2004 21:07:15 -0400 (EDT) Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 724A9CF394; Thu, 29 Jul 2004 21:15:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 29 Jul 2004 21:15:36 -0400 To: Pekka Savola From: Edward Lewis Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface Cc: Edward Lewis , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 0:42 +0300 7/30/04, Pekka Savola wrote: >Rather, it's "the minimum how long the DNS server asserts that this >address corresponding to the name I asked will be valid". This is what I am afraid of. ;) A DNS server makes no assurance of the accuracy, etc., of the data it serves. The server makes no temporal statement of the data either. (DNSSEC only "protects" the transfer of data from where the administrator enters it to the resolver that last performs the check.) Also, the servers are not the (ultimate) authority for the data. They are just the "publication" mechanism. (That's when DNSSEC has something else sign the data, and has the authoritative servers load signed data.) Statements like "DNS server asserts...will be valid" indicate expectations of what DNS does that are higher than reality. DNS is just a plain old, vanilla look up service. >Similarly, consider a mechanism like SCTP or HIP which ties multiple >addresses to a connection. A hostname might map to 1..N addresses >when the connection is established; during the lifetime of the >connection, the hostname could change to point to an entirely >different set of addresses. Depending on how the new addresses >corresponding to the end-points are discovered during the session, >this TTL information could be quite useful -- as a means to trigger >how often one should poll for new information (instead of an arbitrary >interval). Although DNS is quite capable of carrying changing information (thanks to dynamic update), I don't think any application would be wise to rely on polling DNS to discover changed data. That an application element needs to get new data from the DNS ought to be triggered by an event internal to the application (such as a sudden failure of one application element in hearing from a remote element). >There are probably better examples as well.. And this is another troubling statement to me. The SIKED BOF said the same thing and we got grilled. Unless we have a good taxonomy of how DNS is going to be fit under applications, it's hard to know that we are designing a "level above DNS" that is as level a playing field as the DNS interface. This entire thread is from my reacting to the desire to expose the TTL from the resolver to application. My message is mostly one of concern - that applications need to understand what the TTL means. From my experience (going back in time), I'd try to avoid the TTL as a meaningful interface element - perhaps just from the principle of network layering. If you view the application as a layer above DNS, then using DNS internal data (the TTL) is a "layering violation." Even if it seems tempting... Remember - TTL's don't account for the rapidity of dynamic updates - and I think that's more important in the example you've described. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 01:25:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04095 for ; Fri, 30 Jul 2004 01:25:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqPnr-00019i-NY for namedroppers-data@psg.com; Fri, 30 Jul 2004 05:19:35 +0000 Received: from [193.0.3.25] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqPng-00018v-T4 for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 05:19:25 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 8807B39985A for ; Fri, 30 Jul 2004 07:19:25 +0200 (CEST) Message-ID: <4109DA5D.5040706@ripe.net> Date: Fri, 30 Jul 2004 07:19:25 +0200 From: "Olaf M. Kolkman" User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers Subject: Re: dictionary attack on nameservers References: <17057.1091131070@gromit.rfc1035.com> <3D96637F4022B14BE90F2D9E@[192.168.100.27]> In-Reply-To: <3D96637F4022B14BE90F2D9E@[192.168.100.27]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues Lets stop going around in circles. - We all know that enumerating zone data is possible today. Your millage may vary. - We all know that NSEC walking will provide you with all names in a zone. But I do not know what the threat is we try to protect against. This working group will need to get the requirements for making informed decisions on how to design NSEC++. Remember that Rip and Ben have volunteered to put such a list together. Please send your requirements to these to friendly volunteers. If you have a threat model in mind, please document and send to Ben & Rip. (http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01237.html) Once we have these requirements we can start engineering and figure out _if_ we can find a solution that meets these requirements. Work that Miek started may help to make an analysis of the requirements. Please try to phrase what NSEC++ is expected to deliver and mail your comments to Ben and Rip. --Olaf DNSEXT Co-Chair. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 04:03:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23212 for ; Fri, 30 Jul 2004 04:03:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqSHS-000KZa-NM for namedroppers-data@psg.com; Fri, 30 Jul 2004 07:58:18 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqSHH-000KYD-SX for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 07:58:08 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 02E8DAC8D; Fri, 30 Jul 2004 09:58:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 01932AC8B; Fri, 30 Jul 2004 09:58:02 +0200 (CEST) Date: Fri, 30 Jul 2004 09:58:02 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 29 Jul 2004, Edward Lewis wrote: > I hope there's time to talk about this in San Diego (outside the > meeting) - reading the doc and the ensuing thread has given me a > headache. ;) Lets do beer. > I thought the draft was introducing a new requirement for authoritative > non-existence, not needing to cover unsecured delegation points. I > thought this was about lightening the load on "widely delegated" zones > (eliminating the need to include "NXT's" for un-DS'd delegations). Yes. That is one of the requirements. > But the thread started on this non-repudiation thing I couldn't make > heads of tails of. To someone - you're right. To many negatives in > the there somewhere. I don't thing you're not right. ;) So, yeah, I changed the name to NSEC3 to avoid confusion. > Of course I can sign "www.example.com A" and *then* sign a statement > that I didn't - and still be valid. You can, but it wouldn't be valid. It is not that atomic. If you'd sign "www.example.com A" you should sign a statement that you did, then serve it as a whole. A MUST, not even a SHOULD. Since that is called "authenticated denail of existence", a statement like Authenticated denial of existence is a statement that is either true or false. A one bit thing. Inverse the statement and it would be authenticated proof of existence. The law of the Excluded Middle as Paul Vixie pointed out. So I looked for a meta-term that did not have the word 'existence', 'absence' nor 'denial' since that would discriminate half of the statement. Since a statement was signed to proof absence or existence, as a method to avoid that statement being repudiated by anyone (by simply replacing a positive response by negative response), I used the term non-repudiation. Maybe ill-chose, maybe not, it doesn't matter, the term is now NSEC3. Small gesture for the purpose of clarity. > It's okay so long as I remove the "www.example.com A" when I sign again. > ;) And, through the magic of caching, both statements can be floating in > the ether simultaneously. Yes, that is an operational thing. If it hurts to much, fiddle TTL. > And that's why the non-repudiation stuff makes no sense to me. No more non-repudiation for me. I'm a little scared to be drowned in the marina for bringing back Opt-In. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 04:04:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23274 for ; Fri, 30 Jul 2004 04:04:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqSL8-000L6O-Hi for namedroppers-data@psg.com; Fri, 30 Jul 2004 08:02:06 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqSKx-000L44-Rr for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 08:01:56 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id EC7D9AC8D; Fri, 30 Jul 2004 10:01:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id EB78CAC8B; Fri, 30 Jul 2004 10:01:54 +0200 (CEST) Date: Fri, 30 Jul 2004 10:01:54 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: draft-arends-dnsnr-00 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 30 Jul 2004, Roy Arends wrote: > Since a statement was signed to proof absence or existence, as a method to > avoid that statement being repudiated by anyone (by simply replacing a ^^^^^^^^^ RRsets > positive response by negative response), I used the term non-repudiation. > Maybe ill-chose, maybe not, it doesn't matter, the term is now NSEC3. > Small gesture for the purpose of clarity. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 06:10:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27363 for ; Fri, 30 Jul 2004 06:10:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqUFA-000AXg-Ir for namedroppers-data@psg.com; Fri, 30 Jul 2004 10:04:04 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqUEz-000AWO-BB for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 10:03:53 +0000 Received: (debugging) helo=deneb.enyo.de ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp id 1BqUEe-0003rm-5N for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 12:03:32 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.34) id 1BqUEu-0001mO-Kl for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 12:03:48 +0200 To: namedroppers Subject: Re: dictionary attack on nameservers References: <20040728190530.GA22758@atoom.net> <20040728210546.GA24838@atoom.net> From: Florian Weimer Date: Fri, 30 Jul 2004 12:03:48 +0200 In-Reply-To: <20040728210546.GA24838@atoom.net> (Miek Gieben's message of "Wed, 28 Jul 2004 23:05:47 +0200") Message-ID: <87ekmtu7zv.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Miek Gieben: > The main point of my post is that I can enumerate (for +/- 90%) a zone > in 24 hours, even if AXFR is blocked. There are other methods to do that, for example passive DNS replication: If you put a DNS zone on a public, authoritative name server, it is public. There is no way to change this. Disabling AXFR makes reconstructing the zone contents somewhat more complicated, but not impossible (at least for the RRs which are actually used in the wild). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 08:21:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02096 for ; Fri, 30 Jul 2004 08:21:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqWKM-0001N4-GN for namedroppers-data@psg.com; Fri, 30 Jul 2004 12:17:34 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqWKB-0001Ky-5I for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 12:17:23 +0000 Received: (debugging) helo=deneb.enyo.de ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp id 1BqWJq-0005fy-6b; Fri, 30 Jul 2004 14:17:02 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.34) id 1BqWK6-00022M-EJ; Fri, 30 Jul 2004 14:17:18 +0200 To: ted@NLnetLabs.nl (Ted Lindgreen) Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: <200407291030.i6TAUGjH033734@open.nlnetlabs.nl> From: Florian Weimer Date: Fri, 30 Jul 2004 14:17:18 +0200 In-Reply-To: <200407291030.i6TAUGjH033734@open.nlnetlabs.nl> (Ted Lindgreen's message of "Thu, 29 Jul 2004 12:30:16 +0200") Message-ID: <873c39sn8x.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Ted Lindgreen: > I am affraid I have lost it now, please enlighten me: > > 1. the argument against enumeration is the European (and/or > other) privacy legislation; I don't think this is an issue. Most TLD zone data is already available on request, under terms that aren't too restrictive. This woul be impossible if domain names were personally identifiable information. > 2. it is clear that 99% enumeration on a daily basis is currently > practice (perhaps not desirable, but real practice); > 3. NSEC may provide for 100% correct snapshots, valid in the > interval between zone-updates. IMHO, the most important question is whether NSEC-based enumeration causes additoinal load on name servers, or if it might result in less load. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 08:21:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02114 for ; Fri, 30 Jul 2004 08:21:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqWLP-0001TU-N5 for namedroppers-data@psg.com; Fri, 30 Jul 2004 12:18:39 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqWLE-0001S9-Vr for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 12:18:29 +0000 Received: (debugging) helo=deneb.enyo.de ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp id 1BqWKx-0005gI-1V for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 14:18:11 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.34) id 1BqWLD-00022T-9S for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 14:18:27 +0200 To: namedroppers Subject: Re: dictionary attack on nameservers References: <20040728190530.GA22758@atoom.net> <20040728230225.0145C13DF0@sa.vix.com> <20040729102429.GB26384@nic.fr> From: Florian Weimer Date: Fri, 30 Jul 2004 14:18:27 +0200 In-Reply-To: <20040729102429.GB26384@nic.fr> (Stephane Bortzmeyer's message of "Thu, 29 Jul 2004 12:24:29 +0200") Message-ID: <871xitsn70.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Stephane Bortzmeyer: > But there are other bad uses (reverse cybersquatting is a good > example, when big corporations try to find domain names looking like > their trademarks in order to harass the holder). This is completely legal and has to be part of any effort to protect a trademark. I suppose that most organizations concerned with trademark protection already systematically scan copies of the most important zones. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 08:35:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02779 for ; Fri, 30 Jul 2004 08:35:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqWYO-000315-OO for namedroppers-data@psg.com; Fri, 30 Jul 2004 12:32:04 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqWYE-00030N-0T for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 12:31:54 +0000 Received: (debugging) helo=deneb.enyo.de ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp id 1BqWXv-0005tj-UA; Fri, 30 Jul 2004 14:31:35 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.34) id 1BqWYC-00024t-4a; Fri, 30 Jul 2004 14:31:52 +0200 To: geoff@nominet.org.uk (Geoffrey Sisson) Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: <20040729091243.0B168E7E8A@mx1.nominet.org.uk> From: Florian Weimer Date: Fri, 30 Jul 2004 14:31:52 +0200 In-Reply-To: <20040729091243.0B168E7E8A@mx1.nominet.org.uk> (Geoffrey Sisson's message of "Thu, 29 Jul 2004 10:12:43 +0100 (BST)") Message-ID: <87pt6dr807.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Geoffrey Sisson: > I can't speak for everyone, but we (Nominet) are advised that we have > a responsibility to protect the confidentiality of data in the .uk zones, > even if this cannot be done perfectly. Is this a contractual requirement (mainly to protect companies during pre-launch phases of new services), or does it follow from privacy requirements? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 09:16:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04010 for ; Fri, 30 Jul 2004 09:16:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqXBo-0008Ld-BW for namedroppers-data@psg.com; Fri, 30 Jul 2004 13:12:48 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqXBd-0008Ko-Kf for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 13:12:37 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i6UDCUZF039299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 30 Jul 2004 13:12:36 GMT (envelope-from roy+dated+1093785150.eed33a@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i6UDCU3s048031 for ; Fri, 30 Jul 2004 14:12:30 +0100 (BST) (envelope-from roy+dated+1093785150.eed33a@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i6UDCUgX048030 for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 14:12:30 +0100 (BST) (envelope-from roy+dated+1093785150.eed33a@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 30 Jul 2004 14:12:29 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16650.18749.440814.95094@giles.gnomon.org.uk> Date: Fri, 30 Jul 2004 14:12:29 +0100 To: Florian Weimer Cc: ted@NLnetLabs.nl (Ted Lindgreen), namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: <873c39sn8x.fsf@deneb.enyo.de> References: <200407291030.i6TAUGjH033734@open.nlnetlabs.nl> <873c39sn8x.fsf@deneb.enyo.de> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Florian" == Florian Weimer writes: Florian> I don't think this is an issue. Most TLD zone data is Florian> already available on request, under terms that aren't too Florian> restrictive. My understanding was that there are many ccTLD operators who do not make copies of their zones available. -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 10:29:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10004 for ; Fri, 30 Jul 2004 10:29:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqYJR-000GzI-Dt for namedroppers-data@psg.com; Fri, 30 Jul 2004 14:24:45 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqYJG-000GvG-9f for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 14:24:34 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 9AA371FE72; Fri, 30 Jul 2004 15:24:30 +0100 (BST) Date: Fri, 30 Jul 2004 15:24:27 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Roy Badami , Florian Weimer Cc: Ted Lindgreen , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: <6AFE81C9A3C54027AE038325@[192.168.100.27]> In-Reply-To: <16650.18749.440814.95094@giles.gnomon.org.uk> References: <200407291030.i6TAUGjH033734@open.nlnetlabs.nl> <873c39sn8x.fsf@deneb.enyo.de> <16650.18749.440814.95094@giles.gnomon.org.uk> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 30 July 2004 14:12 +0100 Roy Badami wrote: > Florian> I don't think this is an issue. Most TLD zone data is > Florian> already available on request, under terms that aren't too > Florian> restrictive. > > My understanding was that there are many ccTLD operators who do not > make copies of their zones available. Mine too - further that those who do make it available do prescribe certain uses contractually, including further publication. I wonder if CENTR has some stats. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 17:19:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01016 for ; Fri, 30 Jul 2004 17:19:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bqei9-000IGn-2B for namedroppers-data@psg.com; Fri, 30 Jul 2004 21:14:41 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bqehx-000ICk-Nm for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 21:14:29 +0000 Received: (debugging) helo=deneb.enyo.de ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp id 1Bqehe-0003aJ-Hj for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 23:14:10 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.34) id 1Bqeht-0003My-Jd for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 23:14:25 +0200 To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: <200407291030.i6TAUGjH033734@open.nlnetlabs.nl> <873c39sn8x.fsf@deneb.enyo.de> <16650.18749.440814.95094@giles.gnomon.org.uk> <6AFE81C9A3C54027AE038325@[192.168.100.27]> From: Florian Weimer Date: Fri, 30 Jul 2004 23:14:25 +0200 In-Reply-To: <6AFE81C9A3C54027AE038325@[192.168.100.27]> (Alex Bligh's message of "Fri, 30 Jul 2004 15:24:27 +0100") Message-ID: <87llh1jiz2.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Alex Bligh: > --On 30 July 2004 14:12 +0100 Roy Badami wrote: > >> Florian> I don't think this is an issue. Most TLD zone data is >> Florian> already available on request, under terms that aren't too >> Florian> restrictive. >> >> My understanding was that there are many ccTLD operators who do not >> make copies of their zones available. > > Mine too - further that those who do make it available do prescribe > certain uses contractually, including further publication. If the data were privacy-sensitive, it couldn't be shared at all without explicit consent from the domain name owner (at least according to most EU law). Certainly most registries, registrars and DNS service providers don't share this view. There might be other reasons to keep zone data confidential. If this is the case, they should be named. Privacy concerns are not an excuse for everything. 8-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 18:13:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04808 for ; Fri, 30 Jul 2004 18:13:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqfYh-000PMf-En for namedroppers-data@psg.com; Fri, 30 Jul 2004 22:08:59 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqfYW-000PLC-O8 for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 22:08:48 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 87CB21FE72; Fri, 30 Jul 2004 23:08:47 +0100 (BST) Date: Fri, 30 Jul 2004 23:08:43 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Florian Weimer , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: In-Reply-To: <87llh1jiz2.fsf@deneb.enyo.de> References: <200407291030.i6TAUGjH033734@open.nlnetlabs.nl> <873c39sn8x.fsf@deneb.enyo.de> <16650.18749.440814.95094@giles.gnomon.org.uk> <6AFE81C9A3C54027AE038325@[192.168.100.27]> <87llh1jiz2.fsf@deneb.enyo.de> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 30 July 2004 23:14 +0200 Florian Weimer wrote: > If the data were privacy-sensitive, it couldn't be shared at all > without explicit consent from the domain name owner (at least > according to most EU law). Whilst that is true, it isn't true in the sense you imply, as registries do demand explicit consent for certain limited disclosures in the contract of registration. See for instance: http://www.nic.uk/ReferenceDocuments/TermsAndConditions/ specifically section 6.1(c). Note the PRSS as described (compressed registry) was suspended as a service for (inter alia) privacy reasons, and is to be replaced by a public registry search service. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 19:01:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07339 for ; Fri, 30 Jul 2004 19:01:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqgKM-00059P-Lw for namedroppers-data@psg.com; Fri, 30 Jul 2004 22:58:14 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqgKB-00058O-Ok for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 22:58:04 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i6UMvr79010367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 30 Jul 2004 22:58:00 GMT (envelope-from roy+dated+1093820272.c52ad5@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i6UMvrYD051724 for ; Fri, 30 Jul 2004 23:57:53 +0100 (BST) (envelope-from roy+dated+1093820272.c52ad5@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i6UMvrZ2051723 for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 23:57:53 +0100 (BST) (envelope-from roy+dated+1093820272.c52ad5@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 30 Jul 2004 23:57:52 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16650.53872.23799.459475@giles.gnomon.org.uk> Date: Fri, 30 Jul 2004 23:57:52 +0100 To: Florian Weimer Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: <87llh1jiz2.fsf@deneb.enyo.de> References: <200407291030.i6TAUGjH033734@open.nlnetlabs.nl> <873c39sn8x.fsf@deneb.enyo.de> <16650.18749.440814.95094@giles.gnomon.org.uk> <6AFE81C9A3C54027AE038325@[192.168.100.27]> <87llh1jiz2.fsf@deneb.enyo.de> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Florian" == Florian Weimer writes: Florian> If the data were privacy-sensitive, it couldn't be shared Florian> at all without explicit consent from the domain name Florian> owner (at least according to most EU law). That's an oversimplistic view of data protection legislation. One of the principles in the UK implementation is that personal data can only be used for the purposes for which it was collected. There isn't a binary private/not-private flag; it's very much about exactly what you're allowed to do with the data that you (legitimately) have, based on what the purpose of collecting the data was, what you told the data subjects, what (if any) consent you got from the data subject, what contractual obligations you have to them, etc. I'm not making any suggestion as to how (if at all) data protection legislation impacts the issues being discussed here; just that many people seem to have an oversimplistic view of what EU data protection legislation is all about. In particular, in previous threads, people have claimed that particular issues _obviously_ couln't be an issue with data protection... Any statement like that rings alarm bells; anyone who's worked with this stuff is unlikely ever to say that something which involves data that might even remotely relate to people is _obviously_ OK. I wish people wouldn't believe that the law is as simplistic as "you're either allowed to publish this or you're not". No law works like that. Quite aside from the fact that although we talk about "publishing infomation in the DNS", a service that answers queries doesn't correspond to the traditional legal notion of publishing, and may well not be regarded as such. AXFR or NSEC may well be more likely to constitute publishing. Though in the UK, in the light of the recent case Durant v FSA, I'd be inclined to believe that zone files aren't personal data. I'd have been far less confident of that last year, though. IANAL, of course. -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 20:35:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12541 for ; Fri, 30 Jul 2004 20:35:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqhnS-000HYg-HW for namedroppers-data@psg.com; Sat, 31 Jul 2004 00:32:22 +0000 Received: from [216.220.241.233] (helo=nic-naa.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqhnH-000HVI-IT for namedroppers@ops.ietf.org; Sat, 31 Jul 2004 00:32:11 +0000 Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.11/8.12.11) with ESMTP id i6V0WDWF042655; Sat, 31 Jul 2004 00:32:14 GMT (envelope-from brunner@nic-naa.net) Message-Id: <200407310032.i6V0WDWF042655@nic-naa.net> To: Roy Badami cc: Florian Weimer , namedroppers@ops.ietf.org, brunner@nic-naa.net Subject: Re: dictionary attack on nameservers In-Reply-To: Your message of "Fri, 30 Jul 2004 23:57:52 +0100." <16650.53872.23799.459475@giles.gnomon.org.uk> Date: Sat, 31 Jul 2004 00:32:13 +0000 From: Eric Brunner-Williams in Portland Maine X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > There isn't a binary private/not-private flag; it's very much about > exactly what you're allowed to do with the data This issue was debated at length in the provreg wg. You may not know this, and may not appreciate the outcome. In a nutshell, a policy object was adopted for provisioning sessions, proximal to the p3p compact policy, and a binary toggle was added at the last minute on data elements. I'm the author of the first proposal, and I'll let you discover who was the author of the second, and infer the process issues. The context was publication via :43, and more generally, bulk transfer and any other publication mechanism, including zone file publication, and the protocol EPP. Cheers, Eric -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 30 21:22:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14464 for ; Fri, 30 Jul 2004 21:22:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqiWh-000Nlx-Ii for namedroppers-data@psg.com; Sat, 31 Jul 2004 01:19:07 +0000 Received: from [208.218.130.13] (helo=gis.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqiWW-000NlC-LA for namedroppers@ops.ietf.org; Sat, 31 Jul 2004 01:18:56 +0000 Received: from tecotoo.localhost ([207.7.195.2]) by mx05.gis.net; Fri, 30 Jul 2004 21:18:55 -0400 Received: from tecotoo (tecotoo [127.0.0.1]) by tecotoo.localhost (NTMail 3.03.0017/1.aaaa) with ESMTP id za000285 for ; Fri, 30 Jul 2004 21:19:12 +0100 Message-Id: <4.3.1.2.20040730210047.03973ea0@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 30 Jul 2004 21:11:04 -0400 To: Alex Bligh , Florian Weimer , namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: dictionary attack on nameservers Cc: Alex Bligh In-Reply-To: References: <87llh1jiz2.fsf@deneb.enyo.de> <200407291030.i6TAUGjH033734@open.nlnetlabs.nl> <873c39sn8x.fsf@deneb.enyo.de> <16650.18749.440814.95094@giles.gnomon.org.uk> <6AFE81C9A3C54027AE038325@[192.168.100.27]> <87llh1jiz2.fsf@deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 06:08 PM 7/30/2004, Alex Bligh wrote: >--On 30 July 2004 23:14 +0200 Florian Weimer wrote: > >>If the data were privacy-sensitive, it couldn't be shared at all >>without explicit consent from the domain name owner (at least >>according to most EU law). > >Whilst that is true, it isn't true in the sense you imply, as registries >do demand explicit consent for certain limited disclosures in the >contract of registration. See for instance: > > http://www.nic.uk/ReferenceDocuments/TermsAndConditions/ > >specifically section 6.1(c). Note the PRSS as described (compressed >registry) was suspended as a service for (inter alia) privacy reasons, >and is to be replaced by a public registry search service. Unless I misread it, this discusses the WHOIS data and says nothing about DNS which is the subject of this discussion. Danny >Alex > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 31 01:00:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23666 for ; Sat, 31 Jul 2004 01:00:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bqlux-000Pca-OL for namedroppers-data@psg.com; Sat, 31 Jul 2004 04:56:23 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqluO-000PZO-AP for namedroppers@ops.ietf.org; Sat, 31 Jul 2004 04:55:48 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i6V4tfqJ019757; Sat, 31 Jul 2004 05:55:42 +0100 (BST) To: Alex Bligh cc: Jay Daley , namedroppers Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Alex Bligh of "Thu, 29 Jul 2004 22:27:34 BST." <3D96637F4022B14BE90F2D9E@[192.168.100.27]> Date: Sat, 31 Jul 2004 05:55:41 +0100 Message-ID: <19756.1091249741@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Alex" == Alex Bligh writes: Alex> A successful but necessarily incomplete zone enumeration is Alex> in my book an oxymoron. We can agree to differ. IMO a successful zone enumeration is one that achieves the goals of whoever is doing the enumeration. That may well be the whole zone. But it might be the set of names that exist between iam.co.uk and izm.co.uk. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 31 09:33:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27206 for ; Sat, 31 Jul 2004 09:33:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bqtqe-000D95-Fz for namedroppers-data@psg.com; Sat, 31 Jul 2004 13:24:28 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqtqT-000D85-Kq for namedroppers@ops.ietf.org; Sat, 31 Jul 2004 13:24:17 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 340F94E719; Sat, 31 Jul 2004 15:22:48 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 956494E713 for ; Sat, 31 Jul 2004 15:22:47 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i6VDMlx0001984 for ; Sat, 31 Jul 2004 15:22:47 +0200 Received: (from olaf@localhost) by cow.ripe.net (8.12.10/8.12.6) id i6VDMlEJ017583 for namedroppers@ops.ietf.org; Sat, 31 Jul 2004 15:22:47 +0200 Received: from [128.2.10.81] (helo=smtp.andrew.cmu.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bqe9O-000DER-HV for namedroppers@ops.ietf.org; Fri, 30 Jul 2004 20:38:46 +0000 Received: from pwolf.WV.CC.CMU.EDU (CMU-100645.WV.CC.cmu.edu [128.2.67.159]) (user=dim mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i6UKckkp027237 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 30 Jul 2004 16:38:46 -0400 Date: Fri, 30 Jul 2004 16:38:47 -0400 From: David Murray To: namedroppers@ops.ietf.org Subject: IETF Session Live Internet Broadcast (MBONE **NOT NEEDED** TO VIEW) Message-ID: Originator-Info: login-token=Mulberry:01KJauqYz/G+ldGi8ybdIRE7EEHOhq/zGdxBMNbw==; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-RIPE-Spam-Status: U 0.495856 / 0.0 / 0.0 / disabled X-RIPE-Signature: a845644ad812e016fae8498a4724295e X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: This post needed manual approval. Either because it was posted by a non-subscriber or because it contained to many characters (> 20000). With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please fix your subscription addresses or shorten your postings by adding links instead of attachments ] For the IETF meeting coming up, a number of events (including one for this group) will be broadcast publicly via a technology called ESM through Carnegie Mellon University. To tune to any broadcasts, visit http://esm.cs.cmu.edu during the meetings (August 2-5) and click "Watch". To participate, you need a system with the following requirements: - A machine with Windows 98 or later, Linux, or Mac OS X - You need to have a DSL, Cable Modem, or better connection (you do *not* need mbone to view this event) Thanks! David Murray CMU End System Multicast Group -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 31 10:36:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00790 for ; Sat, 31 Jul 2004 10:36:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BquuT-000LtT-A8 for namedroppers-data@psg.com; Sat, 31 Jul 2004 14:32:29 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BquuI-000Lsl-6t for namedroppers@ops.ietf.org; Sat, 31 Jul 2004 14:32:18 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 0901E1FE7A; Sat, 31 Jul 2004 15:32:14 +0100 (BST) Date: Sat, 31 Jul 2004 15:32:06 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Danny Mayer , Florian Weimer , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: In-Reply-To: <4.3.1.2.20040730210047.03973ea0@pop.gis.net> References: <87llh1jiz2.fsf@deneb.enyo.de> <200407291030.i6TAUGjH033734@open.nlnetlabs.nl> <873c39sn8x.fsf@deneb.enyo.de> <16650.18749.440814.95094@giles.gnomon.org.uk> <6AFE81C9A3C54027AE038325@[192.168.100.27]> <87llh1jiz2.fsf@deneb.enyo.de> <4.3.1.2.20040730210047.03973ea0@pop.gis.net> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 30 July 2004 21:11 -0400 Danny Mayer wrote: >>> If the data were privacy-sensitive, it couldn't be shared at all >>> without explicit consent from the domain name owner (at least >>> according to most EU law). >> >> Whilst that is true, it isn't true in the sense you imply, as registries >> do demand explicit consent for certain limited disclosures in the >> contract of registration. See for instance: >> >> http://www.nic.uk/ReferenceDocuments/TermsAndConditions/ >> >> specifically section 6.1(c). Note the PRSS as described (compressed >> registry) was suspended as a service for (inter alia) privacy reasons, >> and is to be replaced by a public registry search service. > > Unless I misread it, this discusses the WHOIS data and says nothing about > DNS which is the subject of this discussion. Section 6 says what may be done with personal data (including whois and PRSS). I made the point as Florian was arguing that "if the zonefile can be ftp'd under contract, there cannot be a problem with enumeration". That is simply not the case, as contracts of registration (in the UK and elsewhere) provide for certain data to be given to limited numbers of other people under the safeguard of contract - which is entirely different from giving that data to anyone. Straight from the EU directive that drove the implementing legislation (for instance) you cannot export the data outside the EU without certain protections. So sadly Florian's argument (that if you can ftp under contract lawfully, there is necessarily no problem with enumerability) is just plain wrong in law. A much better argument to make Florian's point would be that the data is not personal data. That is at least arguable. Our advice is that it may well be. But as we said last time we went around this big loop - it isn't just a data protection issue, it's also a publication of database copyright issue, and a POLICY issue on (inter-alia) privacy, It is entirely possible that (for instance) site-finder infringed no national law, but offended the internet community's views on policy. I am not sure this "why is there the requirement" debate is either productive or useful. I'd prefer we did "what is the requirement" (from those who have it), and what are the proposals to fix it. Then, if some have the requirement, and others, incomprehending of the reasons for it (and who knows perhaps they are right) don't, it boils down to "does the next revision of the protocol include the option". No-one has yet suggested an enumerability option is a bad thing, apart from the protocol complexity it generates. I use requirement in the singular above - however, if we are reopening cans of worms, I would have thought it might be a useful requirement for large zone file operators to have features which minimize the CPU required to sign zonefiles where a minimum number of the delegations themselves require signing - this would ease transition to DNSSEC and encourage deployment; I note that sub 5 minute zone updates are now becoming the norm (or at least are on people's near term work plans), whereas they weren't (AFAIK) when this was last discussed. I have deliberately phrased the above without mentioning previously suggested implementations or -arends. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 31 10:52:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01323 for ; Sat, 31 Jul 2004 10:52:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bqv8t-000NhH-Ek for namedroppers-data@psg.com; Sat, 31 Jul 2004 14:47:23 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bqv8i-000Nga-Mv for namedroppers@ops.ietf.org; Sat, 31 Jul 2004 14:47:12 +0000 Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i6VElAHj004223; Sat, 31 Jul 2004 10:47:10 -0400 (EDT) Received: from egyptian-gods.mit.edu (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id i6VEl8oM009473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 31 Jul 2004 10:47:09 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i6VEl6Sv005620; Sat, 31 Jul 2004 10:47:06 -0400 Subject: Re: dictionary attack on nameservers From: Greg Hudson To: Alex Bligh Cc: namedroppers@ops.ietf.org In-Reply-To: References: <87llh1jiz2.fsf@deneb.enyo.de> <200407291030.i6TAUGjH033734@open.nlnetlabs.nl> <873c39sn8x.fsf@deneb.enyo.de> <16650.18749.440814.95094@giles.gnomon.org.uk> <6AFE81C9A3C54027AE038325@[192.168.100.27]> <87llh1jiz2.fsf@deneb.enyo.de> <4.3.1.2.20040730210047.03973ea0@pop.gis.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1091285224.16991.283.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 31 Jul 2004 10:47:05 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2004-07-31 at 10:32, Alex Bligh wrote: > But as we said last time we went around this big loop - it isn't just a > data protection issue, it's also a publication of database copyright issue, I'd like to understand this point better. Who would be infringing upon whose copyright? (Separately, I don't know the status of database copy protection laws around the world; traditionally, information such as you'd find in the phone book is not subject to copyright. But my main question isn't related to that issue; I can't understand how there would be a copyright issue with a TLD or SLD publishing its own database.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 31 11:10:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01758 for ; Sat, 31 Jul 2004 11:10:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqvRn-0000rv-H0 for namedroppers-data@psg.com; Sat, 31 Jul 2004 15:06:55 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqvRc-0000qD-FK for namedroppers@ops.ietf.org; Sat, 31 Jul 2004 15:06:44 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 88CA01FE7A; Sat, 31 Jul 2004 16:06:43 +0100 (BST) Date: Sat, 31 Jul 2004 16:06:39 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Greg Hudson Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: <17AA32A14AD7D34428A6135C@[192.168.100.27]> In-Reply-To: <1091285224.16991.283.camel@egyptian-gods.mit.edu> References: <87llh1jiz2.fsf@deneb.enyo.de> <200407291030.i6TAUGjH033734@open.nlnetlabs.nl> <873c39sn8x.fsf@deneb.enyo.de> <16650.18749.440814.95094@giles.gnomon.org.uk> <6AFE81C9A3C54027AE038325@[192.168.100.27]> <87llh1jiz2.fsf@deneb.enyo.de> <4.3.1.2.20040730210047.03973ea0@pop.gis.net> <1091285224.16991.283.camel@egyptian-gods.mit.edu> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 31 July 2004 10:47 -0400 Greg Hudson wrote: >> But as we said last time we went around this big loop - it isn't just a >> data protection issue, it's also a publication of database copyright >> issue, > > I'd like to understand this point better. Who would be infringing upon > whose copyright? > > (Separately, I don't know the status of database copy protection laws > around the world; traditionally, information such as you'd find in the > phone book is not subject to copyright. But my main question isn't > related to that issue; I can't understand how there would be a copyright > issue with a TLD or SLD publishing its own database.) It isn't about the TLD infringing it's own copyright, it's about later enforceability of copyright. IANAL but AIUI it works this way: there is a separate copyright on a compilation and/or database than on its constituent items. So if, for instance, you compile and publish a compendium of poetry, you hold a copyright on the compiled work, even though you may only have a license to use the poems therein. [I think database copyright is technically different from compilations but not such that it matters here]. If, however, you then publish the work to all and sundry without specific terms of license, it dilutes your ability to enforce license terms against use of the work later. As a concrete example (which I could not comment on before as it was at trial), Nominet recently took action in Australia against a number of companies and individuals allegedly involved in a data mining attack; Nominet alleged the information was then used, inter alia, for provision of misleading invoice-like documents, contrary to various Australian trade practices legislation (I think you can guess the picture). 4 out of 5 who admitted liability just prior to trial, one went to trial and we await verdict. We have taken similar action before, and will continue to do so in the future (even though they may each cost many hundreds of thousands of dollars if not more) on public policy grounds. How they got the data is not relevant here, but, at least for some of the claims, a key factor was not only that they obtained copies of a database, but also that they had a no license to do so. If it were the case that we published the database as a whole without license requirements (i.e. without proscribing the activity a malefactor performed), it would make it harder to make a successful claim which rested on the use of the database without license. For these purposes, it is not necessarily relevant whether some fraction of the database (even a large fraction) could be compiled from other sources (for instance Paul's in-addr.arpa or google logs), because Nominet would not themselves be publishing those - that's someone making their own compilation. The reason for the public policy is many fold, but for one, those supplying the data that generates the compilation do so on the basis of it being used for certain purposes, and not for others - they simply don't want the data they supply used for spam, scams, etc.; that's not a legal driver (so if Nominet were a for-profit body after the last dollar possible this problem would no doubt be solved in the market place for a suitable number of $), that's a policy driver. There are some other issues to do with the triangular relationship between governments, ICANN and ccTLDs - see all the hoo-haa about ccTLD zonefile escrow a year or two ago - but I don't propose to go into those here as they are long and seriously off-topic. Drop me a line off list if you really want to know. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 31 20:25:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24941 for ; Sat, 31 Jul 2004 20:25:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Br45b-000NZk-9I for namedroppers-data@psg.com; Sun, 01 Aug 2004 00:20:35 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Br45Q-000NZ0-5T for namedroppers@ops.ietf.org; Sun, 01 Aug 2004 00:20:24 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 2854D1C0C4; Sun, 1 Aug 2004 09:14:19 +0900 (JST) To: Erik.Nordmark@sun.com Cc: miekg@atoom.net, pekkas@netcore.fi, namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface In-Reply-To: Your message of "Thu, 29 Jul 2004 00:49:41 -0700 (PDT)" References: X-Mailer: Cue version 0.8 (040717-1035/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040801001419.2854D1C0C4@coconut.itojun.org> Date: Sun, 1 Aug 2004 09:14:19 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On the other hand, introducing an new ai_ttl field at the end of struct > addrinfo can be done without any effect on binaries (since the field offsets of > the other fields do not change, and freeaddrinfo() will free the correct size > structure). Applications which want to use ai_ttl would then do > > call getaddrinfo... > #ifdef _GETADDRINFO_AI_TTL > ttl = ai->ai_tll; > #else > ttl = 30; /* Or some other constant */ > #endif > > While this is more painful than if we'd included ai_ttl from the start, > it seems to be less painful than standardizing getrrsetbyname() to > ensure portability of that interface across platforms. getaddrinfo() is not a DNS-only function; it can lookup hostname-to address using /etc/hosts, NIS, LDAP, whatever you have. what value would you put in to ai_ttl when the lookup is done by non-DNS method? itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 31 20:40:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25699 for ; Sat, 31 Jul 2004 20:40:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Br4Lu-000PT0-Mo for namedroppers-data@psg.com; Sun, 01 Aug 2004 00:37:26 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Br4Lk-000PRy-2p for namedroppers@ops.ietf.org; Sun, 01 Aug 2004 00:37:16 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4D95513DE9; Sun, 1 Aug 2004 00:37:10 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: itojun@itojun.org (Jun-ichiro itojun Hagino) Cc: Erik.Nordmark@sun.com, miekg@atoom.net, pekkas@netcore.fi, namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface In-Reply-To: Message from itojun@itojun.org (Jun-ichiro itojun Hagino) of "Sun, 01 Aug 2004 09:14:19 +0900." <20040801001419.2854D1C0C4@coconut.itojun.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 01 Aug 2004 00:37:10 +0000 Message-Id: <20040801003710.4D95513DE9@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i don't think expansing getaddrinfo/getnameinfo to return ttl is the right approach. we need a "getrrsetbyname" for dns-aware applications that returns ttl, security status, and so on. it should be in an rfc, like the advanced ipv6 api document. it should be pushed toward posix. isc had proposed this to some of our funding agencies but i believe it was "too much too soon" at the time. perhaps MODA will pick it up now. re: > To: Erik.Nordmark@sun.com > Cc: miekg@atoom.net, pekkas@netcore.fi, namedroppers@ops.ietf.org, > dnsop@lists.uoregon.edu > Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface > X-Mailer: Cue version 0.8 (040717-1035/itojun) > Date: Sun, 1 Aug 2004 09:14:19 +0900 (JST) > From: itojun@itojun.org (Jun-ichiro itojun Hagino) > Sender: owner-namedroppers@ops.ietf.org > > > On the other hand, introducing an new ai_ttl field at the end of struct > > addrinfo can be done without any effect on binaries (since the field offsets of > > the other fields do not change, and freeaddrinfo() will free the correct size > > structure). Applications which want to use ai_ttl would then do > > > > call getaddrinfo... > > #ifdef _GETADDRINFO_AI_TTL > > ttl = ai->ai_tll; > > #else > > ttl = 30; /* Or some other constant */ > > #endif > > > > While this is more painful than if we'd included ai_ttl from the start, > > it seems to be less painful than standardizing getrrsetbyname() to > > ensure portability of that interface across platforms. > > getaddrinfo() is not a DNS-only function; it can lookup hostname-to > address using /etc/hosts, NIS, LDAP, whatever you have. what value > would you put in to ai_ttl when the lookup is done by non-DNS method? > > itojun > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: