From owner-namedroppers@ops.ietf.org Tue Mar 1 00:15:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19547 for ; Tue, 1 Mar 2005 00:15:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5zcg-000Gjg-FC for namedroppers-data@psg.com; Tue, 01 Mar 2005 05:08:42 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5zce-000GjO-RC for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 05:08:40 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 2D9BA677EF for ; Tue, 1 Mar 2005 05:08:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j2158aab072131 for ; Tue, 1 Mar 2005 16:08:36 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200503010508.j2158aab072131@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt Date: Tue, 01 Mar 2005 16:08:36 +1100 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk HMAC Truncation. Looking at this there is nothing to say whether a reply has to use the same number of bits as the query? i.e. Can a server respond to a truncated HMAC-SHA1 w/ a full HMAC-SHA1? If you are rejecting a TSIG because the number of bits is too small what is the RCODE in the TSIG? BADAUTH+???? Is the server supposed to auto adjust to the client within limits (max(80 bits, half digest bits)) or is the server supposed to specify a absolute number of expected bits or a minimum number of expected bits. How does a server, if it rejecting because of too few bits, signal the minimum number of bits it will accept for this key. Is truncation just too much of a complication? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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 Mar 1 02:39:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20651 for ; Tue, 1 Mar 2005 02:39:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D61uN-000ESE-Mq for namedroppers-data@psg.com; Tue, 01 Mar 2005 07:35:07 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D61uK-000ER0-EA for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 07:35:04 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 82808269C3; Tue, 1 Mar 2005 08:35:03 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 85BD4269E7 for ; Tue, 1 Mar 2005 08:35:01 +0100 (CET) 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 j217Z1et011270 for ; Tue, 1 Mar 2005 08:35:01 +0100 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id j217Z11e019916 for namedroppers@ops.ietf.org; Tue, 1 Mar 2005 08:35:01 +0100 Date: Tue, 1 Mar 2005 08:35:01 +0100 From: Olaf Kolkman Message-Id: <200503010735.j217Z11e019916@x50.ripe.net> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: U 0.491037 / -5.9 X-RIPE-Signature: f5e74d093ba7b4bb9c4a66497a7d693e X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 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 --- 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.8 2005/01/12 15:54: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 Tue Mar 1 05:22:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09696 for ; Tue, 1 Mar 2005 05:22:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D64RV-000BVP-9o for namedroppers-data@psg.com; Tue, 01 Mar 2005 10:17:29 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D64RU-000BVC-7j for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 10:17:28 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j21ADqI3025165 for ; Tue, 1 Mar 2005 05:13:52 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAtraygX; Tue, 1 Mar 05 05:13:47 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j21AFSrK010750; Tue, 1 Mar 2005 05:15:28 -0500 (EST) Date: Tue, 1 Mar 2005 05:15:28 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: =?X-UNKNOWN?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT_co-chair?= cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: TSIG/SHA document In-Reply-To: <16924.50357.206629.553474@guava.araneus.fi> Message-ID: References: <6.2.0.14.2.20050223103137.04c94b20@localhost> <16924.50357.206629.553474@guava.araneus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I concur with Andreas's well-written comments, particularly: > What would be particularly bad is if someone made their implementation > accept messages with the MAC truncated to a single octet just because > the draft says "MAY implement any or all other truncations". I'm not sure if in-band communication of truncation minima is required, but this doc at least needs more text devoted to the topic, as Andreas has suggested. I'd also be happy with just removing truncation, though I imagine there's some good reason for it that I haven't heard yet. Other than that, the doc looks good -- I'd be happy to see it advance. For the benefit of others who may read this doc, I initially wondered why this doc uses algorithm names in a different namespace than the one defined in 2845. Section 7 of 2845 says that is to be expected. And a nit: there's a normative reference to 2434, but no citation to 2434 in the doc. The RFC Editor will toss that one back. -- 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 Mar 1 07:54:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20213 for ; Tue, 1 Mar 2005 07:54:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D66pT-00094R-MC for namedroppers-data@psg.com; Tue, 01 Mar 2005 12:50:23 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D66pS-00093h-7x for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 12:50:22 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 5C6122DEA1; Tue, 1 Mar 2005 13:50:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 55AED2DEA0 for ; Tue, 1 Mar 2005 13:50:19 +0100 (CET) Date: Tue, 1 Mar 2005 13:50:19 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-Reply-To: Message-ID: References: <421D7625.8090201@algroup.co.uk> <4220F4F0.50602@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 28 Feb 2005, Samuel Weiler wrote: > Think about this from the perspective of a zone owner: "if I sign my > zone using new NSEC3 hash algorithm 42, many/most resolvers will > discard the NSEC3's, resulting in validation failures in my zone -- > among other things, unsecure delegations FROM my zone will vanish, > since resolvers discard the NSEC3's needed to prove that they're > unsecure". And none of this requires an attacker -- this is what > happens with well-behaved validators using the algorithm your doc > describes. That's a pretty strong disincentive to use any new > algorithm. > > > If you can't change the algorithm with some grace, I think > > > parameterizing it is misleading and adds unnecessary complexity. > > > > I don't believe you've demonstrated that inability. > > And I believe this document hasn't even postulated, much less > demonstrated, an ability to gracefully roll them. Samuel, Ben, The issue of changing algorithms, or changing any parameter for that matter, becomes a problem when the behaviour of this change is not properly documented. Specific behavior falls into two classes: if the new parameter value is known: behave accordingly. If value is unknown, follow the path of least destruction. Firstly, lets agree that changing the hash-function field value inside the NSEC3 requires re-signing the record. If an adversary changes the hash-function field value without re-signing, the verification of the RR will fail, and will be noticed by the validating resolver. Lets call this state 'failed signature verification'. Essentially, the validation process will end here, if all sources are exhausted, further, the resolver process will end here as well, since it has encountered a fatal error. Secondly, lets agree that an RR with a hash-function field value unknown to the resolver, though with a proper signature, will be verified successfully. Lets call this state 'unknown NSEC3 hash function'. The validation process will ignore this NSEC3, and therefor can't proof (non) existence. The resolver process will end here as well, since it has encountered a fatal error. Basically, there are three mayor effects: 1) negative responses (i.e. no such name, no such type) will deem invalid. (for argument sake, this includes responses due to wildcard expansions). 2) positive responses can be replaced by any negative response from the same zone. Because the hash-function is not known, QNAME can not be checked against the interval. 3) the status of delegation points is unknown, since the interval of the related NSEC3 RR can not be checked, hence, the DS bit status is not valid. The most destructive action an adversary can mount at this point is a denial of service. In contrast: When rolling DS 'digest type', multiple field values can exist in a single RRset, as long as one value is known. It is not possible to have multiple NSEC3 RRs with different 'hash-function' values in a single NSEC3 RRset, since hashing a name using different functions, leads to different hashed owner names. Indeed, there is no easy way to roll NSEC3 hash-functions, and no way to safely include multiple forms of denial in a response. Therefor, the question 'why parameterize hash-functions' is valid. The benefits in parameterizing the hash-function inside NSEC3 as opposed to create a NSEC_SHA1 and NSEC_SHA256 (have a NSEC type per function) are ephemeral when there are just 2 values defined, and the rest is coined 'unknown'. There are benefits when there is a manifold of known hash-functions defined. 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 Mar 1 08:47:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25362 for ; Tue, 1 Mar 2005 08:47:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D67dv-000IiL-91 for namedroppers-data@psg.com; Tue, 01 Mar 2005 13:42:31 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D67du-000Ii5-37 for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 13:42:30 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j21DgPHD049138 for ; Tue, 1 Mar 2005 14:42:25 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.13.3/8.13.1/Submit) id j21DgP9a049137 for namedroppers@ops.ietf.org; Tue, 1 Mar 2005 14:42:25 +0100 (CET) (envelope-from ted) Message-Id: <200503011342.j21DgP9a049137@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Tue, 1 Mar 2005 14:42:25 +0100 In-Reply-To: "Roy Arends's message as of Mar 1, 14:11" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Roy Arends, on Mar 1, 14:11, in "Re: comments on nsec ..."] Roy, I'm not sure I fully understand what you are saying, but I read from your argumentation: > Firstly, lets agree that changing the hash-function field value inside the > NSEC3 requires re-signing the record. If an adversary changes the > hash-function field value without re-signing, the verification of the > RR will fail ..... that it leads to: > Basically, there are three mayor effects: > > 1) negative responses (i.e. no such name, no such type) will deem invalid. > (for argument sake, this includes responses due to wildcard expansions). > > 2) positive responses can be replaced by any negative response from the > same zone. Because the hash-function is not known, QNAME can not be > checked against the interval. > > 3) the status of delegation points is unknown, since the interval of the > related NSEC3 RR can not be checked, hence, the DS bit status is not > valid. which then translates into: > The most destructive action an adversary can mount at this point is a > denial of service. If I understand this correctly, then this expands to: We don't really need the authenticated denial of existance machinery at all, as the most destructive action is a DOS. If this were true, then we could do away with NSEC altogether, but I'm affraid it isn't true as there was (and still is, I think) broad consensus that authenticated denial of existance is an essential part of DNSSEC. 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 Tue Mar 1 08:57:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26258 for ; Tue, 1 Mar 2005 08:57:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D67nj-000KfZ-T3 for namedroppers-data@psg.com; Tue, 01 Mar 2005 13:52:39 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D67nj-000KfB-0r for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 13:52:39 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 6EDE826BA0; Tue, 1 Mar 2005 14:52:38 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 91E9626C77; Tue, 1 Mar 2005 14:52:37 +0100 (CET) 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 j21Dqbet014640; Tue, 1 Mar 2005 14:52:37 +0100 Date: Tue, 1 Mar 2005 14:52:37 +0100 From: "Olaf M. Kolkman" To: Samuel Weiler Cc: ben@algroup.co.uk, namedroppers@ops.ietf.org, roy@dnss.ec Subject: Re: comments on nsec3-01 Message-Id: <20050301145237.2cc02d9d.olaf@ripe.net> In-Reply-To: References: <421D7625.8090201@algroup.co.uk> 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-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.014561 / -5.9 X-RIPE-Signature: f4e674b57218c8117dfea72c21e17949 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler: > This reminds me of a discussion from 1.5 years ago: > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01539.html > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01773.html I think the essential difference between the threat in that thread and the threat in this thread is that one could do an attack by stripping the RRSIGs with known algorithms and insert RRSIGs with unknown algorithms, which would go unnoticed as the RRSIGs are not signed. An attacker cannot simply insert the '42-Hash" since the NSEC3 RR will need to cary a valid signature. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org -- 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 Mar 1 09:10:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27444 for ; Tue, 1 Mar 2005 09:10:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D681G-000NQa-79 for namedroppers-data@psg.com; Tue, 01 Mar 2005 14:06:38 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D681F-000NQD-7f for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 14:06:37 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 998382DF29; Tue, 1 Mar 2005 15:06:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 979D52DF21 for ; Tue, 1 Mar 2005 15:06:35 +0100 (CET) Date: Tue, 1 Mar 2005 15:06:35 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-Reply-To: <200503011342.j21DgP9a049137@open.nlnetlabs.nl> Message-ID: References: <200503011342.j21DgP9a049137@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 1 Mar 2005, Ted Lindgreen wrote: > [Quoting Roy Arends, on Mar 1, 14:11, in "Re: comments on nsec ..."] > > Roy, > > I'm not sure I fully understand what you are saying, but I read > from your argumentation: > > > Firstly, lets agree that changing the hash-function field value inside the > > NSEC3 requires re-signing the record. If an adversary changes the > > hash-function field value without re-signing, the verification of the > > RR will fail ..... > > that it leads to: Nope. The 'firstly' and 'secondly' I wrote simply makes the resolution fatal. I explicitly say that. Then I continue and argue the effect of usage of unknown values for the hash-function field in the nsec3 RDATA. > > Basically, there are three mayor effects: > > > > 1) negative responses (i.e. no such name, no such type) will deem invalid. > > (for argument sake, this includes responses due to wildcard expansions). > > > > 2) positive responses can be replaced by any negative response from the > > same zone. Because the hash-function is not known, QNAME can not be > > checked against the interval. > > > > 3) the status of delegation points is unknown, since the interval of the > > related NSEC3 RR can not be checked, hence, the DS bit status is not > > valid. > > which then translates into: > > > The most destructive action an adversary can mount at this point is a > > denial of service. 'zactly. > If I understand this correctly, then this expands to: > > We don't really need the authenticated denial of existance machinery > at all, as the most destructive action is a DOS. Nope. Not at all. You're jumping to the wrong conclusion. Let me rephrase that so you might understand what was between the lines: The most destructive action an adversary can mount at this point is a denial of service, as opposed to altering a response in such a way that a resolver now regards data as 'cryptographically not secured' > If this were true, Which is not. Please re-read my message. 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 Mar 1 09:29:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29030 for ; Tue, 1 Mar 2005 09:29:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D68JG-0000CT-6K for namedroppers-data@psg.com; Tue, 01 Mar 2005 14:25:14 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D68JD-0000CD-61 for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 14:25:11 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 98A2B33C45; Tue, 1 Mar 2005 14:25:09 +0000 (GMT) Message-ID: <42247ACF.7060908@algroup.co.uk> Date: Tue, 01 Mar 2005 14:23:11 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <421D7625.8090201@algroup.co.uk> <4220F4F0.50602@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > Indeed, there is no easy way to roll NSEC3 hash-functions, and no way to > safely include multiple forms of denial in a response. Therefor, the > question 'why parameterize hash-functions' is valid. It seems to me that it would be fine to include multiple responses, one per desired hash. During introduction of a new hash type, return both the old and new types. If size of response is an issue, I guess the client would have to indicate which version on NSEC3 it supported. 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 Tue Mar 1 09:29:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29053 for ; Tue, 1 Mar 2005 09:29:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D68Ir-00009v-AK for namedroppers-data@psg.com; Tue, 01 Mar 2005 14:24:49 +0000 Received: from [216.148.227.89] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D68Io-00009c-PT for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 14:24:46 +0000 Received: from pothole.dnsalias.com ([24.62.71.160]) by comcast.net (rwcrmhc14) with ESMTP id <200503011424450140033e9se>; Tue, 1 Mar 2005 14:24:46 +0000 Received: by pothole.dnsalias.com (Postfix, from userid 1026) id 4637991479; Tue, 1 Mar 2005 09:24:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by pothole.dnsalias.com (Postfix) with ESMTP id 2797691474 for ; Tue, 1 Mar 2005 09:24:45 -0500 (EST) Date: Tue, 1 Mar 2005 09:24:45 -0500 (EST) From: Donald Eastlake III X-X-Sender: donaldeastlakeiii@mini.pothole.com To: namedroppers@ops.ietf.org Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt In-Reply-To: <200503010508.j2158aab072131@drugs.dv.isc.org> Message-ID: References: <200503010508.j2158aab072131@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk TSIG is only used by prior agreement of the parties involved. Policies as to what algorithms to use and what truncation to allow are all deliberately left open. If they feel like it, the parties could not only use asymmetric amounts of truncation but different hash algorithms in each direction. But one would expect that in most real cases they would use a fixed algorithm and truncation. But, since amounts of truncation are clearly ordered and, arguably, current hash algorithms also are, I suppose that more flexible code could be configured with a minimum hash algorithm and a minimum number of octets of hash. If the signature is too weak for the receiver's policy, I don't see this as different form the signature being missing. This should be probably all be explicitly stated in the document. Truncation is trivial and most IETF security protocols provide explicitly for things like SHA-1 truncated to 96 bits. There are people who believe that a little truncation improves security by revealing less information to crackers. I don't see any reason to fail to provide truncation cababilities in TSIG. Thanks, Donald ==================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Tue, 1 Mar 2005, Mark Andrews wrote: > Date: Tue, 01 Mar 2005 16:08:36 +1100 > From: Mark Andrews > To: namedroppers@ops.ietf.org > Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt > > > HMAC Truncation. > > Looking at this there is nothing to say whether a reply > has to use the same number of bits as the query? > > i.e. > Can a server respond to a truncated HMAC-SHA1 w/ > a full HMAC-SHA1? > > If you are rejecting a TSIG because the number of bits is > too small what is the RCODE in the TSIG? BADAUTH+???? > > Is the server supposed to auto adjust to the client within > limits (max(80 bits, half digest bits)) or is the server > supposed to specify a absolute number of expected bits or > a minimum number of expected bits. > > How does a server, if it rejecting because of too few bits, > signal the minimum number of bits it will accept for this > key. > > Is truncation just too much of a complication? > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > -- > 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 Tue Mar 1 09:34:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29469 for ; Tue, 1 Mar 2005 09:34:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D68Pg-0001Qv-Hs for namedroppers-data@psg.com; Tue, 01 Mar 2005 14:31:52 +0000 Received: from [204.127.202.59] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D68Pd-0001Pq-EL for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 14:31:49 +0000 Received: from pothole.dnsalias.com ([24.62.71.160]) by comcast.net (sccrmhc14) with ESMTP id <2005030114314801400s9fe1e>; Tue, 1 Mar 2005 14:31:48 +0000 Received: by pothole.dnsalias.com (Postfix, from userid 1026) id 6CBD7914AB; Tue, 1 Mar 2005 09:31:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by pothole.dnsalias.com (Postfix) with ESMTP id 1D7ED914A4 for ; Tue, 1 Mar 2005 09:31:47 -0500 (EST) Date: Tue, 1 Mar 2005 09:31:47 -0500 (EST) From: Donald Eastlake III X-X-Sender: donaldeastlakeiii@mini.pothole.com To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: TSIG/SHA document In-Reply-To: <6.2.0.14.2.20050223113008.02ee7150@localhost> Message-ID: References: <6.2.0.14.2.20050223103137.04c94b20@localhost> <20050223162325.GA4687@nic.fr> <6.2.0.14.2.20050223113008.02ee7150@localhost> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-910715544-1109686561=:23771" Content-ID: X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-910715544-1109686561=:23771 Content-Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; FORMAT=flowed Content-ID: Content-Transfer-Encoding: QUOTED-PRINTABLE Needless to say, I support the document but enough requests have been=20 posted for some more security guidance that I think I should revise it=20 once more and post after the IETF meeting. Guidance as to the level of implementation requirement for varous hash functions would be appreciated or should they just be left as they are in the current draft? There is some mention in the document of weaknesses being found in hash=20 algorithms recently. I suppose it should say a little more but I do not=20 see any reason to expand substantially on that or try to make the draft=20 into a treatise on the subject. From=20the draft: "increasingly successful cryptanalytic attacks are being made on the shorter hashes" Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Wed, 23 Feb 2005, [iso-8859-1] =D3lafur Gu=F0mundsson wrote: > Date: Wed, 23 Feb 2005 12:01:54 -0500 > From: "[iso-8859-1] =D3lafur Gu=F0mundsson" > To: Stephane Bortzmeyer > Cc: namedroppers@ops.ietf.org > Subject: Re: DNSEXT WG Last Call: TSIG/SHA document >=20 > At 11:23 23/02/2005, Stephane Bortzmeyer wrote: >> On Wed, Feb 23, 2005 at 10:36:06AM -0500, >> =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote >> a message of 28 lines which said: >>=20 >> > The TSIG protocol provides transaction level authentication for DNS. >> > TSIG is extensible through the definition of new algorithms. This >> > document specifies an algorithm(s) from the SHA algorithm family. >>=20 >> The Security Considerations do not mention the very recent attacks on >> SHA-1, which, IMHO (I am not a cryptographer) should stop this >> document from going on the Standards Track (pending further studies). >>=20 >> http://www.schneier.com/blog/archives/2005/02/sha1_broken.html > > > > Excellent point, the document should address this issue before being > advanced. > > I checked with some people that know cryptography before issuing this > last call, they do not see an issue with THIS USE of SHA-1. > > > > According to cryptographers: > The HMAC addition protects the underlying algorithm from the > vulnerabilities found in SHA-1. > http://jis.mit.edu/pipermail/saag/2005q1/001184.html > > IMHO more given the short time TSIG signatures are valid, and > the great control each TSIG generator has over the input this > is not a great risk. > > > > Having said that the WG can decide to list SHA-1 as Optional, > not mandatory as in the current draft. > Note also HMAC/SHA-256 is listed as mandatory to implement and that is > the algorithm people should be using if they want to significantly > improve security over HMAC/MD5 > > =D3lafur=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: > > --0-910715544-1109686561=:23771-- -- 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 Mar 1 09:50:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01394 for ; Tue, 1 Mar 2005 09:50:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D68e7-0003zj-5C for namedroppers-data@psg.com; Tue, 01 Mar 2005 14:46:47 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D68e6-0003zV-2K for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 14:46:46 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j21EkeE6075310; Tue, 1 Mar 2005 15:46:40 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.13.3/8.13.1/Submit) id j21EkecW075309; Tue, 1 Mar 2005 15:46:40 +0100 (CET) (envelope-from ted) Message-Id: <200503011446.j21EkecW075309@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Tue, 1 Mar 2005 15:46:40 +0100 In-Reply-To: "Roy Arends's message as of Mar 1, 15:11" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Roy Arends , namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Roy Arends, on Mar 1, 15:11, in "Re: comments on nsec ..."] .... > > > The most destructive action an adversary can mount at this point is a > > > denial of service. > > 'zactly. Ok... > > If I understand this correctly, then this expands to: > > > > We don't really need the authenticated denial of existance machinery > > at all, as the most destructive action is a DOS. > > Nope. Not at all. You're jumping to the wrong conclusion. > > Let me rephrase that so you might understand what was between the lines: Sorry, I keep having difficulties with reading between your lines... > The most destructive action an adversary can mount at this point is a > denial of service, as opposed to altering a response in such a way that a > resolver now regards data as 'cryptographically not secured' > > > If this were true, > > Which is not. Please re-read my message. Does that reviel the unwritten lines in between? I doubt it... >From what I understand sofar: - there is a timeframe in which a good and correctly configured resolvers can not (are not able to) verify some part of the authenticated denial of existance machinery; - Sam then argues that this would not be an incentive for a domainholder to get into this stuff; - Roy writes that it isn't that bad as it's only a DOS. What I understand is that, with a good and correctly configured resolver, the resolver-user may encounter a part of the world where authenticated denial of existance can not be verified. This gives two choices: 1. Be strict and accept that this part drops from your world; 2. Be lenient, and accept reduced security. >From the perspective of a domainholder, I think Sam is right: if the domain is valuable, the domainholder will be reluctant to risk that his domain becomes invisible. However, more important than above details is, IMHO, that NSEC3 is making DNSSEC so much more complicated that it becomes difficult for even the people working on DNSSEC to comprehend what exactly are gaping security holes, or just risks, threats, or only minor inconveniences. -- 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 Tue Mar 1 10:34:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06978 for ; Tue, 1 Mar 2005 10:34:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D69Jq-000BB2-WB for namedroppers-data@psg.com; Tue, 01 Mar 2005 15:29:55 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D69Jq-000BAn-0U for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 15:29:54 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 4D59A2DEA0; Tue, 1 Mar 2005 16:29:51 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 4BCAE2DE35; Tue, 1 Mar 2005 16:29:51 +0100 (CET) Date: Tue, 1 Mar 2005 16:29:50 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Ted Lindgreen Cc: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-Reply-To: <200503011446.j21EkecW075309@open.nlnetlabs.nl> Message-ID: References: <200503011446.j21EkecW075309@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 1 Mar 2005, Ted Lindgreen wrote: > >From what I understand sofar: > > - there is a timeframe in which a good and correctly configured > resolvers can not (are not able to) verify some part of the > authenticated denial of existance machinery; > - Sam then argues that this would not be an incentive for a > domainholder to get into this stuff; Exactly. > - Roy writes that it isn't that bad as it's only a DOS. No. No. No. No. No. Please quote the part where I say that. Roy wrote that its a DoS. Roy did NOT write it isn't that bad. I agree with Samuel. I noted it is hard to roll the hash-function field. So did he. > What I understand is that, with a good and correctly configured > resolver, the resolver-user may encounter a part of the world where > authenticated denial of existance can not be verified. This gives > two choices: > > 1. Be strict and accept that this part drops from your world; Hence a denial of service. > 2. Be lenient, and accept reduced security. You call this lenient ? Lenient to whom ? I call this plain stupid. > From the perspective of a domainholder, I think Sam is right: > if the domain is valuable, the domainholder will be reluctant > to risk that his domain becomes invisible. Hmmmm. If the domain is valuable, wouldn't you want resolvers to be strict ? Enforce the upmost scrutiny ? Therefor use a better hash-function ? You're confused. You're mixing valuable with visible. > However, more important than above details is, IMHO, that NSEC3 is > making DNSSEC so much more complicated that it becomes difficult > for even the people working on DNSSEC to comprehend what exactly > are gaping security holes, or just risks, threats, or only minor > inconveniences. NSEC3 is complex, just a little more then DNSSEC. Complicated is a personal view. People who are working on DNSSEC and can't distinguish between gaping security holes, or just risks, can contact me anytime. Ted, contact me off-list if you need help with your learning curve. 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 Mar 1 11:38:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14368 for ; Tue, 1 Mar 2005 11:38:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6AJT-0000fk-1I for namedroppers-data@psg.com; Tue, 01 Mar 2005 16:33:35 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6AJA-0000dD-A9 for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 16:33:16 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 8AE1826D27; Tue, 1 Mar 2005 17:33:15 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 3B04D26D21; Tue, 1 Mar 2005 17:33:14 +0100 (CET) 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 j21GXEet008956; Tue, 1 Mar 2005 17:33:14 +0100 Date: Tue, 1 Mar 2005 17:33:14 +0100 From: "Olaf M. Kolkman" To: Ben Laurie Cc: roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 Message-Id: <20050301173314.1c37ef66.olaf@ripe.net> In-Reply-To: <42247ACF.7060908@algroup.co.uk> References: <421D7625.8090201@algroup.co.uk> <4220F4F0.50602@algroup.co.uk> <42247ACF.7060908@algroup.co.uk> 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-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: U 0.272999 / -5.9 X-RIPE-Signature: e7ddea977783ffaab7adef861a0db4ba X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 01 Mar 2005 14:23:11 +0000 Ben Laurie wrote: > During introduction of a new hash type, return both > the old and new types. If size of response is an issue, I guess the > client would have to indicate which version on NSEC3 it supported. How can one be sure that one of those responses is not stripped from the answer? They are not covered by one signature since they have diffent ownernames. What is the the concequence of stripping? How do you distinguish between a situation where a validator only receives the newest of the two algoritms (the one that it knows about being stripped) and the situation that only a new algorithm NSEC3 is served? Although parts of the answer are popping up in this thread, I still fail to see the complete picture. (And I have not even tried to bend my mind around a situation where one of the two has a DS bit set and the other did not). On the client signaling which version of NSEC3 it supports; that may not be trivial since there might be all kind of forwarders/caches in between that need to deal with this. Im not saying its impossible but its not very appealing to go into that direction. -- Olaf ---------------------------------| 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 Mar 1 11:53:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16040 for ; Tue, 1 Mar 2005 11:53:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6AZx-00053Z-Cc for namedroppers-data@psg.com; Tue, 01 Mar 2005 16:50:37 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6AZw-000513-Bo for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 16:50:36 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 07BD013E3F for ; Tue, 1 Mar 2005 16:50:36 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-Reply-To: Message from Roy Arends of "Tue, 01 Mar 2005 16:29:50 +0100." X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 01 Mar 2005 16:50:36 +0000 Message-Id: <20050301165036.07BD013E3F@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --- nontechnical content first: in keeping with the peer-moderation philosophy that's sweeping some other forums at the moment, i just want to say... > You call this lenient ? Lenient to whom ? I call this plain stupid. ... > You're confused. You're mixing valuable with visible. ... > Ted, contact me off-list if you need help with your learning curve. ...that this is out of line, should never occur, and shouldn't be tolerated. moreover, ted is right when he says: >> However, more important than above details is, IMHO, that NSEC3 is >> making DNSSEC so much more complicated that it becomes difficult for >> even the people working on DNSSEC to comprehend what exactly are >> gaping security holes, or just risks, threats, or only minor >> inconveniences. and i take his point to be that experts are still arguing over terminology and fundamental assumptions, and the dnssec-bis data and security models now have so many subtle points that there is no way to validate it or prove it to the satisfaction of any multi-person team. the fact that roy... > NSEC3 is complex, just a little more then DNSSEC. Complicated is a > personal view. People who are working on DNSSEC and can't distinguish > between gaping security holes, or just risks, can contact me anytime. ...believes that he understands it all, does not constitute validation or provability. and i disagree that complexity is a personal issue. dnssec-bis is objectively complicated, not just subjectively complicated. but in any case, no instance of us insulting eachother has ever been constructive. --- technical content second: i've been struggling recently to integrate sam's and marka's remarks about the trivalued solution space for dnssec validation. for one thing, it bears heavily on the design of DLV. for another thing, i don't think about it the same way as they talk about it. by tri-valued i mean that a validator can come to three possible conclusions: 1. i can prove that this answer is secure 2. i can prove that this answer is unsecure 3. i cannot prove anything either way to my way of thinking, it's a bivalued solution space, having #1 and #3 above but no #2. the subtlety comes in at delegation points, where #2 is important. i call upon sam weiler, who has an excellent record for de-mystifying these topics for me, to write a short piece explaining what #2 is and why it matters. (the reason being, #3 is equivilent to a DoS, and #2 is not, and that's where ted and roy aren't meeting up.) -- 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 Mar 1 12:52:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21982 for ; Tue, 1 Mar 2005 12:52:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6BUS-000K7L-OH for namedroppers-data@psg.com; Tue, 01 Mar 2005 17:49:00 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6BUQ-000K6g-Jv for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 17:48:58 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id DBDBB33C33; Tue, 1 Mar 2005 17:48:56 +0000 (GMT) Message-ID: <4224AA92.9050101@algroup.co.uk> Date: Tue, 01 Mar 2005 17:46:59 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" Cc: roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <421D7625.8090201@algroup.co.uk> <4220F4F0.50602@algroup.co.uk> <42247ACF.7060908@algroup.co.uk> <20050301173314.1c37ef66.olaf@ripe.net> In-Reply-To: <20050301173314.1c37ef66.olaf@ripe.net> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: > On Tue, 01 Mar 2005 14:23:11 +0000 > Ben Laurie wrote: > > >>During introduction of a new hash type, return both >> the old and new types. If size of response is an issue, I guess the >> client would have to indicate which version on NSEC3 it supported. > > > > How can one be sure that one of those responses is not stripped from > the answer? They are not covered by one signature since they have > diffent ownernames. What is the the concequence of stripping? If the stripped answer is the only one the client understands, then the consequence is the same as preventing delivery of the answer at all. That is, I don't believe this introduces any kind of interesting vulnerability in that respect, since an attacker can always eat your responses anyway. > How do you distinguish between a situation where a validator only > receives the newest of the two algoritms (the one that it knows about > being stripped) and the situation that only a new algorithm NSEC3 is > served? Why would you want to? > Although parts of the answer are popping up in this thread, I still > fail to see the complete picture. (And I have not even tried to bend > my mind around a situation where one of the two has a DS bit set and > the other did not). > > On the client signaling which version of NSEC3 it supports; that may > not be trivial since there might be all kind of forwarders/caches in > between that need to deal with this. Im not saying its impossible but > its not very appealing to go into that direction. True enough. 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 Tue Mar 1 14:29:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01616 for ; Tue, 1 Mar 2005 14:29:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6Czy-000J15-Sq for namedroppers-data@psg.com; Tue, 01 Mar 2005 19:25:38 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6Czy-000J0k-2o for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 19:25:38 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j21JM2Jp016402 for ; Tue, 1 Mar 2005 14:22:02 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAzUaicG; Tue, 1 Mar 05 14:22:00 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j21JNg0F027039; Tue, 1 Mar 2005 14:23:42 -0500 (EST) Date: Tue, 1 Mar 2005 14:23:41 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Ben Laurie cc: Roy Arends , namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-Reply-To: <42247ACF.7060908@algroup.co.uk> Message-ID: References: <421D7625.8090201@algroup.co.uk> <4220F4F0.50602@algroup.co.uk> <42247ACF.7060908@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 1 Mar 2005, Ben Laurie wrote: > If size of response is an issue, I guess the > client would have to indicate which version on NSEC3 it supported. Don't go there. Think about caching. Think about the difficulties we've had with signalling up the resolver chain (the DO bit, for one). Don't go there. -- 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 Mar 1 14:31:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01966 for ; Tue, 1 Mar 2005 14:31:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6D4c-000Jax-JG for namedroppers-data@psg.com; Tue, 01 Mar 2005 19:30:26 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6D4a-000Jac-Jz for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 19:30:24 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j21JQnTX016639 for ; Tue, 1 Mar 2005 14:26:49 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0QaGEG; Tue, 1 Mar 05 14:26:46 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j21JSRr5027094; Tue, 1 Mar 2005 14:28:27 -0500 (EST) Date: Tue, 1 Mar 2005 14:28:27 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: "Olaf M. Kolkman" cc: ben@algroup.co.uk, namedroppers@ops.ietf.org, roy@dnss.ec Subject: Re: comments on nsec3-01 In-Reply-To: <20050301145237.2cc02d9d.olaf@ripe.net> Message-ID: References: <421D7625.8090201@algroup.co.uk> <20050301145237.2cc02d9d.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Samuel Weiler: > > This reminds me of a discussion from 1.5 years ago: > > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01539.html > > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01773.html > > I think the essential difference between the threat in that thread and > the threat in this thread is that one could do an attack by stripping > the RRSIGs with known algorithms and insert RRSIGs with unknown > algorithms, which would go unnoticed as the RRSIGs are not signed. > > An attacker cannot simply insert the '42-Hash" since the NSEC3 RR will > need to cary a valid signature. Absolutely correct -- sorry I didn't state that as clearly in my messages. This leads me to think that if we give zones a choice of what hashes to use that includes future expansion space, then it's important to signal what hash is in zone when the zone is entered. We could pick from algorithm signaling, DS hash signaling, a new DS record, or perhaps other ideas doucmented in -trans, but that signalling needs to happen at the zone cut. (The case of possibly including multiple NSEC3's is a different beast, as Olaf pointed out later in this thread.) -- 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 Mar 1 15:47:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09662 for ; Tue, 1 Mar 2005 15:47:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6EEN-0007Ga-3g for namedroppers-data@psg.com; Tue, 01 Mar 2005 20:44:35 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6EEM-0007GJ-0n for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 20:44:34 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 358882DE33; Tue, 1 Mar 2005 21:44:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 343A02DE31 for ; Tue, 1 Mar 2005 21:44:31 +0100 (CET) Date: Tue, 1 Mar 2005 21:44:30 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-Reply-To: <20050301165036.07BD013E3F@sa.vix.com> Message-ID: References: <20050301165036.07BD013E3F@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 1 Mar 2005, Paul Vixie wrote: > --- nontechnical content first: > > in keeping with the peer-moderation philosophy that's sweeping some other > forums at the moment, i just want to say... > > > You call this lenient ? Lenient to whom ? I call this plain stupid. So, what exactly is wrong with this statement. I truly feel that lenience towards security is not a smart thing. > > You're confused. You're mixing valuable with visible. Valuable and visible are two seperate things. He argued they were the same, I gave a counter example. > > Ted, contact me off-list if you need help with your learning curve. Yeah, borderline, but in the same level of "Does that reviel [sic] the unwritten lines in between? I doubt it..." Oh well. > moreover, ted is right when he says: > > >> However, more important than above details is, IMHO, that NSEC3 is > >> making DNSSEC so much more complicated that it becomes difficult for > >> even the people working on DNSSEC to comprehend what exactly are > >> gaping security holes, or just risks, threats, or only minor > >> inconveniences. > > and i take his point to be that experts are still arguing over terminology > and fundamental assumptions, and the dnssec-bis data and security models now > have so many subtle points that there is no way to validate it or prove it > to the satisfaction of any multi-person team. If there is something wrong with the terminology and/or fundamental assumptions in the DNSSEC-bis documentation, please say so, its not an RFC yet. > the fact that roy... > > > NSEC3 is complex, just a little more then DNSSEC. Complicated is a > > personal view. People who are working on DNSSEC and can't distinguish > > between gaping security holes, or just risks, can contact me anytime. > > ...believes that he understands it all, does not constitute validation or > provability. I hope I understand it all, but that was not the point. The point is that NSEC3 is not a different planet compared to DNSSEC. It is more complex, sure, but not an order of complexity greater as one might perceive. 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 Mar 1 16:28:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12465 for ; Tue, 1 Mar 2005 16:28:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6Et5-000EyI-Mw for namedroppers-data@psg.com; Tue, 01 Mar 2005 21:26:39 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6Et2-000Et7-N6 for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 21:26:36 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id CDE9F33C45; Tue, 1 Mar 2005 21:26:34 +0000 (GMT) Message-ID: <4224DD95.3050907@algroup.co.uk> Date: Tue, 01 Mar 2005 21:24:37 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samuel Weiler Cc: Roy Arends , namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <421D7625.8090201@algroup.co.uk> <4220F4F0.50602@algroup.co.uk> <42247ACF.7060908@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler wrote: > On Tue, 1 Mar 2005, Ben Laurie wrote: > > >>If size of response is an issue, I guess the >>client would have to indicate which version on NSEC3 it supported. > > > Don't go there. > > Think about caching. Think about the difficulties we've had with > signalling up the resolver chain (the DO bit, for one). > > Don't go there. I am more than happy not to go there :-) -- 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 Tue Mar 1 16:39:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13695 for ; Tue, 1 Mar 2005 16:39:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6F3f-000Gad-Q7 for namedroppers-data@psg.com; Tue, 01 Mar 2005 21:37:35 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6F3d-000GaO-Hv for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 21:37:33 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 7850267503 for ; Tue, 1 Mar 2005 21:37:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j21LZIYC025513; Wed, 2 Mar 2005 08:35:19 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200503012135.j21LZIYC025513@drugs.dv.isc.org> To: Donald Eastlake III Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: DNSEXT WG Last Call: TSIG/SHA document In-reply-to: Your message of "Tue, 01 Mar 2005 09:31:47 CDT." Date: Wed, 02 Mar 2005 08:35:18 +1100 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > > --0-910715544-1109686561=:23771 > Content-Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; FORMAT=flowed > Content-Transfer-Encoding: QUOTED-PRINTABLE > Content-ID: > > Needless to say, I support the document but enough requests have been=20 > posted for some more security guidance that I think I should revise it=20 > once more and post after the IETF meeting. Guidance as to the level of > implementation requirement for varous hash functions would be > appreciated or should they just be left as they are in the current > draft? The document had enough detail to implement non-truncated hash functions. > There is some mention in the document of weaknesses being found in hash=20 > algorithms recently. I suppose it should say a little more but I do not=20 > see any reason to expand substantially on that or try to make the draft=20 > into a treatise on the subject. > > From=20the draft: "increasingly > successful cryptanalytic attacks are being made on the shorter > hashes" > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd dee3@torque.pothole.com > 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) > Milford, MA 01757 USA Donald.Eastlake@motorola.com > > On Wed, 23 Feb 2005, [iso-8859-1] =D3lafur Gu=F0mundsson wrote: > > > Date: Wed, 23 Feb 2005 12:01:54 -0500 > > From: "[iso-8859-1] =D3lafur Gu=F0mundsson" > > To: Stephane Bortzmeyer > > Cc: namedroppers@ops.ietf.org > > Subject: Re: DNSEXT WG Last Call: TSIG/SHA document > >=20 > > At 11:23 23/02/2005, Stephane Bortzmeyer wrote: > >> On Wed, Feb 23, 2005 at 10:36:06AM -0500, > >> =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote > >> a message of 28 lines which said: > >>=20 > >> > The TSIG protocol provides transaction level authentication for DNS. > >> > TSIG is extensible through the definition of new algorithms. This > >> > document specifies an algorithm(s) from the SHA algorithm family. > >>=20 > >> The Security Considerations do not mention the very recent attacks on > >> SHA-1, which, IMHO (I am not a cryptographer) should stop this > >> document from going on the Standards Track (pending further studies). > >>=20 > >> http://www.schneier.com/blog/archives/2005/02/sha1_broken.html > > > > > > > > Excellent point, the document should address this issue before being > > advanced. > > > > I checked with some people that know cryptography before issuing this > > last call, they do not see an issue with THIS USE of SHA-1. > > > > > > > > According to cryptographers: > > The HMAC addition protects the underlying algorithm from the > > vulnerabilities found in SHA-1. > > http://jis.mit.edu/pipermail/saag/2005q1/001184.html > > > > IMHO more given the short time TSIG signatures are valid, and > > the great control each TSIG generator has over the input this > > is not a great risk. > > > > > > > > Having said that the WG can decide to list SHA-1 as Optional, > > not mandatory as in the current draft. > > Note also HMAC/SHA-256 is listed as mandatory to implement and that is > > the algorithm people should be using if they want to significantly > > improve security over HMAC/MD5 > > > > =D3lafur=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: > > > > > --0-910715544-1109686561=:23771-- > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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 Mar 1 17:02:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15424 for ; Tue, 1 Mar 2005 17:02:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6FOx-000KQ7-EB for namedroppers-data@psg.com; Tue, 01 Mar 2005 21:59:35 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6FOw-000KPo-JD for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 21:59:34 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j21LtxUg027796 for ; Tue, 1 Mar 2005 16:55:59 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAXVayr2; Tue, 1 Mar 05 16:55:56 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j21LvisH001422; Tue, 1 Mar 2005 16:57:44 -0500 (EST) Date: Tue, 1 Mar 2005 16:57:44 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Donald Eastlake III cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: TSIG/SHA document In-Reply-To: Message-ID: References: <6.2.0.14.2.20050223103137.04c94b20@localhost> <20050223162325.GA4687@nic.fr> <6.2.0.14.2.20050223113008.02ee7150@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 1 Mar 2005, Donald Eastlake III wrote: > > Guidance as to the level of implementation requirement for varous > hash functions would be appreciated or should they just be left as > they are in the current draft? I like the list as it stands. I'd support requiring (with a 2119 SHOULD) software that supports this spec to have a way of specifying which hash algorithms (and truncations) are (dis-)allowed. Thinking about this more, the point about prior agreement is winning me over -- I don't see a need to do hash/truncation negotiation on-line (specifically, no need to communicate a minumum acceptable bit length). > There is some mention in the document of weaknesses being found in hash > algorithms recently. I suppose it should say a little more but I do not > see any reason to expand substantially on that or try to make the draft > into a treatise on the subject. Concur. -- 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 Mar 1 17:03:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15500 for ; Tue, 1 Mar 2005 17:03:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6FRB-000KvM-Oh for namedroppers-data@psg.com; Tue, 01 Mar 2005 22:01:53 +0000 Received: from [144.189.100.103] (helo=motgate3.mot.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6FR8-000Kuu-P1 for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 22:01:50 +0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j21M9J3Z010156 for ; Tue, 1 Mar 2005 15:09:19 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j21M2pxM011040 for ; Tue, 1 Mar 2005 16:02:52 -0600 (CST) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id <1LP6N2XP>; Tue, 1 Mar 2005 17:01:48 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF238105CD4540@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: "'Mark Andrews'" Cc: namedroppers@ops.ietf.org Subject: RE: DNSEXT WG Last Call: TSIG/SHA document Date: Tue, 1 Mar 2005 17:01:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk By "level of implementation requirement" I meant optional/recommended/mandatory. The draft has three mandatory algorithms, HMACs MD5, SHA-1, and SHA-256 which is unusual for an IETF standard, but may be justified in this case. All others are optional. Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Mark Andrews Sent: Tuesday, March 01, 2005 4:35 PM To: Donald Eastlake III Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: TSIG/SHA document > Needless to say, I support the document but enough requests have been=20 > posted for some more security guidance that I think I should revise it=20 > once more and post after the IETF meeting. Guidance as to the level of > implementation requirement for varous hash functions would be > appreciated or should they just be left as they are in the current > draft? The document had enough detail to implement non-truncated hash functions. > There is some mention in the document of weaknesses being found in hash=20 > algorithms recently. I suppose it should say a little more but I do not=20 > see any reason to expand substantially on that or try to make the draft=20 > into a treatise on the subject. > > From the draft: "increasingly > successful cryptanalytic attacks are being made on the shorter > hashes" Also from the draft: "Significant progress has been made recently in cryptanalysis of hash function of the type used herein. While the results so far should not effect HMAC, the stronger SHA-1 and SHA-256 algorithms are being made mandatory due to caution." > Thanks, > Donald -- 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 Mar 1 17:23:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16856 for ; Tue, 1 Mar 2005 17:23:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6Fjn-000OwI-6v for namedroppers-data@psg.com; Tue, 01 Mar 2005 22:21:07 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6Fjm-000Ow3-GY for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 22:21:06 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2F57E13E3F for ; Tue, 1 Mar 2005 22:21:06 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-Reply-To: Message from Roy Arends of "Tue, 01 Mar 2005 21:44:30 +0100." X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 01 Mar 2005 22:21:06 +0000 Message-Id: <20050301222106.2F57E13E3F@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > --- nontechnical content first: > ... > Yeah, borderline, but in the same level of "Does that reviel [sic] the > unwritten lines in between? I doubt it..." > > Oh well. that's a lot of he-said she-said, which i'm not interested in. you're welcome to feel that i've singled you out or chosen an example at random; the fact will remain that we have to uplevel our behaviour if we want to make progress (or for other reasons not directly relevant to the charter.) > > ... i take [ted's] point to be that experts are still arguing over > > terminology and fundamental assumptions, and the dnssec-bis data and > > security models now have so many subtle points that there is no way > > to validate it or prove it to the satisfaction of any multi-person > > team. > > If there is something wrong with the terminology and/or fundamental > assumptions in the DNSSEC-bis documentation, please say so, its not an > RFC yet. i didn't say it was wrong, i said it was complicated. complicated enough that reasonable experts are still disagreeing over the meaning of it all. and my point is not that the rfc's need to be changed but that we all need to show a little compassion when we encounter terminological or conceptual chasms. > I hope I understand it all, but that was not the point. The point is > that NSEC3 is not a different planet compared to DNSSEC. It is more > complex, sure, but not an order of complexity greater as one might > perceive. then you are too close to it and may lack perspective. dnssec-bis is extremely complex on its own, and while NSEC3 might not be a large change, it is at best a moderate change to something that's already very complex. i'd caution you to remember that your familiarity with NSEC3 was not gained overnight nor have you ever tried to consider NSEC3 without already being an expert on dnssec-bis. this stuff is complicated. show some compassion. -- 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 Mar 1 17:26:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17160 for ; Tue, 1 Mar 2005 17:26:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6Fnp-000Pjq-BS for namedroppers-data@psg.com; Tue, 01 Mar 2005 22:25:17 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6Fnn-000PjO-9I for namedroppers@ops.ietf.org; Tue, 01 Mar 2005 22:25:15 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 9E2E3677F2 for ; Tue, 1 Mar 2005 22:25:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j21MP8mK049114; Wed, 2 Mar 2005 09:25:08 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200503012225.j21MP8mK049114@drugs.dv.isc.org> To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: DNSEXT WG Last Call: TSIG/SHA document In-reply-to: Your message of "Tue, 01 Mar 2005 17:01:47 CDT." <62173B970AE0A044AED8723C3BCF238105CD4540@ma19exm01.e6.bcs.mot.com> Date: Wed, 02 Mar 2005 09:25:08 +1100 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > By "level of implementation requirement" I meant > optional/recommended/mandatory. > > The draft has three mandatory algorithms, HMACs MD5, SHA-1, and > SHA-256 which is unusual for an IETF standard, but may be > justified in this case. All others are optional. > > Donald I'm fine w/ the existing levels. I suspect most will just implement them all as it is not much extra work once you implement one. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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 Mar 2 04:25:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16681 for ; Wed, 2 Mar 2005 04:25:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6Q1w-000C5X-HO for namedroppers-data@psg.com; Wed, 02 Mar 2005 09:20:32 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6Q1s-000C5D-Da for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 09:20:28 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id BF35225325; Wed, 2 Mar 2005 10:20:27 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id DD89124E4F for ; Wed, 2 Mar 2005 10:20:24 +0100 (CET) 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 j229KOet020389 for ; Wed, 2 Mar 2005 10:20:24 +0100 Date: Wed, 2 Mar 2005 10:20:24 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Fw: Impending publication: draft-iab-dns-assumptions-02.txt Message-Id: <20050302102024.7074ed49.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-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.112498 / -5.9 X-RIPE-Signature: 6de227c47980716b08d8f92d6b3ba5f2 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit FYI Note the addresses to which comments are to be send (ietf@ietf.org and/or iab@iab.org). --Olaf ---------------------- Begin forwarded message ---------------------- Date: Tue, 01 Mar 2005 17:46:27 -0500 From: Leslie Daigle To: IETF Announcement list Cc: iab@ietf.org Subject: Impending publication: draft-iab-dns-assumptions-02.txt The IAB is ready to ask the RFC-Editor to publish What's in a Name: False Assumptions about DNS Names draft-iab-dns-assumptions-02 as an Informational RFC. This document reviews the potential assumptions that may be made based on domain names, as well as the potential implications (and pitfalls) of those assumptions. The IAB solicits comments by March 29, 2005. Please send comments to the IAB (iab@iab.org), or to ietf@ietf.org. The document can be found at http://www.ietf.org/internet-drafts/draft-iab-dns-assumptions-02.txt >From the Abstract: The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, URIs, and other application layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. A danger of this trend is that the humans and automata which consume and use these identifiers will make assumptions about the services that are or should be provided by the hosts associated with these identifiers. This document discusses this problem in more detail and makes recommendations on how it can be avoided. Leslie Daigle, For the IAB. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ---------------------- End forwarded message ------------------------ -- ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org -- 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 Mar 2 05:46:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25340 for ; Wed, 2 Mar 2005 05:46:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6RKZ-0000wj-Um for namedroppers-data@psg.com; Wed, 02 Mar 2005 10:43:51 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6RKY-0000wP-QG for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 10:43:51 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 3748427142; Wed, 2 Mar 2005 11:43:50 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5443A2713E for ; Wed, 2 Mar 2005 11:43:49 +0100 (CET) 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 j22Ahnet021306 for ; Wed, 2 Mar 2005 11:43:49 +0100 Date: Wed, 2 Mar 2005 11:43:49 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 Message-Id: <20050302114349.0c8e9ffd.olaf@ripe.net> In-Reply-To: <4224AA92.9050101@algroup.co.uk> References: <421D7625.8090201@algroup.co.uk> <4220F4F0.50602@algroup.co.uk> <42247ACF.7060908@algroup.co.uk> <20050301173314.1c37ef66.olaf@ripe.net> <4224AA92.9050101@algroup.co.uk> 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-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: U 0.305642 / -5.9 X-RIPE-Signature: 013ec5b79fca398cdd7b8a81d42656a1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > > How can one be sure that one of those responses is not stripped from > > the answer? They are not covered by one signature since they have > > diffent ownernames. What is the the concequence of stripping? > > If the stripped answer is the only one the client understands, then the > consequence is the same as preventing delivery of the answer at all. > That is, I don't believe this introduces any kind of interesting > vulnerability in that respect, since an attacker can always eat your > responses anyway. Iff stripping has prevention of delivery as only concequence I am with you. That would be a vulnarability one can live with. > > > How do you distinguish between a situation where a validator only > > receives the newest of the two algoritms (the one that it knows about > > being stripped) and the situation that only a new algorithm NSEC3 is > > served? > > Why would you want to? > That question was related to the first question. If there are concequences, other than prevention of delivery (DOS) how would you understand that you are under attack or that you are served with genuine data? One of the many questions I have is what should be the default behavior in case you do not understand the new hash algorithm. Should you treat the answer as non secure? I am also affraid there might be interference between algorithm roll and the opt-in part of the proposal. What should a validator do if it receives an answer with an unknown hash algorithm and the "A" flag set? The validator can not tell that the delegation NS RR that has been returned is actually part of the opt-in span and is therefore supposed to be non-secured. In other words if one spoofs an NSEC3 RR with an unknown hashing algorithm and a valid RRSIG (which was obtained from a random query) into the query stream one can make a zone that was previously secure unsecured and then spoof answers from that zone. (I am affraid I'm a little to dense here). As an alternative approach. Lets try to enumerate the possible answers a resolver may expect and see what the possible choices are. In all cases we asume that the NSEC3 spans the "hashed qname" for which an NXDOMAIN is returned and that the NSEC3 RR is validated with an RRSIG. For means of notation. NSEC3(a,0) means an NSEC3 record with hash algorithm an that the "A" flag is clear. NSEC3(z,1) means the NSEC3 rr uses hash algorithm 'z' and the "A" flag is set (hence its "OPT-IN"). Algorithms a,b are understood by the validators and algorithm z,y are not. What does the resolver do if the following is returned and what are the vulnarabilities in these cases. situation Returned 1 NSEC3(a,0) 2 NSEC3(a,1) 3 NSEC3(a,0),NSEC3(b,1) Two different owner names both span the QNAME one is with opt-in one without. 4 NSEC3(a,0),NSEC3(z,0) 5 NSEC3(a,1),NSEC3(z,0) 6 NSEC3(a,0),NSEC3(z,1) 7 NSEC3(a,1),NSEC3(z,1) 8 NSEC3(a,1),NSEC3(a,0) These have the same owner name should this be outlawed? 9 NSEC3(z,0) 10 NSEC3(z,1) I think that we have to go over these corner cases and spell out if there are vulnarabilities. I think that we can safely assume that NSEC3(z) records can not be injected since they will need to be signed. That is a somewhat different situation from what we had with the key degradation attack. --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 Wed Mar 2 10:16:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20539 for ; Wed, 2 Mar 2005 10:15:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6VUs-0000tt-19 for namedroppers-data@psg.com; Wed, 02 Mar 2005 15:10:46 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6VUR-0000pJ-JL for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 15:10:20 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 6A87933C45; Wed, 2 Mar 2005 15:10:17 +0000 (GMT) Message-ID: <4225D6E4.1020400@algroup.co.uk> Date: Wed, 02 Mar 2005 15:08:20 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <421D7625.8090201@algroup.co.uk> <4220F4F0.50602@algroup.co.uk> <42247ACF.7060908@algroup.co.uk> <20050301173314.1c37ef66.olaf@ripe.net> <4224AA92.9050101@algroup.co.uk> <20050302114349.0c8e9ffd.olaf@ripe.net> In-Reply-To: <20050302114349.0c8e9ffd.olaf@ripe.net> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: >>>How do you distinguish between a situation where a validator only >>>receives the newest of the two algoritms (the one that it knows about >>>being stripped) and the situation that only a new algorithm NSEC3 is >>>served? >> >>Why would you want to? >> > > > That question was related to the first question. If there are > concequences, other than prevention of delivery (DOS) how would you > understand that you are under attack or that you are served with > genuine data? > > > One of the many questions I have is what should be the default > behavior in case you do not understand the new hash algorithm. Should > you treat the answer as non secure? The answer is non secure, so it would be slightly insane to treat it any other way. However, I do not believe it is well-defined what we mean when we say "treat the answer as non-secure". This seems to me to be tied in with the questions related to resolvers, APIs and user interaction that have been consistently punted every time I've seen them discussed. Having a clear idea of what is meant by this seems to me to be vital to understanding the threats, if any. > I am also affraid there might be interference between algorithm roll > and the opt-in part of the proposal. What should a validator do if it > receives an answer with an unknown hash algorithm and the "A" flag > set? The validator can not tell that the delegation NS RR that has > been returned is actually part of the opt-in span and is therefore > supposed to be non-secured. In other words if one spoofs an NSEC3 RR > with an unknown hashing algorithm and a valid RRSIG (which was > obtained from a random query) into the query stream one can make a > zone that was previously secure unsecured and then spoof answers from > that zone. (I am affraid I'm a little to dense here). Again, I don't see how this is different from preventing the delivery of NSEC3 RRs at all. > As an alternative approach. Lets try to enumerate the possible answers > a resolver may expect and see what the possible choices are. > > In all cases we asume that the NSEC3 spans the "hashed qname" for > which an NXDOMAIN is returned and that the NSEC3 RR is validated with > an RRSIG. > > For means of notation. NSEC3(a,0) means an NSEC3 record with hash > algorithm an that the "A" flag is clear. NSEC3(z,1) means the NSEC3 rr > uses hash algorithm 'z' and the "A" flag is set (hence its "OPT-IN"). > > Algorithms a,b are understood by the validators and algorithm z,y are > not. > > What does the resolver do if the following is returned and what are the > vulnarabilities in these cases. > > situation Returned > 1 NSEC3(a,0) > 2 NSEC3(a,1) > 3 NSEC3(a,0),NSEC3(b,1) Two different owner names both span > the QNAME one is with opt-in one > without. > > 4 NSEC3(a,0),NSEC3(z,0) > 5 NSEC3(a,1),NSEC3(z,0) > 6 NSEC3(a,0),NSEC3(z,1) > 7 NSEC3(a,1),NSEC3(z,1) > > 8 NSEC3(a,1),NSEC3(a,0) These have the same owner name > should this be outlawed? > > > 9 NSEC3(z,0) > > 10 NSEC3(z,1) > > > > > I think that we have to go over these corner cases and spell out if > there are vulnarabilities. I think that we can safely assume that > NSEC3(z) records can not be injected since they will need to be > signed. That is a somewhat different situation from what we had with > the key degradation attack. I guess sitting down for an hour or two in minneapolis and going over these would be useful. Just to be clear, there appear to be two different issues which are being addressed here: a) Hash function rollover b) Inconsistent opt-in responses (which are presumably only of interest if a zone is switching to or from opt-in - otherwise the zone is just plain broken). but, until we have a clear idea of what action we might take depending on our assessment of the security of the zone, it is difficult to be clear what, if any, vulnerabilities arise from the above situations. In particular, the state where we can can't get an answer to a query seems to me to be not interestingly different from the state where we get an answer we don't understand (whether through intervention or simply because we're out of sync, version-wise), but perhaps someone has a threat model where these are different - do they? 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 Wed Mar 2 10:36:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23576 for ; Wed, 2 Mar 2005 10:36:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6VrK-0005Oz-GT for namedroppers-data@psg.com; Wed, 02 Mar 2005 15:33:58 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6VrJ-0005Oa-0I for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 15:33:57 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j22FXrLb017862 for ; Wed, 2 Mar 2005 16:33:53 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.13.3/8.13.1/Submit) id j22FXrw9017861; Wed, 2 Mar 2005 16:33:53 +0100 (CET) (envelope-from ted) Message-Id: <200503021533.j22FXrw9017861@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 2 Mar 2005 16:33:53 +0100 In-Reply-To: "Ben Laurie's message as of Mar 2, 16:18" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 Cc: namedroppers@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Ben Laurie, on Mar 2, 16:18, in "Re: comments on nsec ..."] > > One of the many questions I have is what should be the default > > behavior in case you do not understand the new hash algorithm. Should > > you treat the answer as non secure? > > The answer is non secure, so it would be slightly insane to treat it any > other way. Shouldn't you be treating it as bogus? (Because it was meant to be secured, but you can't verify 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 Wed Mar 2 11:22:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28632 for ; Wed, 2 Mar 2005 11:22:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6WZe-000El2-6w for namedroppers-data@psg.com; Wed, 02 Mar 2005 16:19:46 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6WZb-000EgW-Qu for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 16:19:43 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id DECA4C2DA8; Wed, 2 Mar 2005 16:19:42 +0000 (GMT) Date: Wed, 02 Mar 2005 16:19:43 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie , "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: comments on nsec3-01 Message-ID: <2A1E3B9A8F22C3D3C25D57B4@[192.168.100.25]> In-Reply-To: <4225D6E4.1020400@algroup.co.uk> References: <421D7625.8090201@algroup.co.uk> <4220F4F0.50602@algroup.co.uk> <42247ACF.7060908@algroup.co.uk> <20050301173314.1c37ef66.olaf@ripe.net> <4224AA92.9050101@algroup.co.uk> <20050302114349.0c8e9ffd.olaf@ripe.net> <4225D6E4.1020400@algroup.co.uk> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 02 March 2005 15:08 +0000 Ben Laurie wrote: > However, I do not believe it is well-defined what we mean when we say > "treat the answer as non-secure". This seems to me to be tied in with the > questions related to resolvers, APIs and user interaction that have been > consistently punted every time I've seen them discussed. Having a clear > idea of what is meant by this seems to me to be vital to understanding > the threats, if any. Call me naive or avoiding the question, but isn't the answer here that the API / application treats it exactly how it would have treated it if the zone were unsigned. So some apps might chose to proceed, some might display a warning, some might not highlight the browser bar in yellow and proceed anyway. IE I don't understand why at APPLICATION level this adds any more of a third state than is already necessary to provide backward compatibility with vanilla DNS. If applications do not want to provide such backward compatibility, they necessary reject unsigned replies, whether that's an opt-in "I can't tell give you a signed denial of existence" or a vanilla DNS NXDOMAIN. If they want to treat unsigned replies as if they were signed, fine. If they want to treat them "a third way", also fine. 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 Wed Mar 2 11:23:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28745 for ; Wed, 2 Mar 2005 11:23:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6Wb1-000EzD-2j for namedroppers-data@psg.com; Wed, 02 Mar 2005 16:21:11 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6Way-000Eyt-6S for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 16:21:08 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 9B14BC2DA8; Wed, 2 Mar 2005 16:21:07 +0000 (GMT) Date: Wed, 02 Mar 2005 16:21:07 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Ted Lindgreen , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: comments on nsec3-01 Message-ID: In-Reply-To: <200503021533.j22FXrw9017861@open.nlnetlabs.nl> References: <200503021533.j22FXrw9017861@open.nlnetlabs.nl> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 02 March 2005 16:33 +0100 Ted Lindgreen wrote: >> > One of the many questions I have is what should be the default >> > behavior in case you do not understand the new hash algorithm. Should >> > you treat the answer as non secure? >> >> The answer is non secure, so it would be slightly insane to treat it any >> other way. > > Shouldn't you be treating it as bogus? (Because it was meant to > be secured, but you can't verify it). It's no more bogus than an unsigned reply. It might be bogus, or it might be a hash function you don't implement and be perfectly OK. 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 Wed Mar 2 11:53:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01322 for ; Wed, 2 Mar 2005 11:53:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6X3i-000Kiq-T7 for namedroppers-data@psg.com; Wed, 02 Mar 2005 16:50:50 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6X3h-000Kho-TB for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 16:50:50 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 16BB02DF63; Wed, 2 Mar 2005 17:50:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 155322DF62; Wed, 2 Mar 2005 17:50:48 +0100 (CET) Date: Wed, 2 Mar 2005 17:50:47 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Ted Lindgreen Cc: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-Reply-To: <200503021533.j22FXrw9017861@open.nlnetlabs.nl> Message-ID: References: <200503021533.j22FXrw9017861@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 2 Mar 2005, Ted Lindgreen wrote: > [Quoting Ben Laurie, on Mar 2, 16:18, in "Re: comments on nsec ..."] > > > > One of the many questions I have is what should be the default > > > behavior in case you do not understand the new hash algorithm. Should > > > you treat the answer as non secure? > > > > The answer is non secure, so it would be slightly insane to treat it any > > other way. > > Shouldn't you be treating it as bogus? (Because it was meant to > be secured, but you can't verify it). I'm with Ted on this one. This is a degradation attack. If the stripping of an NSEC3 record from the response can go undetected, and meanwhile treating the other NSEC3 (with unknown hash) response as unsigned, an attacker can degrade security. 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 Mar 2 12:14:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04330 for ; Wed, 2 Mar 2005 12:14:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6XNs-000OgE-DI for namedroppers-data@psg.com; Wed, 02 Mar 2005 17:11:40 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6XNq-000Ofm-0U for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 17:11:38 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 6071C33C33; Wed, 2 Mar 2005 17:11:36 +0000 (GMT) Message-ID: <4225F3D9.2060307@algroup.co.uk> Date: Wed, 02 Mar 2005 17:11:53 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <421D7625.8090201@algroup.co.uk> <4220F4F0.50602@algroup.co.uk> <42247ACF.7060908@algroup.co.uk> <20050301173314.1c37ef66.olaf@ripe.net> <4224AA92.9050101@algroup.co.uk> <20050302114349.0c8e9ffd.olaf@ripe.net> <4225D6E4.1020400@algroup.co.uk> <2A1E3B9A8F22C3D3C25D57B4@[192.168.100.25]> In-Reply-To: <2A1E3B9A8F22C3D3C25D57B4@[192.168.100.25]> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > > > --On 02 March 2005 15:08 +0000 Ben Laurie wrote: > >> However, I do not believe it is well-defined what we mean when we say >> "treat the answer as non-secure". This seems to me to be tied in with the >> questions related to resolvers, APIs and user interaction that have been >> consistently punted every time I've seen them discussed. Having a clear >> idea of what is meant by this seems to me to be vital to understanding >> the threats, if any. > > > Call me naive or avoiding the question, but isn't the answer here > that the API / application treats it exactly how it would have treated > it if the zone were unsigned. > > So some apps might chose to proceed, some might display a warning, some > might not highlight the browser bar in yellow and proceed anyway. > > IE I don't understand why at APPLICATION level this adds any more of > a third state than is already necessary to provide backward compatibility > with vanilla DNS. If applications do not want to provide such backward > compatibility, they necessary reject unsigned replies, whether that's > an opt-in "I can't tell give you a signed denial of existence" or > a vanilla DNS NXDOMAIN. If they want to treat unsigned replies as > if they were signed, fine. If they want to treat them "a third way", > also fine. That's certainly a plausible argument for how APIs might work :-) If everyone can agree that that's how it should work, then we have a basis for proceeding. 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 Wed Mar 2 12:27:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06813 for ; Wed, 2 Mar 2005 12:27:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6Xb5-0000wK-TY for namedroppers-data@psg.com; Wed, 02 Mar 2005 17:25:19 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6Xb5-0000w4-2h for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 17:25:19 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8B43A33C6B; Wed, 2 Mar 2005 17:25:17 +0000 (GMT) Message-ID: <4225F710.9010900@algroup.co.uk> Date: Wed, 02 Mar 2005 17:25:36 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Lindgreen Cc: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <200503021533.j22FXrw9017861@open.nlnetlabs.nl> In-Reply-To: <200503021533.j22FXrw9017861@open.nlnetlabs.nl> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ted Lindgreen wrote: > [Quoting Ben Laurie, on Mar 2, 16:18, in "Re: comments on nsec ..."] > > >>>One of the many questions I have is what should be the default >>>behavior in case you do not understand the new hash algorithm. Should >>>you treat the answer as non secure? >> >>The answer is non secure, so it would be slightly insane to treat it any >>other way. > > > Shouldn't you be treating it as bogus? (Because it was meant to > be secured, but you can't verify it). But it isn't bogus, your validator is :-) -- 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 Wed Mar 2 12:28:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06921 for ; Wed, 2 Mar 2005 12:28:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6Xcn-0001E5-99 for namedroppers-data@psg.com; Wed, 02 Mar 2005 17:27:05 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6Xck-0001DL-Ak for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 17:27:02 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id B839533C33; Wed, 2 Mar 2005 17:26:57 +0000 (GMT) Message-ID: <4225F774.8000804@algroup.co.uk> Date: Wed, 02 Mar 2005 17:27:16 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Arends Cc: Ted Lindgreen , namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <200503021533.j22FXrw9017861@open.nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > On Wed, 2 Mar 2005, Ted Lindgreen wrote: > > >>[Quoting Ben Laurie, on Mar 2, 16:18, in "Re: comments on nsec ..."] >> >> >>>>One of the many questions I have is what should be the default >>>>behavior in case you do not understand the new hash algorithm. Should >>>>you treat the answer as non secure? >>> >>>The answer is non secure, so it would be slightly insane to treat it any >>>other way. >> >>Shouldn't you be treating it as bogus? (Because it was meant to >>be secured, but you can't verify it). > > > I'm with Ted on this one. This is a degradation attack. > > If the stripping of an NSEC3 record from the response can go undetected, > and meanwhile treating the other NSEC3 (with unknown hash) response as > unsigned, an attacker can degrade security. An attacker can "degrade security" in the same way by blocking the (understood) NSEC3 response and providing an unsigned response. This does not seem to me to be either interesting or preventable. 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 Wed Mar 2 13:29:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11762 for ; Wed, 2 Mar 2005 13:29:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6YYZ-000B9H-Su for namedroppers-data@psg.com; Wed, 02 Mar 2005 18:26:47 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6YYQ-000B21-TY for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 18:26:38 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7129113E3F for ; Wed, 2 Mar 2005 18:26:38 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-Reply-To: Message from Ben Laurie of "Wed, 02 Mar 2005 17:27:16 GMT." <4225F774.8000804@algroup.co.uk> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 02 Mar 2005 18:26:38 +0000 Message-Id: <20050302182638.7129113E3F@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > Shouldn't you be treating it as bogus? (Because it was meant to be > > > secured, but you can't verify it). > > > I'm with Ted on this one. This is a degradation attack. If the > > stripping of an NSEC3 record from the response can go undetected, > > and meanwhile treating the other NSEC3 (with unknown hash) response > > as unsigned, an attacker can degrade security. > > An attacker can "degrade security" in the same way by blocking the > (understood) NSEC3 response and providing an unsigned response. This > does not seem to me to be either interesting or preventable. this goes to expectation. in dnssec-bis, if you learned a DS RR from the parent or if your validator's SEP indicates "must be secure" for some domain, then if you don't get security metadata from the subzone, you have to assume that you're being MIM'd. in this case you'll drop the data and the application on the other side of your API will never see it. it'll be the same, from the application's point of view, as SERVFAIL. same thing happens if the data is signed with the wrong key or if the signature doesn't match. this is the "provably not secure" member of the trivalued validator result space. if NSEC3 alters this then i'm concerned and would like to hear more. -- 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 Mar 2 13:30:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11830 for ; Wed, 2 Mar 2005 13:30:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6Yb3-000Bkt-Qf for namedroppers-data@psg.com; Wed, 02 Mar 2005 18:29:21 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6Yb2-000BkZ-ML for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 18:29:21 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j22ITHSn024455 for ; Wed, 2 Mar 2005 19:29:17 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.13.3/8.13.1/Submit) id j22ITHWK024454 for namedroppers@ops.ietf.org; Wed, 2 Mar 2005 19:29:17 +0100 (CET) (envelope-from ted) Message-Id: <200503021829.j22ITHWK024454@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 2 Mar 2005 19:29:17 +0100 In-Reply-To: "Ben Laurie's message as of Mar 2, 18:25" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Ben Laurie, on Mar 2, 18:25, in "Re: comments on nsec ..."] > Ted Lindgreen wrote: > > [Quoting Ben Laurie, on Mar 2, 16:18, in "Re: comments on nsec ..."] > > > > > >>>One of the many questions I have is what should be the default > >>>behavior in case you do not understand the new hash algorithm. Should > >>>you treat the answer as non secure? > >> > >>The answer is non secure, so it would be slightly insane to treat it any > >>other way. > > > > > > Shouldn't you be treating it as bogus? (Because it was meant to > > be secured, but you can't verify it). > > But it isn't bogus, your validator is :-) No, the protocol (or this particular extention of it) is, I'm affraid. -- 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 Wed Mar 2 14:08:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15101 for ; Wed, 2 Mar 2005 14:08:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6ZBK-000JVG-6y for namedroppers-data@psg.com; Wed, 02 Mar 2005 19:06:50 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6ZBH-000JUj-Sv for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 19:06:48 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8B99C33C5F; Wed, 2 Mar 2005 19:06:45 +0000 (GMT) Message-ID: <42260EE7.9030804@algroup.co.uk> Date: Wed, 02 Mar 2005 19:07:19 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <20050302182638.7129113E3F@sa.vix.com> In-Reply-To: <20050302182638.7129113E3F@sa.vix.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>>Shouldn't you be treating it as bogus? (Because it was meant to be >>>>secured, but you can't verify it). >> >>>I'm with Ted on this one. This is a degradation attack. If the >>>stripping of an NSEC3 record from the response can go undetected, >>>and meanwhile treating the other NSEC3 (with unknown hash) response >>>as unsigned, an attacker can degrade security. >> >>An attacker can "degrade security" in the same way by blocking the >>(understood) NSEC3 response and providing an unsigned response. This >>does not seem to me to be either interesting or preventable. > > > this goes to expectation. in dnssec-bis, if you learned a DS RR from > the parent or if your validator's SEP indicates "must be secure" for > some domain, then if you don't get security metadata from the subzone, > you have to assume that you're being MIM'd. in this case you'll drop > the data and the application on the other side of your API will never > see it. it'll be the same, from the application's point of view, as > SERVFAIL. same thing happens if the data is signed with the wrong key > or if the signature doesn't match. this is the "provably not secure" > member of the trivalued validator result space. > > if NSEC3 alters this then i'm concerned and would like to hear more. I do not believe NSEC3 alters it, that was my point. If the validator treats hashes it can't handle in the same way as unsigned data or data signed with the wrong key, etc, then, it seems to me, you are in the "provably not secure" space. Note that if the validator is up-to-date, then this is not an issue anyway, so people who _really_ care about security should never be exposed to this problem. 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 Wed Mar 2 14:18:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16150 for ; Wed, 2 Mar 2005 14:18:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6ZJy-000LD0-Ls for namedroppers-data@psg.com; Wed, 02 Mar 2005 19:15:46 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6ZJx-000LCm-Tb for namedroppers@ops.ietf.org; Wed, 02 Mar 2005 19:15:45 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 94F8A13E3F for ; Wed, 2 Mar 2005 19:15:45 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-Reply-To: Message from Ben Laurie of "Wed, 02 Mar 2005 19:07:19 GMT." <42260EE7.9030804@algroup.co.uk> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 02 Mar 2005 19:15:45 +0000 Message-Id: <20050302191545.94F8A13E3F@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > if NSEC3 alters this then i'm concerned and would like to hear more. > > I do not believe NSEC3 alters it, that was my point. If the validator > treats hashes it can't handle in the same way as unsigned data or data > signed with the wrong key, etc, then, it seems to me, you are in the > "provably not secure" space. ok, so what if someone signs a zone with NSEC3 but not NSEC? that'll mean old validators can prove existence but not nonexistence. how would a validator signal nonexistence to its application? it would have to signal SERVFAIL rather than NXDOMAIN. is that ok? (it's important to know this, because the same thing happens if we change the NSEC3 hash later on, so it's not a once-only transition cost.) > Note that if the validator is up-to-date, then this is not an issue > anyway, so people who _really_ care about security should never be > exposed to this problem. agreed, but what i'm trying to understand is whether we're reducing the security for the part of the community who doesn't subscribe to the dnssec-of-the-month club. if so, and if it's inevitable that we do this and not merely a failing in the current draft, then we have to disclose it to the communities who might fund the work or use it when complete. -- 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 Mar 3 04:06:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24027 for ; Thu, 3 Mar 2005 04:06:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6mCd-000Ew3-Uy for namedroppers-data@psg.com; Thu, 03 Mar 2005 09:01:03 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6mCa-000EvI-Qd for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 09:01:01 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 045EA33C45; Thu, 3 Mar 2005 09:00:59 +0000 (GMT) Message-ID: <4226D2C5.7000102@algroup.co.uk> Date: Thu, 03 Mar 2005 09:03:01 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <20050302191545.94F8A13E3F@sa.vix.com> In-Reply-To: <20050302191545.94F8A13E3F@sa.vix.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>if NSEC3 alters this then i'm concerned and would like to hear more. >> >>I do not believe NSEC3 alters it, that was my point. If the validator >>treats hashes it can't handle in the same way as unsigned data or data >>signed with the wrong key, etc, then, it seems to me, you are in the >>"provably not secure" space. > > > ok, so what if someone signs a zone with NSEC3 but not NSEC? that'll > mean old validators can prove existence but not nonexistence. how would > a validator signal nonexistence to its application? it would have to > signal SERVFAIL rather than NXDOMAIN. is that ok? (it's important to > know this, because the same thing happens if we change the NSEC3 hash > later on, so it's not a once-only transition cost.) It sounds OK to me, though I can see why one might want a slightly richer user experience, if only so the user has a better idea what they might do about the failure (signature mismatch might be caused by out-of-date keys, for example). >>Note that if the validator is up-to-date, then this is not an issue >>anyway, so people who _really_ care about security should never be >>exposed to this problem. > > > agreed, but what i'm trying to understand is whether we're reducing the > security for the part of the community who doesn't subscribe to the > dnssec-of-the-month club. if so, and if it's inevitable that we do this > and not merely a failing in the current draft, then we have to disclose > it to the communities who might fund the work or use it when complete. Given that the alternative (in the case of NSEC3) is no security at all, I can't see how we can be reducing security by deploying it. 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 Mar 3 04:41:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29576 for ; Thu, 3 Mar 2005 04:41:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6mn7-000KFQ-6n for namedroppers-data@psg.com; Thu, 03 Mar 2005 09:38:45 +0000 Received: from [213.154.224.50] (helo=bartok.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6mn5-000KF6-Tw for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 09:38:44 +0000 Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j239cfSA013874 for ; Thu, 3 Mar 2005 10:38:41 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200503030938.j239cfSA013874@bartok.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-reply-to: Your message of Thu, 03 Mar 2005 09:03:01 +0000. <4226D2C5.7000102@algroup.co.uk> Date: Thu, 03 Mar 2005 10:38:41 +0100 From: Jaap Akkerhuis X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ok, so what if someone signs a zone with NSEC3 but not NSEC? that'll > mean old validators can prove existence but not nonexistence. how would > a validator signal nonexistence to its application? it would have to > signal SERVFAIL rather than NXDOMAIN. is that ok? (it's important to > know this, because the same thing happens if we change the NSEC3 hash > later on, so it's not a once-only transition cost.) It sounds OK to me, though I can see why one might want a slightly richer user experience, if only so the user has a better idea what they might do about the failure ... So pushing even more complications towards the resolver. I'm loosing track of all the corner cases which will be introduced by NSEC2, NSEC3 and friends, although I see one common theme in these solutions: methods to guard the server or the information it produces, seem to put all of the burden towards the resolver. Proper resolving for dnssec-bis is already difficult enough. jaap -- 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 Mar 3 05:10:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01874 for ; Thu, 3 Mar 2005 05:10:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6nFC-000PLl-Nq for namedroppers-data@psg.com; Thu, 03 Mar 2005 10:07:46 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6nF9-000PL9-JQ for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 10:07:43 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 75A1AC2DA7; Thu, 3 Mar 2005 10:07:42 +0000 (GMT) Date: Thu, 03 Mar 2005 10:07:34 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Jaap Akkerhuis , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: comments on nsec3-01 Message-ID: <443F27E9CE891D3D18311DCD@[192.168.100.25]> In-Reply-To: <200503030938.j239cfSA013874@bartok.nlnetlabs.nl> References: <200503030938.j239cfSA013874@bartok.nlnetlabs.nl> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 03 March 2005 10:38 +0100 Jaap Akkerhuis wrote: > So pushing even more complications towards the resolver. > > I'm loosing track of all the corner cases which will be introduced > by NSEC2, NSEC3 and friends, although I see one common theme in > these solutions: methods to guard the server or the information it > produces, seem to put all of the burden towards the resolver. Proper > resolving for dnssec-bis is already difficult enough. I don't think this is fair criticism. Part of the issue here is that it seems to me DNSSEC has at least in part been driven by the protocol community, not the application community. So naturally we have a little bit of a vacuum when the question "how do you want the results presented" is asked anyway. Put NSEC3 aside for a minute. Can you give me a consistent answer to how an application that wants to resolve (say) www.microsoft.com to retrieve a web page should treat: a) Unsecurely denied existence (i.e. NXDOMAIN in vanilla DNS) b) Securely denied existence (i.e. normal NSEC) c) An attempt at secure denial of existence but where the proof fails due to i) expired keys ii) failed signature iii) unsupported signature algorithm d) Unsecure reported existence (i.e. an A record in vanilla DNS) e) Secure reported existence f) An attempt at a secure reported existence (i.e. signed RR) but the proof fails due to i) expired keys ii) failed signature iii) unsupported signature algorithm Now, that isn't an easy question to answer. As I argued previously, much depends on application behaviour (for instance whether it wants to treat (c)/(f) like (a)/(d) or as SERVFAIL, or some subcases of (c)/(f) differently, or report them to the user, or what), and we don't actually know what applications want to do. Now granted NSEC3 carries one more algorithm that might not be understood, and carries (with opt-in) one more possibility of generating case (a). However, it doesn't (it seems to me) change the number of end-cases (i.e. there is no '(g)' to add to the list above). Your criticism is valid in so much as DNSSEC-bis does not (currently) definitively determine what action an application should take (and perhaps this is right) so a resolver writer is going to be left passing quite a rich data set to the app "just in case" it wants to know; I agree incidentally that this isn't necessarily a recipe for ensuring application writers with little knowledge of DNSSEC end up writing secure apps. However, this is a criticism of DNSSEC (and the need to maintain backward compatibility) as a whole. NSEC3 should add no further states which the application writer needs to guard against. Clearly, NSEC3 is going to add some *internal* complexity to the resolver. But it should be just that: internal. And internal complexity is necessary (as far as I can see) to achieve the design objectives. I should point out that the server-side proposals for solutions were substantially more ugly in design terms (see epsilon draft - no criticism of the authors intended). 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 Mar 3 05:36:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04706 for ; Thu, 3 Mar 2005 05:36:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6ney-0003HS-CM for namedroppers-data@psg.com; Thu, 03 Mar 2005 10:34:24 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6new-0003Et-5i for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 10:34:22 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8807C33C6B; Thu, 3 Mar 2005 10:34:20 +0000 (GMT) Message-ID: <4226E8A7.5030507@algroup.co.uk> Date: Thu, 03 Mar 2005 10:36:23 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jaap Akkerhuis Cc: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <200503030938.j239cfSA013874@bartok.nlnetlabs.nl> In-Reply-To: <200503030938.j239cfSA013874@bartok.nlnetlabs.nl> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jaap Akkerhuis wrote: > > ok, so what if someone signs a zone with NSEC3 but not NSEC? that'll > > mean old validators can prove existence but not nonexistence. how would > > a validator signal nonexistence to its application? it would have to > > signal SERVFAIL rather than NXDOMAIN. is that ok? (it's important to > > know this, because the same thing happens if we change the NSEC3 hash > > later on, so it's not a once-only transition cost.) > > It sounds OK to me, though I can see why one might want a slightly > richer user experience, if only so the user has a better idea what they > might do about the failure ... > > So pushing even more complications towards the resolver. As Alex has pointed out, no new complications. This issue is there throughout DNSSEC. -- 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 Mar 3 05:38:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04833 for ; Thu, 3 Mar 2005 05:38:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6nh5-0003b9-9e for namedroppers-data@psg.com; Thu, 03 Mar 2005 10:36:35 +0000 Received: from [213.154.224.43] (helo=sol.nlnetlabs.nl) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6nh1-0003aq-VS for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 10:36:32 +0000 Received: from elektron.atoom.net (vhe-530008.sshn.net [195.169.222.38]) by sol.nlnetlabs.nl (Postfix) with ESMTP id 219171880AF for ; Thu, 3 Mar 2005 11:36:31 +0100 (CET) Received: by elektron.atoom.net (Postfix, from userid 1000) id F39211280D9; Thu, 3 Mar 2005 11:36:30 +0100 (CET) Date: Thu, 3 Mar 2005 11:36:30 +0100 From: Miek Gieben To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 Message-ID: <20050303103630.GA19524@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <4226D2C5.7000102@algroup.co.uk> <200503030938.j239cfSA013874@bartok.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503030938.j239cfSA013874@bartok.nlnetlabs.nl> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 03 Mar, @ 10:38, Jaap wrote in "Re: comments on nsec3-01 ..."] > > > ok, so what if someone signs a zone with NSEC3 but not NSEC? that'll > > mean old validators can prove existence but not nonexistence. how would > > a validator signal nonexistence to its application? it would have to > > signal SERVFAIL rather than NXDOMAIN. is that ok? (it's important to > > know this, because the same thing happens if we change the NSEC3 hash > > later on, so it's not a once-only transition cost.) > > It sounds OK to me, though I can see why one might want a slightly > richer user experience, if only so the user has a better idea what they > might do about the failure ... > > So pushing even more complications towards the resolver. I think this is a fair observation. I also feel that can all agree that o a DNSSEC aware resolver is a complicated beast o NSECx isn't going to make it any less complicated -- grtz, - Miek http://www.miek.nl http://www.nlnetlabs.nl -- 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 Mar 3 06:41:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12075 for ; Thu, 3 Mar 2005 06:41:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6oeD-000CrM-0k for namedroppers-data@psg.com; Thu, 03 Mar 2005 11:37:41 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6oeB-000Cqv-D9 for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 11:37:39 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j23BbZ27041072 for ; Thu, 3 Mar 2005 12:37:35 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.13.3/8.13.1/Submit) id j23BbZag041071 for namedroppers@ops.ietf.org; Thu, 3 Mar 2005 12:37:35 +0100 (CET) (envelope-from ted) Message-Id: <200503031137.j23BbZag041071@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Thu, 3 Mar 2005 12:37:35 +0100 In-Reply-To: "Ben Laurie's message as of Mar 3, 11:37" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Ben Laurie, on Mar 3, 11:37, in "Re: comments on nsec ..."] > As Alex has pointed out, no new complications. This issue is there > throughout DNSSEC. I'm affraid, I do not agree, and I think most of the protocol community here feels that NSEC3 does introduce new complications. What bothers me is that the desire of a few to obscure part of the data for which DNS is designed to make it available, now seems to lead to a situation where part (or most?) of the users (all but the members of the dnssec-of-the-month-club) must settle with either reduced functionality (SERVFAIL) or reduced security (or be "plain stupid" to quote Roy). 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 Mar 3 07:01:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14357 for ; Thu, 3 Mar 2005 07:01:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6oyv-000GP1-R7 for namedroppers-data@psg.com; Thu, 03 Mar 2005 11:59:05 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6oys-000GOG-It for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 11:59:02 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id A6329C2DA7; Thu, 3 Mar 2005 11:59:01 +0000 (GMT) Date: Thu, 03 Mar 2005 11:59:02 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Ted Lindgreen , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: comments on nsec3-01 Message-ID: <6AB55F43CA4DFC00E32BF01D@[192.168.100.25]> In-Reply-To: <200503031137.j23BbZag041071@open.nlnetlabs.nl> References: <200503031137.j23BbZag041071@open.nlnetlabs.nl> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 03 March 2005 12:37 +0100 Ted Lindgreen wrote: >> As Alex has pointed out, no new complications. This issue is there >> throughout DNSSEC. > > I'm affraid, I do not agree, and I think most of the protocol > community here feels that NSEC3 does introduce new complications. You are conflating two issues: complexity internal to the resolver (everyone agrees some of that is introduced), and different external data state (i.e. complexity of the resolver interface) - whilst you may think the external interface is more complex, I do not think "most of the protocol community" agrees. > What bothers me is that the desire of a few to obscure part of the > data for which DNS is designed to make it available, That is a disputed premise which I would suggest we have been asked not to debate here again. > now seems to > lead to a situation where part (or most?) of the users (all but the > members of the dnssec-of-the-month-club) must settle with either > reduced functionality (SERVFAIL) or reduced security This is palpable nonsense - sorry. The *users* of the DNSSEC protocol will a) See no change in functionality AT ALL except in zones where NSEC3 is deployed b) See no change in functionality AT ALL if a zone signed using NSEC were changed to NSEC3 (without opt-in) and the hash algorithm used was known to the resolver (which is no higher a hurdle than requiring the signature algorithm is known to the resolver). c) Can see unauthenticated denial of existence (i.e. the opt-in non-existence condition) exactly the same as the legacy unauthenticated denial of existence (i.e. NXDOMAIN unauthenticated) unless they choose to go into things more deeply and dig into why the result is unauthenticated (opt-in, vs vanilla DNS) - how many users will care? d) See unsupported hash protocols in the same way they see unsupported signature RRs. Exactly HOW does this reduce functionality for the user, or security, given that the resolver must already code with non-DNSSEC names, and with signature algorithm incompatibilities? Certainly it doesn't affect functionality when resolving non-NSEC3 signed zones AT ALL, nor NSEC3 (as opposed to NSEC signed zones) when hash algorithms are supported and opt-in is not used. Clearly NSEC3 signed zones that do use opt in do reduce security in terms of denial of existence. BUT THAT IS THE POINT! However, they increase security over (entirely) unsigned zones. 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 Mar 3 07:01:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14411 for ; Thu, 3 Mar 2005 07:01:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6p0O-000GoC-W1 for namedroppers-data@psg.com; Thu, 03 Mar 2005 12:00:36 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6p0M-000Gng-V0 for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 12:00:35 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5EC5B33C73; Thu, 3 Mar 2005 12:00:33 +0000 (GMT) Message-ID: <4226FCDB.5000608@algroup.co.uk> Date: Thu, 03 Mar 2005 12:02:35 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Lindgreen Cc: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <200503031137.j23BbZag041071@open.nlnetlabs.nl> In-Reply-To: <200503031137.j23BbZag041071@open.nlnetlabs.nl> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ted Lindgreen wrote: > [Quoting Ben Laurie, on Mar 3, 11:37, in "Re: comments on nsec ..."] > > >>As Alex has pointed out, no new complications. This issue is there >>throughout DNSSEC. > > > I'm affraid, I do not agree, and I think most of the protocol > community here feels that NSEC3 does introduce new complications. I meant no new complications in the interface between the resolver and the application. > What bothers me is that the desire of a few to obscure part of the > data for which DNS is designed to make it available, now seems to > lead to a situation where part (or most?) of the users (all but the > members of the dnssec-of-the-month-club) must settle with either > reduced functionality (SERVFAIL) SERVFAIL is suggested as the consequence of failure to validate a supposedly secure response. This is not caused by NSEC3, it can happen with any DNSSEC response. 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 Mar 3 08:47:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24118 for ; Thu, 3 Mar 2005 08:47:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6qbi-0006mR-Pe for namedroppers-data@psg.com; Thu, 03 Mar 2005 13:43:14 +0000 Received: from [193.0.3.29] (helo=fopje.dacht.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6qbe-0006lL-VL for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 13:43:11 +0000 Received: from [193.0.3.28] (unknown [193.0.3.28]) by fopje.dacht.net (Postfix) with ESMTP id 29FA62FC56 for ; Thu, 3 Mar 2005 14:43:09 +0100 (CET) Message-ID: <42271470.6040706@ripe.net> Date: Thu, 03 Mar 2005 14:43:12 +0100 From: "Olaf M. Kolkman" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: hash algorithm roll X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've started a new thread. I think we all agree that by using a scheme like the algorithm roll we can reliably move NSEC to NSEC3. Those validators that do not have NSEC3 implemented will have a "signed record" that will tell them this zone will use NSEC3 and those validators that do not understand NSEC3 will treat the data from that zone as insecure. A zone that would want to roll from NSEC to NSEC3 can do so gradually (if the signalling is done via algorithm rolls) as there is no down-grade attack possible. I am trying to assess if one can gradually go from NSEC3 with hash-algo 'a' to NSEC3 with hash-algo 'b' and I do not think it is possible. Changing hash-algorithms would be a flag date event. Even if the server would hand out NSEC3s with both hash-algos stripping of one of the NSEC3 RRs would go unnoticed as they are not tied together by an RRSIG. I seriously wonder if a domainowner (whose custommers pay to get secure delegations) would change the hashing algorithm so that a fair persentage of the validators in the field, that previously saw the zone as secure, now treat sub-domains become insecure. In other words I think that hash-algorithm rollover has its problems unless we make clear to the validator which hash algorithms to expect. (One of the signaling algorithms I can come up with is that the zone owner needs to use the same hashing algorithms in the NSEC3 as that are used in the signing algorithms. ugly ugly.) --Olaf (namedropper) -- 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 Mar 3 09:36:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29586 for ; Thu, 3 Mar 2005 09:36:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6rPM-000HEH-MG for namedroppers-data@psg.com; Thu, 03 Mar 2005 14:34:32 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6rPH-000HDP-73 for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 14:34:27 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j23EYM1o094990 for ; Thu, 3 Mar 2005 09:34:22 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j23EYMC5094989 for namedroppers@ops.ietf.org; Thu, 3 Mar 2005 09:34:22 -0500 (EST) (envelope-from namedroppers) Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6nhr-0003lM-62 for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 10:37:23 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id A33D433C45; Thu, 3 Mar 2005 10:37:21 +0000 (GMT) Message-ID: <4226E95C.6070006@algroup.co.uk> Date: Thu, 03 Mar 2005 10:39:24 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <20050302191545.94F8A13E3F@sa.vix.com> <4226D2C5.7000102@algroup.co.uk> <4226D8D0.20904@ripe.net> In-Reply-To: <4226D8D0.20904@ripe.net> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Olaf M. Kolkman wrote: > >>> >>> agreed, but what i'm trying to understand is whether we're reducing the >>> security for the part of the community who doesn't subscribe to the >>> dnssec-of-the-month club. if so, and if it's inevitable that we do this >>> and not merely a failing in the current draft, then we have to disclose >>> it to the communities who might fund the work or use it when complete. >> >> Given that the alternative (in the case of NSEC3) is no security at >> all, I can't see how we can be reducing security by deploying it. >> > > > > I interpret what Paul sais as: > > If you deploy today, the introduction of new features should not make > you vulnarable if you choose not to upgrade and use the new feature. > > I interpet what Ben sais as: > > If you cannot deal with the new features then you should treat the data > as if the features would not be there at all; treat the data as "classic > DNS". No, that's not what I'm saying. I'm saying that those who want NSEC3 _will not deploy_ with NSEC, so what you get _is_ classis DNS unless you deploy NSEC3. > Those are two different requirements. > > I think we all agree that iff a new feature is introduces (e.g. NSEC3) > it should be introduced in such a way that it is "neutral" for the usere > of DNSSECbis. That means you have to signal the use of NSEC3 by a zone. > There are multiple transition mechanisms that could be used such as > algorithm roll. Why doesn't it suffice to simply return NSEC3 records? Why do you need to know before you see an NSEC3 that the zone uses NSEC3? > What we are trying to assess now is what to do if we have a base of > deployed NSEC3 and we need to roll the hash algorithm. I suspect that if we have any sense, we'd use the same algorithm for NSEC3 as we do for signing, so we'd only have to roll it if we had to roll the signing algorithm. 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 Mar 3 09:36:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29645 for ; Thu, 3 Mar 2005 09:36:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6rOb-000H4c-47 for namedroppers-data@psg.com; Thu, 03 Mar 2005 14:33:45 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6rOZ-000H4E-Je for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 14:33:44 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j23EXcQ9094983 for ; Thu, 3 Mar 2005 09:33:38 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j23EXcw9094982 for namedroppers@ops.ietf.org; Thu, 3 Mar 2005 09:33:38 -0500 (EST) (envelope-from namedroppers) Received: from [193.0.3.29] (helo=fopje.dacht.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6mdT-000ItW-Iq for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 09:28:47 +0000 Received: from [193.0.3.28] (unknown [193.0.3.28]) by fopje.dacht.net (Postfix) with ESMTP id 6083F2FC56; Thu, 3 Mar 2005 10:28:45 +0100 (CET) Message-ID: <4226D8D0.20904@ripe.net> Date: Thu, 03 Mar 2005 10:28:48 +0100 From: "Olaf M. Kolkman" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <20050302191545.94F8A13E3F@sa.vix.com> <4226D2C5.7000102@algroup.co.uk> In-Reply-To: <4226D2C5.7000102@algroup.co.uk> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] >> >> agreed, but what i'm trying to understand is whether we're reducing the >> security for the part of the community who doesn't subscribe to the >> dnssec-of-the-month club. if so, and if it's inevitable that we do this >> and not merely a failing in the current draft, then we have to disclose >> it to the communities who might fund the work or use it when complete. > > > Given that the alternative (in the case of NSEC3) is no security at > all, I can't see how we can be reducing security by deploying it. > I interpret what Paul sais as: If you deploy today, the introduction of new features should not make you vulnarable if you choose not to upgrade and use the new feature. I interpet what Ben sais as: If you cannot deal with the new features then you should treat the data as if the features would not be there at all; treat the data as "classic DNS". Those are two different requirements. I think we all agree that iff a new feature is introduces (e.g. NSEC3) it should be introduced in such a way that it is "neutral" for the usere of DNSSECbis. That means you have to signal the use of NSEC3 by a zone. There are multiple transition mechanisms that could be used such as algorithm roll. What we are trying to assess now is what to do if we have a base of deployed NSEC3 and we need to roll the hash algorithm. --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 Mar 3 09:59:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01459 for ; Thu, 3 Mar 2005 09:59:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6rkN-000Kr6-D5 for namedroppers-data@psg.com; Thu, 03 Mar 2005 14:56:15 +0000 Received: from [195.54.233.67] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6rkI-000KqP-Ng for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 14:56:11 +0000 Received: from shaun.rfc1035.com (shaun.rfc1035.com [195.54.233.67]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j23EtwGW023240; Thu, 3 Mar 2005 14:55:58 GMT To: Ben Laurie cc: "Olaf M. Kolkman" , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-Reply-To: Message from Ben Laurie of "Thu, 03 Mar 2005 10:39:24 GMT." <4226E95C.6070006@algroup.co.uk> Date: Thu, 03 Mar 2005 14:55:58 +0000 Message-ID: <23239.1109861758@shaun.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Just curious. If/when DNSSEC-ter gets through IETF, what's going to be done about RFC3225? Are more EDNS header bits going to be used to signal that a resolver groks NSEC[23] (or whatever) RRs but not NSECs? And vice versa? -- 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 Mar 3 10:18:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04574 for ; Thu, 3 Mar 2005 10:18:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6s3e-000P18-T5 for namedroppers-data@psg.com; Thu, 03 Mar 2005 15:16:10 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6s3T-000Ozv-Bd for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 15:15:59 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 44C1233C45 for ; Thu, 3 Mar 2005 15:15:57 +0000 (GMT) Message-ID: <42272AA8.3010403@algroup.co.uk> Date: Thu, 03 Mar 2005 15:18:00 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: DNSEXT WG Subject: Proof of nonexistence for NSEC3 X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Following a revelation about NSEC3 nonexistence proofs, I have proposed language to add to the I-D. Comments, please... "If a wildcard ownername appears in a zone, the wildcard label ("*") is treated as a literal symbol and is treated in the same way as any other ownername for purposes of generating NSEC3 RRs. RFC 2535 describes the impact of wildcards on authenticated denial of existence. In order to prove there are no wildcards for a domain, as well as no RRs that match directly, an RR must be shown for the closest encloser, and non-existence must be shown for all enclosers that could be closer. If we are attempting to prove the non-existence of some domain, then in general the domain is of the form P.x.C where C is the closest encloser in the zone (there is always one, if nothing else, the apex of th4e zone), x is the label immediately preceding the closest encloser (again, there must always be one, since if there weren't then the domain would be C, which exists), and P is the (possibly empty) remainder of the domain. To prove the nonexistence of P.x.C, we must show that C exists, x.C does not exist and *.C does not exist. Because x.C does not exist, all possible closer enclosers and wildcards also cannot exist (if they did, there would at least be an empty non-terminal at x.C), so these three facts are always sufficient to prove the nonexistence of P.x.C. In practice, then, we must show an NSEC3 record that encloses the hash of x.C, one that encloses the hash of *.C, and any RR owned by C (which could be an NSEC3, in which case it would be owned by the hash of C). A resolver verifying this proof would have to try longer and longer closest enclosers to determine which was being demonstrated as C, if an NSEC3 is presented. If any other RR was used, then C would be the owner. Once C has been determined, the resolver can easily check x.C and *.C against the proof." 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 Mar 3 10:24:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05338 for ; Thu, 3 Mar 2005 10:24:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6s9p-0000Bu-8V for namedroppers-data@psg.com; Thu, 03 Mar 2005 15:22:33 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6s9o-0000Bg-6w for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 15:22:32 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 66DC1C2DA7; Thu, 3 Mar 2005 15:22:31 +0000 (GMT) Date: Thu, 03 Mar 2005 15:22:34 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie , "Olaf M. Kolkman" Cc: Paul Vixie , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: comments on nsec3-01 Message-ID: <0FE82C52CB37C969FE59F217@[192.168.100.25]> In-Reply-To: <4226E95C.6070006@algroup.co.uk> References: <20050302191545.94F8A13E3F@sa.vix.com> <4226D2C5.7000102@algroup.co.uk> <4226D8D0.20904@ripe.net> <4226E95C.6070006@algroup.co.uk> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 03 March 2005 10:39 +0000 Ben Laurie wrote: >> If you cannot deal with the new features then you should treat the data >> as if the features would not be there at all; treat the data as "classic >> DNS". > > No, that's not what I'm saying. I'm saying that those who want NSEC3 > _will not deploy_ with NSEC, so what you get _is_ classis DNS unless you > deploy NSEC3. Whilst I agree with your argument in general, the foregoing is actually an exaggeration. Yes, a large constituency of those who want NSEC3 will not deploy with NSEC. However, there are others for whom NSEC3 is desirable (perhaps because it gives opt-in, perhaps because they don't like enumeration but are less fussed about it than others, perhaps because they like to be using 'the latest code' for whatever reason) who will deploy NSEC then NSEC3. For these people, it is (as Olaf states) a reasonable requirement that there is no degradation of functionality UNLESS it is intended by the user; by which I mean the user switching from NSEC to NSEC3 to exploit opt-in to reduce the size of a zonefile with only sparse secure delegations knows has the option to use opt-in or not, and any consequent perceived reduction in security from lack of authenticated denial is his own choice - he could have used NSEC3 without opt-in. So while Olaf has Paul saying: > If you deploy today, the introduction of new features should not make you > vulnarable if you choose not to upgrade and use the new feature. that's a reasonable requirement if by "use the new feature" you mean "use NSEC3 not NSEC" provided you also add "and do not deliberately use options that arguably make you more vulnerable" (e.g. opt-in). 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 Mar 3 10:26:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05604 for ; Thu, 3 Mar 2005 10:26:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6sCc-0000me-Ev for namedroppers-data@psg.com; Thu, 03 Mar 2005 15:25:26 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6sCa-0000m9-HZ for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 15:25:24 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id D18DCC2DA7; Thu, 3 Mar 2005 15:25:23 +0000 (GMT) Date: Thu, 03 Mar 2005 15:25:27 +0000 From: Alex Bligh Reply-To: Alex Bligh To: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: hash algorithm roll Message-ID: <7E3123F36FD7FEE8112AAE16@[192.168.100.25]> In-Reply-To: <42271470.6040706@ripe.net> References: <42271470.6040706@ripe.net> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 03 March 2005 14:43 +0100 "Olaf M. Kolkman" wrote: > I think we all agree that by using a scheme like the algorithm roll we > can reliably move NSEC to NSEC3. Those validators that do not have NSEC3 > implemented will have a "signed record" that will tell them this zone > will use NSEC3 and those validators that do not understand NSEC3 will > treat the data from that zone as insecure. ... > In other words I think that hash-algorithm rollover has its problems > unless we make clear to the validator which hash algorithms to expect. Just out of interest, is hash-algorithm rollover that important in practice? Would it be a Very Bad Thing (tm) if hash-algorithm rollover was handled just like the NSEC->NSEC3 transition you describe - i.e. fix supported hash algorithms in NSEC3, code in lots of hashes with variable truncation parameters, deprecate any found to be terminally weak, and if we end up with no usable hashes, invent NSEC4 with some working ones and roll to that in the same way as NSEC->NSEC3? 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 Mar 3 11:06:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10139 for ; Thu, 3 Mar 2005 11:06:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6snm-0007Yd-TK for namedroppers-data@psg.com; Thu, 03 Mar 2005 16:03:50 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6sni-0007Wx-Gn for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 16:03:46 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j23G2ZQJ095589; Thu, 3 Mar 2005 11:02:36 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <42272AA8.3010403@algroup.co.uk> References: <42272AA8.3010403@algroup.co.uk> Date: Thu, 3 Mar 2005 11:02:36 -0500 To: Ben Laurie From: Edward Lewis Subject: Re: Proof of nonexistence for NSEC3 Cc: DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk For some reason I've popped open this message without reading any other parts of the threads on this. Yet I am compelled to write...;) At 15:18 +0000 3/3/05, Ben Laurie wrote: >Following a revelation about NSEC3 nonexistence proofs, I have >proposed language to add to the I-D. Comments, please... > >"If a wildcard ownername appears in a zone, the wildcard label ("*") >is treated as a literal symbol and is treated in the same way as any >other ownername for purposes of generating NSEC3 RRs. RFC 2535 describes the >impact of wildcards on authenticated denial of existence. In wcard, I've defined "asterisk label" for "*". >In order to prove there are no wildcards for a domain, as well as no >RRs that match directly, an RR must be shown for the closest encloser, >and non-existence must be shown for all enclosers that could be >closer. More terminology that has to be fixed. "In order to prove there are no wildcards (source of synthesis) applicable to a lookup..." Also, by definition there cannot be enclosers closer that the closest enclosure. I.e., you establish the closest encloser by showing that the span "beyond" it includes the sought name. >If we are attempting to prove the non-existence of some domain, >then in general the domain is of the form P.x.C where C is the closest >encloser in the zone (there is always one, if nothing else, the apex >of the zone), x is the label immediately preceding the closest >encloser (again, there must always be one, since if there weren't then >the domain would be C, which exists), and P is the (possibly empty) >remainder of the domain. To prove the nonexistence of P.x.C, we must >show that C exists, x.C does not exist and *.C does not exist. Because >x.C does not exist, all possible closer enclosers and wildcards also >cannot exist (if they did, there would at least be an empty >non-terminal at x.C), so these three facts are always sufficient to >prove the nonexistence of P.x.C. The goal is to prove that there are no records to return in an answer. One strategy is to show that the static parts of the tree which would have been the source of an answer (exact match, source of synthesis) do not exist. Another strategy is to have the name server craft a "take my word for it, there's nothing." I say this so that no one remains fixated on the existence question - that ain't the real problem. Think of source of synthesis and closest enclosers in the dynamic context of a lookup. They mean nothing with staring at the static tree of domains. There is no x...in the tree. I guess you mean that x is the most significant label in the sought name that does not match one in the tree? I don't get the need to prove anything about P.x.C. If x is in the tree, then x.C is the closest encloser. If x isn't, then there isn't P.x either. >In practice, then, we must show an NSEC3 record that encloses the >hash of x.C, one that encloses the hash of *.C, and any RR owned by C >(which could be an NSEC3, in which case it would be owned by the hash >of C). A resolver verifying this proof would have to try longer and >longer closest enclosers to determine which was being demonstrated as >C, if an NSEC3 is presented. If any other RR was used, then C would be >the owner. Once C has been determined, the resolver can easily check >x.C and *.C against the proof." In order to return an RCODE=name error when dealing with hashes instead of names, three stipulations have to be made. 1) You need to demonstrate that the hash of the searched name falls into a span of hashes not in the zone (not necessarily it's closest encloser). 2) You have to reveal (and prove) the closest encloser. 3) You have to show that the would-be source of synthesis has a hash that falls in to the span of hashes not in the zone. Number 2 may be the trickiest part. Maybe that's what you said...what do you mean by "[i]f any other RR was used..."? RR as in the QTYPE? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 3 11:07:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10178 for ; Thu, 3 Mar 2005 11:07:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6spm-00085J-Ko for namedroppers-data@psg.com; Thu, 03 Mar 2005 16:05:54 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6spk-00083V-RQ for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 16:05:53 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j23G5mXq095600 for ; Thu, 3 Mar 2005 11:05:48 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.0.14.2.20050303105509.02c0c878@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 03 Mar 2005 11:05:40 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: DNSEXT small "design team" meeting slots Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Following on the success of our small gatherings in Washington at the last IETF, the DNSEXT chairs have secured a room for a small number of people and are planning to use that for meetings. Some of the meetings could be classified as ad-hoc design teams, others as high bandwidth low latency discussion forum with white board. It is not the intention to make any decisions in these meetings. The intention is only to "brainstorm". Any results will need to be reflected in I-Ds that will need to receive WG scrutiny. People are welcome to join but since the space in the room is limited you will have to notify the chairs that you intend to participate. If more people want to attend any session the chairs will inform when slots are full. Tentative time slots for these meetings are: Monday 9:00 - 11:30 Negative answer session NSEC-epsilon signing issues Hash based Negative answers Signed negative query response or BERT Monday at 15:30 - 17:30 Synthesis session Requirements for wildcards and wildcard alternatives, this meeting will have two different topics - first to discuss the wildcard clarify document open issues. - second to follow up on long discussion on namedroppers about the need for different kinds of wildcards and what they may look like. This session is indented to gather requirements and discuss various ideas on how to meet these requirements, inside and outside the protocol. Wed at 15:30 - 17:30 DNS interoperabilty testing plan The working group has many documents lingering at Proposed standards level that need to be advanced to draft standard. This meeting is to facilitate more interoperabilty testing and how to do it in a short time. At each meeting an official meeting reporter will be appointed to submit to namedroppers a report on what took place in these meetings. If you are interested to be the reporter in any meeting please indicate that in your request. The chairs want to thank Bill Manning for enabling these gatherings. Olafur and 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 Mar 3 12:07:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18806 for ; Thu, 3 Mar 2005 12:07:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6tkX-000HLF-9Y for namedroppers-data@psg.com; Thu, 03 Mar 2005 17:04:33 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6tkU-000HKP-PL for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 17:04:31 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5F65933C45; Thu, 3 Mar 2005 17:04:28 +0000 (GMT) Message-ID: <42274417.4070504@algroup.co.uk> Date: Thu, 03 Mar 2005 17:06:31 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis Cc: DNSEXT WG Subject: Re: Proof of nonexistence for NSEC3 References: <42272AA8.3010403@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > For some reason I've popped open this message without reading any other > parts of the threads on this. Yet I am compelled to write...;) > > At 15:18 +0000 3/3/05, Ben Laurie wrote: > >> Following a revelation about NSEC3 nonexistence proofs, I have >> proposed language to add to the I-D. Comments, please... >> >> "If a wildcard ownername appears in a zone, the wildcard label ("*") >> is treated as a literal symbol and is treated in the same way as any >> other ownername for purposes of generating NSEC3 RRs. RFC 2535 >> describes the >> impact of wildcards on authenticated denial of existence. > > > In wcard, I've defined "asterisk label" for "*". You mean we should change "wildcard label" to "asterisk label"? >> In order to prove there are no wildcards for a domain, as well as no >> RRs that match directly, an RR must be shown for the closest encloser, >> and non-existence must be shown for all enclosers that could be >> closer. > > > More terminology that has to be fixed. "In order to prove there are no > wildcards (source of synthesis) applicable to a lookup..." Also, by > definition there cannot be enclosers closer that the closest enclosure. > I.e., you establish the closest encloser by showing that the span > "beyond" it includes the sought name. Sure. Perhaps I should change the wording to "an RR must be shown for the _alleged_ closest encloser" to make it clear? >> If we are attempting to prove the non-existence of some domain, >> then in general the domain is of the form P.x.C where C is the closest >> encloser in the zone (there is always one, if nothing else, the apex >> of the zone), x is the label immediately preceding the closest >> encloser (again, there must always be one, since if there weren't then >> the domain would be C, which exists), and P is the (possibly empty) >> remainder of the domain. To prove the nonexistence of P.x.C, we must >> show that C exists, x.C does not exist and *.C does not exist. Because >> x.C does not exist, all possible closer enclosers and wildcards also >> cannot exist (if they did, there would at least be an empty >> non-terminal at x.C), so these three facts are always sufficient to >> prove the nonexistence of P.x.C. > > > The goal is to prove that there are no records to return in an answer. > One strategy is to show that the static parts of the tree which would > have been the source of an answer (exact match, source of synthesis) do > not exist. Another strategy is to have the name server craft a "take my > word for it, there's nothing." I say this so that no one remains > fixated on the existence question - that ain't the real problem. > > Think of source of synthesis and closest enclosers in the dynamic > context of a lookup. They mean nothing with staring at the static tree > of domains. > > There is no x...in the tree. I guess you mean that x is the most > significant label in the sought name that does not match one in the tree? Yes - as I said "x is the lebel immediately preceding the closest encloser". > I don't get the need to prove anything about P.x.C. If x is in the > tree, then x.C is the closest encloser. If x isn't, then there isn't > P.x either. This is almost my point precisely (up to now, people have thought you had to prove every possible encloser separately), except that C is in the tree and x.C isn't. >> In practice, then, we must show an NSEC3 record that encloses the >> hash of x.C, one that encloses the hash of *.C, and any RR owned by C >> (which could be an NSEC3, in which case it would be owned by the hash >> of C). A resolver verifying this proof would have to try longer and >> longer closest enclosers to determine which was being demonstrated as >> C, if an NSEC3 is presented. If any other RR was used, then C would be >> the owner. Once C has been determined, the resolver can easily check >> x.C and *.C against the proof." > > > In order to return an RCODE=name error when dealing with hashes instead > of names, three stipulations have to be made. > > 1) You need to demonstrate that the hash of the searched name falls into > a span of hashes not in the zone (not necessarily it's closest encloser). No, if the x.C (being one longer than the closest encloser) doesn't exist, then the searched named does not exist. > 2) You have to reveal (and prove) the closest encloser. Indeed, that is why you show an NSEC3 for (i.e. owned by the hash of) C (or some other RR owned by C) and show the nonexistence of x.C. > 3) You have to show that the would-be source of synthesis has a hash > that falls in to the span of hashes not in the zone. And that is why you show the nonexistence of *.C. > Number 2 may be the trickiest part. > > Maybe that's what you said...what do you mean by "[i]f any other RR was > used..."? RR as in the QTYPE? I mean that to prove the existence of C any RR owned by C suffices. 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 Mar 3 12:27:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20986 for ; Thu, 3 Mar 2005 12:27:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6u3z-000KSz-HD for namedroppers-data@psg.com; Thu, 03 Mar 2005 17:24:39 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6u3S-000KQ8-2D for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 17:24:06 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j23HMrtE096227; Thu, 3 Mar 2005 12:22:54 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <42274417.4070504@algroup.co.uk> References: <42272AA8.3010403@algroup.co.uk> <42274417.4070504@algroup.co.uk> Date: Thu, 3 Mar 2005 12:22:57 -0500 To: Ben Laurie From: Edward Lewis Subject: Re: Proof of nonexistence for NSEC3 Cc: Edward Lewis , DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:06 +0000 3/3/05, Ben Laurie wrote: >You mean we should change "wildcard label" to "asterisk label"? Yeah. >Sure. Perhaps I should change the wording to "an RR must be shown for the >_alleged_ closest encloser" to make it clear? That wording is also unclear. (What RR? A TXT record?) The response message needs to demonstrate to the validator/evaluator what the closest encloser is. >> There is no x...in the tree. I guess you mean that x is the most >>significant label in the sought name that does not match one in the >>tree? > >Yes - as I said "x is the lebel immediately preceding the closest encloser". Still confused. "Preceding" from the root to the closest encloser? Or the label at which the match failed? >This is almost my point precisely (up to now, people have thought you had to >prove every possible encloser separately), except that C is in the tree and >x.C isn't. Once we understood the concept of the closest encloser, it became apparent that the higher (in the tree) enclosers are unimportant. 'Course, this assumes the tree structure is apparent. >No, if the x.C (being one longer than the closest encloser) doesn't exist, >then the searched named does not exist. Existence isn't the point. It's whether there are answers available. You don't set a return code of name error when the answer is synthesized. >And that is why you show the nonexistence of *.C. ... >I mean that to prove the existence of C any RR owned by C suffices. I guess the point I'm trying to make is that DNS is a client-server protocol. It's more important to achieve the goal of information transfer than to bury ourselves in mathematics of proofs. The server generates a response. The server needs to know what statements are needed to express a certain result - such as an answer, a synthesized answer, no data available, or no applicable domain name. The protocol does not assign different credibilities to stock and synthesized answers, the only reason the server indicates any difference is to demonstrate that it has dutifully followed the algorithm in RCFC 1034. The response is interpreted by the client. It is the one that "proves" to itself the assertions in the response. It's up to the client to decide how to do the proof - e.g., take everything at face value. A more prudent client would be looking for statements it can use to verify that the server followed the protocol. Not for correctness, mind you, but to make sure that the message originated from an authoritative source. I'm not picking on the math in the draft. I'm picking on the tone of the description. DNSSEC in 2065 and 2535 spent too much time trying to get the theory right and not enough time understanding that DNS is a client-server protocol. I.e., it's not existence that I care about, it's whether there is an answer. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 3 15:12:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09219 for ; Thu, 3 Mar 2005 15:12:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6wbp-000LWW-Qu for namedroppers-data@psg.com; Thu, 03 Mar 2005 20:07:45 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6wbm-000LVu-Dm for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 20:07:42 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j23K47XL013597 for ; Thu, 3 Mar 2005 15:04:07 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKLaGJA; Thu, 3 Mar 05 15:04:04 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j23K5m6n012126; Thu, 3 Mar 2005 15:05:50 -0500 (EST) Date: Thu, 3 Mar 2005 15:05:47 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Alex Bligh cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: hash algorithm roll In-Reply-To: <7E3123F36FD7FEE8112AAE16@[192.168.100.25]> Message-ID: References: <42271470.6040706@ripe.net> <7E3123F36FD7FEE8112AAE16@[192.168.100.25]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Just out of interest, is hash-algorithm rollover that important in > practice? Happily, we have a requirements document for this problem (draft-ietf-dnsext-signed-nonexistence-requirements-01.txt). It does not include hash function rollover as a requirement. The more time I spend on this, the more willing I become to answer "no" -- I'm willing to accept not being able to roll hash functions. I'm even willing to accept the current document's instructions for what to do with NSEC3 RRs w/ unknown hashes: discard them. I don't think it's good engineering, but if it's sufficient for those who want NSEC3, it will get us NSEC3 (and hopefully signed zones) sooner while taking less effort, and that's a good thing. Perfect is the enemy of deployed. -- 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 Thu Mar 3 15:37:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12989 for ; Thu, 3 Mar 2005 15:37:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6x2l-000PpA-Kg for namedroppers-data@psg.com; Thu, 03 Mar 2005 20:35:35 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6x2j-000Pox-6i for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 20:35:33 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id E8946C2DA7; Thu, 3 Mar 2005 20:35:31 +0000 (GMT) Date: Thu, 03 Mar 2005 20:35:35 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Samuel Weiler Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: hash algorithm roll Message-ID: In-Reply-To: References: <42271470.6040706@ripe.net> <7E3123F36FD7FEE8112AAE16@[192.168.100.25]> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 03 March 2005 15:05 -0500 Samuel Weiler wrote: >> Just out of interest, is hash-algorithm rollover that important in >> practice? > > Happily, we have a requirements document for this problem > (draft-ietf-dnsext-signed-nonexistence-requirements-01.txt). > It does not include hash function rollover as a requirement. > > The more time I spend on this, the more willing I become to answer > "no" -- I'm willing to accept not being able to roll hash functions. > I'm even willing to accept the current document's instructions for > what to do with NSEC3 RRs w/ unknown hashes: discard them. I don't > think it's good engineering, but if it's sufficient for those who want > NSEC3, it will get us NSEC3 (and hopefully signed zones) sooner while > taking less effort, and that's a good thing. Actually I think I may have an engineering reason why not supporting rollover is a good idea - it's (provably) never actually going to be useful. Let's assume: A. NSEC3 (as finally published) supports the following types of hash i) identity 'hash' ii) trivially invertible (e.g. 32 bit XOR) test 'hash' so those worried about collisions can test it. iii) SHA-1 iv) SHA-512 truncated to n octets for various values of n v) WHIRLPOOL (512 bit) truncated to n octets for various values of n and that all the above are mandatory B. There exists some mechanism of doing a hash algorithm rollover (yes, some people may consider this counterfactual, but hang in there, I think I'm coming out on your side). C. There is a (subsequent) requirement to do an algorithm rollover. If so, one has to ask what on earth would have driven the requirement? The only thing I can think of is that one or more of the useful hashes (iii) (iv) and (v) is found to be broken in some way, i.e. partially invertible. The zone publisher no doubt wants to prevent enumeration, or they'd be using the identity hash, or would be unfussed about the breakage. Now, if some, but not all of the useful hash algorithms in the standard are broken, they can 'roll-over' to another (supported) algorithm - this isn't a real roll-over problem, this is just "take your next version of the zone with different algorithm NSEC3" - the resolver must either support NSEC3 and all the algorithms on publication, or none. EG if SHA-1 is broken, the signer can switch to (say) SHA-512 truncated, because he knows all resolvers must support that. So the only requirement for a real rollover (where you face the possibility that a resolver does not understand an algorithm you've newly introduced) is where ALL the hash algorithms available in the (as published) NSEC3 are inadequate and so you've introduced a new algorithm (say a newly designed SHA-1024). But then, by assumption, you CAN'T do a useful rollover - i.e. you can't usefully support both old resolvers (which don't understand new fangled SHA-1024), and new resolvers (that do), because to do so you'd have to publish NSEC3 records generated with both hash algorithms, and that would mean that an attacker need only signal that it is an old-resolver (however that's done), receive the old NSEC3 records, and attack those. The only type of rollover that's useful in the "help all my hash functions have become useless and I'm now worried about enumeration" scenario is to cease publishing NSEC3 records with ANY broken hash function. If you're going to publish NSEC3 records at all, that means you ONLY publish with new and (by old resolvers) unsupported hash functions. In this instance, it seems to me a better type of rollover would be much like that suggested between NSEC and NSEC3: generate NSEC4 RR's to replace all NSEC RRs and say "this just isn't going to work with NSEC3-only resolvers". Let's just make sure on publication there are some ridiculously long hash functions in there so this "never happens" (watch me eat my words later). 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 Mar 3 16:08:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15465 for ; Thu, 3 Mar 2005 16:08:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6xW3-0005Uj-4k for namedroppers-data@psg.com; Thu, 03 Mar 2005 21:05:51 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6xW1-0005U5-4c for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 21:05:49 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 89490677EF for ; Thu, 3 Mar 2005 21:05:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j23L5gBV005801; Fri, 4 Mar 2005 08:05:42 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200503032105.j23L5gBV005801@drugs.dv.isc.org> To: Samuel Weiler Cc: Alex Bligh , "Olaf M. Kolkman" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: hash algorithm roll In-reply-to: Your message of "Thu, 03 Mar 2005 15:05:47 CDT." Date: Fri, 04 Mar 2005 08:05:42 +1100 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Just out of interest, is hash-algorithm rollover that important in > > practice? > > Happily, we have a requirements document for this problem > (draft-ietf-dnsext-signed-nonexistence-requirements-01.txt). > It does not include hash function rollover as a requirement. > > The more time I spend on this, the more willing I become to answer > "no" -- I'm willing to accept not being able to roll hash functions. > I'm even willing to accept the current document's instructions for > what to do with NSEC3 RRs w/ unknown hashes: discard them. I don't > think it's good engineering, but if it's sufficient for those who want > NSEC3, it will get us NSEC3 (and hopefully signed zones) sooner while > taking less effort, and that's a good thing. > > Perfect is the enemy of deployed. But when does the list of things that can't be done w/ NSEC3 get so big that we say "this proposal is broken"? > -- 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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 Mar 3 16:20:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16480 for ; Thu, 3 Mar 2005 16:20:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6xhc-0007QP-SD for namedroppers-data@psg.com; Thu, 03 Mar 2005 21:17:48 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6xhb-0007QD-O1 for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 21:17:47 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5F29113E3F for ; Thu, 3 Mar 2005 21:17:47 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-Reply-To: Message from Jim Reid of "Thu, 03 Mar 2005 14:55:58 GMT." <23239.1109861758@shaun.rfc1035.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 03 Mar 2005 21:17:47 +0000 Message-Id: <20050303211747.5F29113E3F@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Just curious. If/when DNSSEC-ter gets through IETF, what's going to be > done about RFC3225? Are more EDNS header bits going to be used to > signal that a resolver groks NSEC[23] (or whatever) RRs but not NSECs? > And vice versa? previously i'd suggested the following: DNSEXT Working Group Paul Vixie INTERNET-DRAFT ISC June 2004 Extending DNSSEC-BIS (DNSSEC-TER) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract As the DNSSEC-BIS document set goes to press, we find that the design goals for DNSSEC have shifted somewhat in the ten years of its preproduction. This memo lists some possible new directions for DNSSEC-TER, and also, some methods by which DNSSEC-TER could first coexist with, and possibly replace, DNSSEC-BIS. 1 - Rationale and Scope 1.1. DNSSEC-BIS, which took ten years to evolve, is widely considered to be a working solution for end to end DNS data authenticity. However, the threat model which drove the design of DNSSEC and DNSSEC-BIS fails to address issues of great interest to some members of the community, for example, domain name confidentiality. Expires December 2004 [Page 1] INTERNET-DRAFT DNSSEC-TER June 2004 1.2. Without proposing any specific new features, this memo will lay out an upgrade path whereby DNSSEC-TER could first coexist with, and then possibly replace DNSSEC-BIS, with no loss of functionality for DNSSEC- BIS adopters. The method used has been called a "type code roll" or TCR. 1.3. The goal of this memo is not to specify DNSSEC-TER itself, but rather, to describe the method by which it can be developed and deployed, compatibly with an existing DNSSEC-BIS installed base. 2 - New Signalling, New Metadata 2.1. Since DNSSEC-BIS already depends on EDNS due to message size increases, it is safe to depend on EDNS to carry a new DNSSEC-TER flag. The meaning of this flag would be, generally, "when I say I want DNSSEC metadata in the response to this query, I can handle, and prefer, DNSSEC-TER metadata." 2.2. DNSSEC-TER might define new metadata records (for example, DS2, NSEC2, RRSIG2, and/or DNSKEY2), but will not redefine the meaning or format of existing DNSSEC-BIS metadata records due to the risk of these records becoming separated from the DNSSEC-TER tag that tells how to interpret them. 2.3. EDNS is a hop by hop protocol, carrying meaning only between an initiator and a responder. A caching forwarder who can process both DNSSEC-TER and DNSSEC-BIS will "tag" its security metadata using the "DNSSEC-TER data is wanted" status of the query which causes that metadata to enter the cache. If cached data exists but was fetched without (or with) this tag, and a query arrives with (or without) the "DNSSEC-TER wanted" flag, then the new query will have to be forwarded upstream toward the authority servers, and the result (even if negative) will be cached and used separately. This behaviour has the effect of promoting the "DNSSEC-TER" wanted flag from hop-by-hop to end-to-end. 2.4. If an authority server or caching recursive server is asked for DNSSEC-TER metadata but only has DNSSEC-BIS metadata available, then DNSSEC-BIS data will be sent. Thus, a requestor who is capable of handling DNSSEC-TER metadata records should ask for DNSSEC-TER first, and then fall back to DNSSEC-BIS if necessary. This optimizes for the eventual case when the installed base of DNSSEC-BIS has completely upgraded to DNSSEC-TER. An initiator is not permitted to assume, from the lack of a DNSSEC-TER response, that either that server or that zone does not in general support DNSSEC-TER. Expires December 2004 [Page 2] INTERNET-DRAFT DNSSEC-TER June 2004 2.5. A zone signer and/or authority server might choose to support both DNSSEC-BIS and DNSSEC-TER, or only DNSSEC-BIS, or only DNSSEC-TER. It is expected that a validating recursive server, or a caching recursive server, will support either DNSSEC-BIS alone (as is the case today), or both DNSSEC-BIS and DNSSEC-TER, but never DNSSEC-TER alone. 3 - References [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [RFC2671] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671, IETF DNSIND, September 1998 4 - Author's Address Paul Vixie Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 +1.650.423.1301 3557*VIX Expires December 2004 [Page 3] -- 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 Mar 3 16:28:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17085 for ; Thu, 3 Mar 2005 16:28:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6xqe-00092M-50 for namedroppers-data@psg.com; Thu, 03 Mar 2005 21:27:08 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6xqd-000923-A3 for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 21:27:07 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EFCF513E3F for ; Thu, 3 Mar 2005 21:27:06 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 In-Reply-To: Message from Alex Bligh of "Thu, 03 Mar 2005 15:22:34 GMT." <0FE82C52CB37C969FE59F217@[192.168.100.25]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 03 Mar 2005 21:27:06 +0000 Message-Id: <20050303212706.EFCF513E3F@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > No, that's not what I'm saying. I'm saying that those who want NSEC3 > > _will not deploy_ with NSEC, so what you get _is_ classis DNS unless you > > deploy NSEC3. > > Whilst I agree with your argument in general, the foregoing is actually an > exaggeration. Yes, a large constituency of those who want NSEC3 will not > deploy with NSEC. However, there are others for whom NSEC3 is desirable ... > > So while Olaf has Paul saying: > > If you deploy today, the introduction of new features should not > > make you vulnarable if you choose not to upgrade and use the new > > feature. > > that's a reasonable requirement if by "use the new feature" you mean > "use NSEC3 not NSEC" provided you also add "and do not deliberately > use options that arguably make you more vulnerable" (e.g. opt-in). and yet, none of these takes account of what i meant by dnssec-of-the-month. every time we roll the hash algo for NSEC3, the problem recurs. if it was just that adding NSEC3 made zones less secure while validators were yet to upgrade, then there'd be a flag day. we're talking about a flag-tuesday. every tuesday from now on. is that ok? -- 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 Mar 3 19:07:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01760 for ; Thu, 3 Mar 2005 19:07:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D70IH-0008IH-HT for namedroppers-data@psg.com; Fri, 04 Mar 2005 00:03:49 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D70IF-0008HZ-0m for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 00:03:47 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id D355867503 for ; Fri, 4 Mar 2005 00:03:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j2403fCP019008; Fri, 4 Mar 2005 11:03:42 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200503040003.j2403fCP019008@drugs.dv.isc.org> To: Donald Eastlake III Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt In-reply-to: Your message of "Tue, 01 Mar 2005 09:24:45 CDT." Date: Fri, 04 Mar 2005 11:03:41 +1100 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > TSIG is only used by prior agreement of the parties involved. Policies > as to what algorithms to use and what truncation to allow are all > deliberately left open. If they feel like it, the parties could not only > use asymmetric amounts of truncation but different hash algorithms in > each direction. But one would expect that in most real cases they would > use a fixed algorithm and truncation. But, since amounts of truncation > are clearly ordered and, arguably, current hash algorithms also are, I > suppose that more flexible code could be configured with a minimum hash > algorithm and a minimum number of octets of hash. If the signature is > too weak for the receiver's policy, I don't see this as different form > the signature being missing. This should be probably all be explicitly > stated in the document. Truncation introduces lots of flexability. It would be nice to constrain it or everybody will have to implement lots of knobs to achieve interoperability. In addition to we now have query bits, reply bits, whether they are absolute or minima. The relationship between query bits and reply bits. e.g. * none * reply bits == query bits. * reply bits >= query bits For example I had a client configure to use hmac-sha512-400 with a server configure to use hmac-sha512-256 both minima. The server could verify the query but client couldn't verify the response. The reason was that the server was sending hmac-sha512-256. Making the server respond with the same number bits as the the client sent allow the client to verify the response. > Truncation is trivial and most IETF security protocols provide > explicitly for things like SHA-1 truncated to 96 bits. There are people > who believe that a little truncation improves security by revealing less > information to crackers. I don't see any reason to fail to provide > truncation cababilities in TSIG. > > Thanks, > Donald > ==================================================================== > Donald E. Eastlake 3rd dee3@torque.pothole.com > 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) > Milford, MA 01757 USA Donald.Eastlake@motorola.com > > On Tue, 1 Mar 2005, Mark Andrews wrote: > > > Date: Tue, 01 Mar 2005 16:08:36 +1100 > > From: Mark Andrews > > To: namedroppers@ops.ietf.org > > Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt > > > > > > HMAC Truncation. > > > > Looking at this there is nothing to say whether a reply > > has to use the same number of bits as the query? > > > > i.e. > > Can a server respond to a truncated HMAC-SHA1 w/ > > a full HMAC-SHA1? > > > > If you are rejecting a TSIG because the number of bits is > > too small what is the RCODE in the TSIG? BADAUTH+???? > > > > Is the server supposed to auto adjust to the client within > > limits (max(80 bits, half digest bits)) or is the server > > supposed to specify a absolute number of expected bits or > > a minimum number of expected bits. > > > > How does a server, if it rejecting because of too few bits, > > signal the minimum number of bits it will accept for this > > key. > > > > Is truncation just too much of a complication? > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > > > -- > > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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 Mar 3 22:01:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15281 for ; Thu, 3 Mar 2005 22:01:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D72ys-0009uc-1j for namedroppers-data@psg.com; Fri, 04 Mar 2005 02:55:58 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D72yq-0009tt-1W for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 02:55:56 +0000 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1D72yp-0006Hl-0b for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 21:55:55 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j242trx27201 for ; Thu, 3 Mar 2005 18:55:53 -0800 Date: Thu, 3 Mar 2005 18:55:53 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 80: Conflicts and Addresses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 80: Conflicts and Addresses Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 3, 2005 Reference: Document: LLMNR-38 Comment type: E Priority: 1 Section: 4.2 Rationale/Explanation of issue: When LLMNR messages are sent over multiple protocols (IPv4 and IPv6), some interesting conflict scenarios can arise. For example: Host A supports both IPv4 and IPv6 but only sends and responds to LLMNR queries over IPv6. Host B supports IPv4 only and sends and responds to LLMNR queries only over IPv4. What happens if Host A and B configure the same name? A sender (Host C) will send an LLMNR query and will get a single response, whether the query is sent over IPv4 or IPv6. However, when it sends a query over IPv6, Host A could respond with an A RR conflicting with the A RR that Host B would respond with if the query were sent over IPv4. Since a sender only gets a single response, it never sends a query with the 'C' bit set. The responders never detect a conflict via the uniqueness verification mechanism either. Yet a conflict does exist. What can we do about this? My suggestion is that a host should only respond with resource records corresponding to protocols that it supports for use with LLMNR. So if Host A only supports LLMNR over IPv6, it should not configure an A RR, even if it has an IPv4 address. Similarly, if Host A only supports LLMNR over IPv4, it should not configure a AAAA RR. Does this make sense? -- 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 Mar 3 22:01:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15282 for ; Thu, 3 Mar 2005 22:01:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D731N-000AKN-8U for namedroppers-data@psg.com; Fri, 04 Mar 2005 02:58:33 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D731L-000AJr-2E for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 02:58:31 +0000 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1D731J-0006aI-W1 for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 21:58:30 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j242wSu27348 for ; Thu, 3 Mar 2005 18:58:28 -0800 Date: Thu, 3 Mar 2005 18:58:28 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: Proposed Resolution to Issue 78: UNIQUEness Probing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Here is a proposed resolution incorporating the changes suggested by Markku Savela. A new version incorporating these changes is available here: http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-39.txt In Section 2.1.1 change the initial text to the following: " 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode | C|TC| Z| Z| Z| Z| Z| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ID A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied from the query to the response and can be used by the sender to match responses to outstanding queries. The ID field in a query SHOULD be set to a pseudo-random value. For advice on generation of pseudo-random values, please consult [RFC1750]. QR Query/Response. A one bit field, which if set indicates that the message is an LLMNR response; if clear then the message is an LLMNR query. OPCODE A four bit field that specifies the kind of query in this message. This value is set by the originator of a query and copied into the response. This specification defines the behavior of standard queries and responses (opcode value of zero). Future specifications may define the use of other opcodes with LLMNR. LLMNR senders and responders MUST support standard queries (opcode value of zero). LLMNR queries with unsupported OPCODE values MUST be silently discarded by responders. C Conflict. When set within a request, indicates that a sender has received multiple LLMNR responses to this query. When set within an LLMNR response, it indicates that a responder considers none the resource record(s) in the answer section to be UNIQUE; if one or more of the resource records in the response is UNIQUE, then the 'C' bit is clear. LLMNR senders do not retransmit queries with the 'C' bit set. Responders MUST NOT respond to LLMNR queries with the 'C' bit set, but may start the uniqueness verification process, as described in Section 4.2." Change Section 4, 4.1 and 4.2 to the following: "4. Conflict resolution The uniqueness of a resource record depends on the nature of the name in the query and type of the query. For example it is expected that: - multiple hosts may respond to a query for an SRV type record - multiple hosts may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A or AAAA type record for a name. By default, a responder SHOULD be configured to behave as though all RRs are UNIQUE on each interface on which LLMNR is enabled (by default, the 'C' bit is clear in responses). To detect duplicate use of a name, an administrator can use a name resolution utility which employs LLMNR and lists both responses and responders. This would allow an administrator to diagnose behavior and potentially to intervene and reconfigure LLMNR responders who should not be configured to respond to the same name. 4.1. Uniqueness Verification Prior to including a UNIQUE resource record in a response, for each UNIQUE resource record in a given interface's configuration, the host MUST verify that there is no other host within the scope of LLMNR query propagation that can return a resource record for the same name, type and class on that interface. Once a responder has verified the uniqueness of a UNIQUE resource record, if it receives an LLMNR query for that resource record, with the 'C' bit clear, it MUST respond. Uniqueness verification is carried out when the host: - starts up or is rebooted - wakes from sleep (if the network interface was inactive during sleep) - is configured to respond to LLMNR queries on an interface enabled for transmission and reception of IP traffic - is configured to respond to LLMNR queries using additional UNIQUE resource records - verifies the acquisition of a new IP address and configuration on an interface To verify uniqueness, a responder MUST send an LLMNR query with the 'C' bit clear for each UNIQUE resource record, using all protocols that it supports for use with LLMNR (IPv4 and/or IPv6). If no response is received, the sender retransmits the query, as specified in Section 2.7. If a response is received with the answer section containing a resource record that is considered UNIQUE, the responder MUST NOT use the UNIQUE resource record in response to LLMNR queries received over any protocol. Periodically carrying out uniqueness verification in an attempt to detect name conflicts is not necessary, wastes network bandwidth, and may actually be detrimental. For example, if network links are joined only briefly, and are separated again before any new communication is initiated, temporary conflicts are benign and no forced reconfiguration is required. Triggering a reconfiguration in this case would not serve any useful purpose. LLMNR responders SHOULD NOT periodically attempt uniqueness verification. 4.2. Conflict Detection and Defense Hosts on disjoint network links may configure the same name for use with LLMNR. If these separate network links are later joined or bridged together, then there may be multiple hosts which are now on the same link, trying to use the same name. When multiple responders attempt to verify uniqueness simultaneously (such as during recovery from a power failure) they may erroneously conclude that no conflict exists since a responder cannot respond to a query for a resource record without first having verified its uniqueness. In order to enable ongoing detection of name conflicts, When an LLMNR sender receives multiple LLMNR responses to a query, it MUST check if the 'C' bit is clear in any of the responses. If so, the sender SHOULD send another query for the same name, type and class, this time with the 'C' bit set, with the potentially conflicting resource records included in the Additional section. Queries with the 'C' bit set are considered advisory and responders MUST verify the existence of a conflict before acting on it. A responder receiving a query with the 'C' bit set MUST NOT respond. If the query is for UNIQUE resource record(s), then the responder MUST send its own query for the same name, type and class, with the 'C' bit clear. If a response is received and one or more of the resource records included in the Answer section are UNIQUE, then a conflict has been detected. An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD log them. Upon detecting a conflict, an LLMNR responder MUST immediately stop using the conflicting UNIQUE resource record(s) in response to LLMNR queries received over IPv4 or IPv6, if the source IP address in the response, interpreted as an unsigned integer, is less than the source IP address in the uniqueness verification query. After stopping the use of a UNIQUE resource record, the responder MAY elect to configure a new name. However, since name reconfiguration may be disruptive, this is not required, and a responder may have been configured to respond to multiple names so that alternative names may already be available." Delete DEFEND_INTERVAL from Section 7. -- 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 Mar 4 03:31:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12684 for ; Fri, 4 Mar 2005 03:31:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D789L-000DIv-AL for namedroppers-data@psg.com; Fri, 04 Mar 2005 08:27:07 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D789K-000DIj-7K for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 08:27:06 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j248NUXq016470 for ; Fri, 4 Mar 2005 03:23:30 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAhNaOkG; Fri, 4 Mar 05 03:23:28 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j248PCH8000682; Fri, 4 Mar 2005 03:25:16 -0500 (EST) Date: Fri, 4 Mar 2005 03:25:12 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Validation states (was: comments on nsec3-01) In-Reply-To: <20050301165036.07BD013E3F@sa.vix.com> Message-ID: References: <20050301165036.07BD013E3F@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Let's have yet another thread. Paul writes: > i've been struggling recently to integrate sam's and marka's remarks > about the trivalued solution space for dnssec validation. for one > thing, it bears heavily on the design of DLV. for another thing, i > don't think about it the same way as they talk about it. > > by tri-valued i mean that a validator can come to three possible > conclusions: > > 1. i can prove that this answer is secure > 2. i can prove that this answer is unsecure > 3. i cannot prove anything either way > > to my way of thinking, it's a bivalued solution space, having #1 and > #3 above but no #2. the subtlety comes in at delegation points, > where #2 is important. i call upon sam weiler, who has an excellent > record for de-mystifying these topics for me, to write a short piece > explaining what #2 is and why it matters. > > (the reason being, #3 is equivilent to a DoS, and #2 is not, and > that's where ted and roy aren't meeting up.) I'm working on a longer treatise on the subject, but since Paul asked for "short"... DNSSECbis (in -intro Section 5 and -protocol Section 4.3) describes a slightly different set of states (or at least different labels). It uses "Secure", which looks like #1, and "Bogus", which is close to #3. It also defines "Insecure" and "Indeterminate", which I think are both parts of #2. There are a multitude of sub-states for each of these, especially #3, but these three (combining Insecure and Indeterminate) make a good starting point. State #2, Insecure, is for cases where data isn't Secure through some fault or lacking of the validator. Perhaps the validator doesn't have any trust anchors configured. Perhaps it does have some, but none are applicable to the zone in question. Perhaps it doesn't implement any of the algorithms used by the zone in question. But it can figure out what the deficiency is, and it knows that it has no reason to believe the data ought to be in State #1. State #3, Bogus, is for the rest of the cases, where the validator has some reason to believe the data ought to be in State #1 (a trust anchor for that zone, or a state #1 DS at the delegation point into the zone, using a known algorithm), but the validation failed for some reason. To be clear, State #2 includes intentionally unsigned zones, where the validator not having a trust anchor for those zones is a good thing. Perhaps I shouldn't call that a lacking of the validator, and maybe someone else will offer a better way to phrase the definition of state #2. Stay tuned for the longer version... -- 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 Fri Mar 4 03:32:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12759 for ; Fri, 4 Mar 2005 03:32:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D78Ct-000Dpl-Rd for namedroppers-data@psg.com; Fri, 04 Mar 2005 08:30:47 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D78Cs-000DpG-Tf for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 08:30:47 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j248RBYE016784 for ; Fri, 4 Mar 2005 03:27:11 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA2wa4WG; Fri, 4 Mar 05 03:27:08 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j248Srmv000773; Fri, 4 Mar 2005 03:28:53 -0500 (EST) Date: Fri, 4 Mar 2005 03:28:52 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Mark Andrews cc: namedroppers@ops.ietf.org Subject: Re: hash algorithm roll In-Reply-To: <200503032105.j23L5gBV005801@drugs.dv.isc.org> Message-ID: References: <200503032105.j23L5gBV005801@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 4 Mar 2005, Mark Andrews wrote: > > Perfect is the enemy of deployed. > > But when does the list of things that can't be done w/ > NSEC3 get so big that we say "this proposal is broken"? Now. But that's the wrong question. The question is: when is NSEC3 so broken that we must stop it? The answer is: when we can no longer ignore it and just use something else -- when NSEC3 starts polluting non-participating zones. So far, I haven't found any brokenness that rises to that level. -- 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 Fri Mar 4 05:26:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25241 for ; Fri, 4 Mar 2005 05:26:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D79vm-00086l-Bw for namedroppers-data@psg.com; Fri, 04 Mar 2005 10:21:14 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D79vk-00085v-6X for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 10:21:12 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id CB47A33C45; Fri, 4 Mar 2005 10:21:09 +0000 (GMT) Message-ID: <42283711.2030404@algroup.co.uk> Date: Fri, 04 Mar 2005 10:23:13 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Andrews Cc: Samuel Weiler , Alex Bligh , "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: hash algorithm roll References: <200503032105.j23L5gBV005801@drugs.dv.isc.org> In-Reply-To: <200503032105.j23L5gBV005801@drugs.dv.isc.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Andrews wrote: >>>Just out of interest, is hash-algorithm rollover that important in >>>practice? >> >>Happily, we have a requirements document for this problem >>(draft-ietf-dnsext-signed-nonexistence-requirements-01.txt). >>It does not include hash function rollover as a requirement. >> >>The more time I spend on this, the more willing I become to answer >>"no" -- I'm willing to accept not being able to roll hash functions. >>I'm even willing to accept the current document's instructions for >>what to do with NSEC3 RRs w/ unknown hashes: discard them. I don't >>think it's good engineering, but if it's sufficient for those who want >>NSEC3, it will get us NSEC3 (and hopefully signed zones) sooner while >>taking less effort, and that's a good thing. >> >>Perfect is the enemy of deployed. > > > But when does the list of things that can't be done w/ > NSEC3 get so big that we say "this proposal is broken"? Is it possible to roll hash functions in _any_ of DNSSEC? 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 Mar 4 05:31:40 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26152 for ; Fri, 4 Mar 2005 05:31:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7A3n-0009UN-5x for namedroppers-data@psg.com; Fri, 04 Mar 2005 10:29:31 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7A3l-0009U2-2i for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 10:29:29 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 1CAFBC2DA6; Fri, 4 Mar 2005 10:29:28 +0000 (GMT) Date: Fri, 04 Mar 2005 10:29:30 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: comments on nsec3-01 Message-ID: <59F33B046404EA589698D15D@[192.168.100.25]> In-Reply-To: <20050303212706.EFCF513E3F@sa.vix.com> References: <20050303212706.EFCF513E3F@sa.vix.com> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, --On 03 March 2005 21:27 +0000 Paul Vixie wrote: >> that's a reasonable requirement if by "use the new feature" you mean >> "use NSEC3 not NSEC" provided you also add "and do not deliberately >> use options that arguably make you more vulnerable" (e.g. opt-in). > > and yet, none of these takes account of what i meant by > dnssec-of-the-month. > > every time we roll the hash algo for NSEC3, the problem recurs. > > if it was just that adding NSEC3 made zones less secure while validators > were yet to upgrade, then there'd be a flag day. > > we're talking about a flag-tuesday. every tuesday from now on. is that > ok? I'm must be missing the point of what you saying, and/or there's more agreement here than people realize. I am saying that the introduction of new features in NSEC3 (which at least by specification gives non-enumerability and opt-in) should not weaken security for those who migrate from NSEC to NSEC3, but opt not want to use features the very purpose of which is to reduce security (e.g. opt-in) - i.e. if you migrate, you should have the option of being unaffected. [*] Now that INCLUDES any hash-roll algorithm that is in place within NSEC3. So, taking the hypothetical case, IF NSEC3 introduced a hash-roll algorithm that reduced security during a hash-roll, and (taking a hypothetical case which I believe to be counterfactual, but...) hash-roll is actually useful and likely to be used in more than a test environment, THEN the NSEC3 does *not* meet criteria '*' above. I think this is what you are asking by "is this OK" and, with the previous assumptions the answer is "no". This implies (in my book) we either have to a) find a non-security-weakening form of hash-roll (which Ben seems to think he has already) OR b) abandon hash-roll For reasons I've set out elsewhere, whilst (a) sounds like a fun engineering task (perhaps one already completed, perhaps not), I actually don't see the point of hash-roll at all, in which case (b) is fine. In the specific context of your question, I don't think hash roll (and I'm talking about here not 'changing the hash algorithm to one the resolver MUST support' or 'changing the salt' [**], but 'changing the algorithm to one which which the resolver MAY not support') is going to be common at all - why should it be every Tuesday? Are we not happy with "if all mandatory hash algorithms are broken, we give up and have a flag day then". I think that buys us a good 20 years rather than 7 days. [**]=for these types of roll, surely there is no issue? 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 Mar 4 05:40:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26953 for ; Fri, 4 Mar 2005 05:40:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7ACr-000BFg-RI for namedroppers-data@psg.com; Fri, 04 Mar 2005 10:38:53 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7ACo-000BFK-Ro for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 10:38:51 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id AC86AC2DA6; Fri, 4 Mar 2005 10:38:49 +0000 (GMT) Date: Fri, 04 Mar 2005 10:38:51 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Samuel Weiler , Paul Vixie Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Validation states (was: comments on nsec3-01) Message-ID: In-Reply-To: References: <20050301165036.07BD013E3F@sa.vix.com> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 04 March 2005 03:25 -0500 Samuel Weiler wrote: > [ States are: Secure, Insecure, Bogus] > Stay tuned for the longer version... Am I correct in my assumption that EACH of the states above can support both proof of existence and denial of existence. IE you can have Secure existence, insecure existence, bogus existence, and Secure denial of existence, insecure denial of existence, bogus denial of existence. If that is the case, then opt-in (at either end) gives insecure denial of existence (using your taxonomy) for a query for a non-existent name not covered by a signed interval, yes? (just so I understand the taxonomy). Are error conditions separate states from the above, or are they mapped to one of the six possibilities above (sometimes / always)? and who does the mapping (resolver or thing using resolver)? i.e. what happens if SERVFAIL is returned / injected? 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 Mar 4 05:41:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27027 for ; Fri, 4 Mar 2005 05:41:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7AD1-000BLv-Sq for namedroppers-data@psg.com; Fri, 04 Mar 2005 10:39:03 +0000 Received: from [193.0.2.43] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7ACy-000BLS-7D for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 10:39:00 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id BDF8F14AA62; Fri, 4 Mar 2005 11:38:41 +0100 (CET) Message-ID: <42283AB0.3090203@ripe.net> Date: Fri, 04 Mar 2005 11:38:40 +0100 From: "Olaf M. Kolkman" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie Cc: Mark Andrews , Samuel Weiler , Alex Bligh , namedroppers@ops.ietf.org Subject: Re: hash algorithm roll References: <200503032105.j23L5gBV005801@drugs.dv.isc.org> <42283711.2030404@algroup.co.uk> In-Reply-To: <42283711.2030404@algroup.co.uk> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Is it possible to roll hash functions in _any_ of DNSSEC? > Yes, by means of changing the key algorithm (RSAMD5->RSASHA1). Some thought has been going into how to prevent attacks during the rollover. And the rolling can be done more or less gradually (you can have a period in which two signature algorithms are used). I've tried to argue that a hash-roll in NSEC3 ends up needing a flag-date (IMHO that is prohibitive). Another question, how bad is it that we cannot change hashing algorithm? If HASHSAM is vulnarable than there is a 'timescale' attached to that vulnarability (it takes X cycles to find a collission). As long as HASHSAM data lost its relevance before X cycles of computing power can be performed you can stay in business. You make sure your signature validity intervall is short enough and you use a different salt each time you generate new sigs. ( I might be too naive here, crypto analysis is just not my field). --Olaf (namedropper) -- 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 Mar 4 05:43:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27136 for ; Fri, 4 Mar 2005 05:43:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7AFg-000BnP-5G for namedroppers-data@psg.com; Fri, 04 Mar 2005 10:41:48 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7AFe-000Bmw-2r for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 10:41:46 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5D5F533C33; Fri, 4 Mar 2005 10:41:44 +0000 (GMT) Message-ID: <42283BE4.4000702@algroup.co.uk> Date: Fri, 04 Mar 2005 10:43:48 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <20050303212706.EFCF513E3F@sa.vix.com> <59F33B046404EA589698D15D@[192.168.100.25]> In-Reply-To: <59F33B046404EA589698D15D@[192.168.100.25]> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > This implies (in my book) we either have to > a) find a non-security-weakening form of hash-roll (which Ben seems to > think he has already) OR > b) abandon hash-roll > > For reasons I've set out elsewhere, whilst (a) sounds like a fun > engineering task (perhaps one already completed, perhaps not), I actually > don't see the point of hash-roll at all, in which case (b) is fine. I agree. Just because NSEC3 has a field to specify the hash algorithm, it doesn't mean we have to be ready to update its meaning on-the-fly. 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 Mar 4 05:51:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27857 for ; Fri, 4 Mar 2005 05:51:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7ANe-000DDP-IT for namedroppers-data@psg.com; Fri, 04 Mar 2005 10:50:02 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7ANb-000DCG-V6 for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 10:50:00 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 05EEEC2DA6; Fri, 4 Mar 2005 10:49:59 +0000 (GMT) Date: Fri, 04 Mar 2005 10:50:01 +0000 From: Alex Bligh Reply-To: Alex Bligh To: "Olaf M. Kolkman" , Ben Laurie Cc: Mark Andrews , Samuel Weiler , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: hash algorithm roll Message-ID: <58B1A3DDED729CBD261CB485@[192.168.100.25]> In-Reply-To: <42283AB0.3090203@ripe.net> References: <200503032105.j23L5gBV005801@drugs.dv.isc.org> <42283711.2030404@algroup.co.uk> <42283AB0.3090203@ripe.net> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 04 March 2005 11:38 +0100 "Olaf M. Kolkman" wrote: > Yes, by means of changing the key algorithm (RSAMD5->RSASHA1). Some > thought has been going into how to prevent attacks during the rollover. > And the rolling can be done more or less gradually (you can have a period > in which two signature algorithms are used). Isn't that a different kind of roll - i.e. a roll between one algorithm the resolver MUST support and another algorithm the resolver MUST support (in modern DNSSEC). I can't see why that kind of roll would be problematic in NSEC3. What is problematic is a roll between one the resolver MUST support and one the resolver MAY NOT support. Do those exist elswhere? > Another question, how bad is it that we cannot change hashing algorithm? > If HASHSAM is vulnarable than there is a 'timescale' attached to that > vulnarability (it takes X cycles to find a collission). As long as > HASHSAM data lost its relevance before X cycles of computing power can be > performed you can stay in business. You make sure your signature validity > intervall is short enough and you use a different salt each time you > generate new sigs. ( I might be too naive here, crypto analysis is just > not my field). I don't think that works, because you just walk the hash linked list once, downloading each NSEC3 record, then analyze the data off-line. The only defense here is if the hash takes longer to crack that the data itself is useful (rather than the hash taking longer to crack than the data stays up for). May be I misunderstood the argument entirely, but noone is claiming roll between salts is hard, or (for that matter) roll between algorithms for which there is mandatory resolver support at release time. Are they? But you say: > (it takes X cycles to find a collission) I don't think it's collisions we are worried about, is it? I think it's inversions. (i.e. being able to determine x from H(x) ). If two RR's hash to the same value ( H(x) = H(y) where x,y are in the zone file), this can be sorted at signing time. If an existing RR happens to have the same hash as a QNAME for a non-existing RR ( H(x) = H(q) where x is in the zone file, and q is not, but is queried for), we can use the "return identity hashed version" trick, and they discover one name. If *this* is the attack you are worried about, then I agree, it will take them so many cycles to find these hash collisions, that they have no chance of getting a substantial proportion of the zone file that way. 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 Mar 4 05:53:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28047 for ; Fri, 4 Mar 2005 05:53:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7APy-000DoE-Qm for namedroppers-data@psg.com; Fri, 04 Mar 2005 10:52:26 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7APp-000DlU-Iy for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 10:52:17 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id B60A533C6B; Fri, 4 Mar 2005 10:52:15 +0000 (GMT) Message-ID: <42283E5B.9000300@algroup.co.uk> Date: Fri, 04 Mar 2005 10:54:19 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" Cc: Mark Andrews , Samuel Weiler , Alex Bligh , namedroppers@ops.ietf.org Subject: Re: hash algorithm roll References: <200503032105.j23L5gBV005801@drugs.dv.isc.org> <42283711.2030404@algroup.co.uk> <42283AB0.3090203@ripe.net> In-Reply-To: <42283AB0.3090203@ripe.net> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: > >> >> Is it possible to roll hash functions in _any_ of DNSSEC? >> > > Yes, by means of changing the key algorithm (RSAMD5->RSASHA1). Some > thought has been going into how to prevent attacks during the rollover. > And the rolling can be done more or less gradually (you can have a > period in which two signature algorithms are used). > > I've tried to argue that a hash-roll in NSEC3 ends up needing a > flag-date (IMHO that is prohibitive). I'd argue that you only need to roll NSEC3's hash if you roll the hash for signing. > Another question, how bad is it that we cannot change hashing > algorithm? If HASHSAM is vulnarable than there is a 'timescale' > attached to that vulnarability (it takes X cycles to find a > collission). As long as HASHSAM data lost its relevance before X cycles > of computing power can be performed you can stay in business. You make > sure your signature validity intervall is short enough and you use a > different salt each time you generate new sigs. ( I might be too naive > here, crypto analysis is just not my field). Well, we've also discussed at length how bad it is being able to find collisions, and the answer seems to be "not very bad" (though it is obviously undesirable). The other way a hash might be broken is to allow preimages to be found (i.e. reversing the hash) - the impact of this is that domain names are revealed, not that proof-of-nonexistence stops working. This is bad from the POV of people who want domain names not to be revealed, but not bad from the POV of whether the zone remains secure. So, in short, I would _strongly_ argue that hash-rolling for NSEC3 is a red herring - if it is ever needed, then it can be rolled at the same time as the signature algorithm is rolled. 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 Mar 4 05:55:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28204 for ; Fri, 4 Mar 2005 05:55:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7ARY-000EKg-Ke for namedroppers-data@psg.com; Fri, 04 Mar 2005 10:54:04 +0000 Received: from [193.0.2.43] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7ARX-000EKL-Ks for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 10:54:03 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id C575F14AA7C; Fri, 4 Mar 2005 11:53:45 +0100 (CET) Message-ID: <42283E38.8000907@ripe.net> Date: Fri, 04 Mar 2005 11:53:44 +0100 From: "Olaf M. Kolkman" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie Cc: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <20050303212706.EFCF513E3F@sa.vix.com> <59F33B046404EA589698D15D@[192.168.100.25]> <42283BE4.4000702@algroup.co.uk> In-Reply-To: <42283BE4.4000702@algroup.co.uk> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > I agree. Just because NSEC3 has a field to specify the hash algorithm, > it doesn't mean we have to be ready to update its meaning on-the-fly. > But we do have to specify what applications do if they see that field having a value that they do not understand and we have to understand what happens if the applications receive such packets. The problem in this case is that if the vallue of the hash field is critical in the verification of the answer. And if the field is unknown the NSEC3 cannot be reliably coupled to the original QNAME. --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 Fri Mar 4 05:57:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28426 for ; Fri, 4 Mar 2005 05:57:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7ATG-000Eol-VF for namedroppers-data@psg.com; Fri, 04 Mar 2005 10:55:50 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7ATD-000Eo1-Dy for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 10:55:48 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id A5ECF33C45; Fri, 4 Mar 2005 10:55:45 +0000 (GMT) Message-ID: <42283F2D.2020108@algroup.co.uk> Date: Fri, 04 Mar 2005 10:57:49 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis Cc: DNSEXT WG Subject: Re: Proof of nonexistence for NSEC3 References: <42272AA8.3010403@algroup.co.uk> <42274417.4070504@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 17:06 +0000 3/3/05, Ben Laurie wrote: > >> You mean we should change "wildcard label" to "asterisk label"? > > > Yeah. > >> Sure. Perhaps I should change the wording to "an RR must be shown for the >> _alleged_ closest encloser" to make it clear? > > > That wording is also unclear. (What RR? A TXT record?) The response > message needs to demonstrate to the validator/evaluator what the closest > encloser is. > >>> There is no x...in the tree. I guess you mean that x is the most >>> significant label in the sought name that does not match one in the >>> tree? >> >> >> Yes - as I said "x is the lebel immediately preceding the closest >> encloser". > > > Still confused. "Preceding" from the root to the closest encloser? Or > the label at which the match failed? The label at which the match failed (surely this is obvious from the general form P.x.C?). >> This is almost my point precisely (up to now, people have thought you >> had to >> prove every possible encloser separately), except that C is in the >> tree and >> x.C isn't. > > Once we understood the concept of the closest encloser, it became > apparent that the higher (in the tree) enclosers are unimportant. > 'Course, this assumes the tree structure is apparent. Or lower, depending which way up you draw your trees ;-) >> No, if the x.C (being one longer than the closest encloser) doesn't >> exist, >> then the searched named does not exist. > > Existence isn't the point. It's whether there are answers available. > You don't set a return code of name error when the answer is synthesized. Point taken. >> And that is why you show the nonexistence of *.C. > > ... > >> I mean that to prove the existence of C any RR owned by C suffices. > > > I guess the point I'm trying to make is that DNS is a client-server > protocol. It's more important to achieve the goal of information > transfer than to bury ourselves in mathematics of proofs. > > The server generates a response. The server needs to know what > statements are needed to express a certain result - such as an answer, a > synthesized answer, no data available, or no applicable domain name. > The protocol does not assign different credibilities to stock and > synthesized answers, the only reason the server indicates any difference > is to demonstrate that it has dutifully followed the algorithm in RCFC > 1034. > > The response is interpreted by the client. It is the one that "proves" > to itself the assertions in the response. It's up to the client to > decide how to do the proof - e.g., take everything at face value. A > more prudent client would be looking for statements it can use to verify > that the server followed the protocol. Not for correctness, mind you, > but to make sure that the message originated from an authoritative source. > > I'm not picking on the math in the draft. I'm picking on the tone of > the description. DNSSEC in 2065 and 2535 spent too much time trying to > get the theory right and not enough time understanding that DNS is a > client-server protocol. I.e., it's not existence that I care about, > it's whether there is an answer. OK, so are you saying that you agree that the response is sufficient, but you would prefer the way it is presented to be more client-centric? 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 Mar 4 05:57:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28444 for ; Fri, 4 Mar 2005 05:57:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7ATm-000Ew6-AR for namedroppers-data@psg.com; Fri, 04 Mar 2005 10:56:22 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7ATl-000Eva-75 for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 10:56:21 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id B40FC33C5F; Fri, 4 Mar 2005 10:56:19 +0000 (GMT) Message-ID: <42283F4F.2060408@algroup.co.uk> Date: Fri, 04 Mar 2005 10:58:23 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <20050303212706.EFCF513E3F@sa.vix.com> <59F33B046404EA589698D15D@[192.168.100.25]> <42283BE4.4000702@algroup.co.uk> <42283E38.8000907@ripe.net> In-Reply-To: <42283E38.8000907@ripe.net> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: > >> >> I agree. Just because NSEC3 has a field to specify the hash algorithm, >> it doesn't mean we have to be ready to update its meaning on-the-fly. >> > > But we do have to specify what applications do if they see that field > having a value that they do not understand and we have to understand > what happens if the applications receive such packets. > > The problem in this case is that if the vallue of the hash field is > critical in the verification of the answer. And if the field is unknown > the NSEC3 cannot be reliably coupled to the original QNAME. Correct. 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 Mar 4 06:15:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00012 for ; Fri, 4 Mar 2005 06:15:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7Aji-000IJN-NW for namedroppers-data@psg.com; Fri, 04 Mar 2005 11:12:50 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7Ajg-000IJ5-RY for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 11:12:48 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 198F5C2E00; Fri, 4 Mar 2005 11:12:48 +0000 (GMT) Date: Fri, 04 Mar 2005 11:12:50 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie , "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: comments on nsec3-01 Message-ID: <6A679EEAE758C28956119AB6@[192.168.100.25]> In-Reply-To: <42283F4F.2060408@algroup.co.uk> References: <20050303212706.EFCF513E3F@sa.vix.com> <59F33B046404EA589698D15D@[192.168.100.25]> <42283BE4.4000702@algroup.co.uk> <42283E38.8000907@ripe.net> <42283F4F.2060408@algroup.co.uk> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 04 March 2005 10:58 +0000 Ben Laurie wrote: >> But we do have to specify what applications do if they see that field >> having a value that they do not understand and we have to understand >> what happens if the applications receive such packets. >> >> The problem in this case is that if the vallue of the hash field is >> critical in the verification of the answer. And if the field is unknown >> the NSEC3 cannot be reliably coupled to the original QNAME. > > Correct. & so the answer (where there is no hash roll to non-mandatory algorithms) is that the server MUST NOT put a value in the hash algorithm field which is not that of a specified mandatory algorithm in the NSEC3 docs (as released), that the resolver MUST implement all such mandatory algorithms (if that isn't tautology), and hence that if the resolver finds a value in the algorithm field which does not map to such a mandatory algorithm, it knows the server is behaving out of protocol. According to Sam's exposition, the data is not insecure due to "some fault in the validator", it is because the server is out of protocol. So the correct interpretation here is state #3 (Bogus). That seems correct to me (given that we are not trying to support roll). 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 Mar 4 07:20:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08715 for ; Fri, 4 Mar 2005 07:20:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7Bjt-0002mK-Bm for namedroppers-data@psg.com; Fri, 04 Mar 2005 12:17:05 +0000 Received: from [193.0.2.43] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7Bjr-0002m3-EQ for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 12:17:03 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id AE5E314B02F; Fri, 4 Mar 2005 13:16:44 +0100 (CET) Message-ID: <422851AB.3080008@ripe.net> Date: Fri, 04 Mar 2005 13:16:43 +0100 From: "Olaf M. Kolkman" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh Cc: Ben Laurie , namedroppers@ops.ietf.org Subject: Re: comments on nsec3-01 References: <20050303212706.EFCF513E3F@sa.vix.com> <59F33B046404EA589698D15D@[192.168.100.25]> <42283BE4.4000702@algroup.co.uk> <42283E38.8000907@ripe.net> <42283F4F.2060408@algroup.co.uk> <6A679EEAE758C28956119AB6@[192.168.100.25]> In-Reply-To: <6A679EEAE758C28956119AB6@[192.168.100.25]> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > & so the answer (where there is no hash roll to non-mandatory algorithms) > is that the server MUST NOT put a value in the hash algorithm field which > is not that of a specified mandatory algorithm in the NSEC3 docs (as > released), that the resolver MUST implement all such mandatory algorithms > (if that isn't tautology), and hence that if the resolver finds a > value in > the algorithm field which does not map to such a mandatory algorithm, it > knows the server is behaving out of protocol. > > According to Sam's exposition, the data is not insecure due to "some > fault > in the validator", it is because the server is out of protocol. So the > correct interpretation here is state #3 (Bogus). That seems correct to me > (given that we are not trying to support roll). I agree. --Olaf (namedropper) -- 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 Mar 4 07:27:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09297 for ; Fri, 4 Mar 2005 07:27:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7Bs6-0003vv-Tt for namedroppers-data@psg.com; Fri, 04 Mar 2005 12:25:34 +0000 Received: from [193.0.2.43] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7Bs4-0003vf-NC for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 12:25:33 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id E938714B044 for ; Fri, 4 Mar 2005 13:25:14 +0100 (CET) Message-ID: <422853AA.6070201@ripe.net> Date: Fri, 04 Mar 2005 13:25:14 +0100 From: "Olaf M. Kolkman" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers Subject: [Fwd: New tool prototypes] X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------000609050706050903020506" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------000609050706050903020506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI, http://tools.ietf.org/wg/dnsext/ is the relevant link for this group. Praise Henrik :-) --Olaf --------------000609050706050903020506 Content-Type: message/rfc822; name="New tool prototypes" Content-Disposition: inline; filename="New tool prototypes" Return-Path: Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j24CBlet025899; Fri, 4 Mar 2005 13:11:47 +0100 Received: by postman.ripe.net (Postfix, from userid 8) id C1ABE246B0; Fri, 4 Mar 2005 13:11:47 +0100 (CET) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by postman.ripe.net (Postfix) with ESMTP id A10A9246A1; Fri, 4 Mar 2005 13:11:43 +0100 (CET) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Bc8-0001YB-Jd; Fri, 04 Mar 2005 07:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Bc7-0001Xt-EB; Fri, 04 Mar 2005 07:09:03 -0500 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 HAA07662; Fri, 4 Mar 2005 07:09:00 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Bdg-0000HW-4Q; Fri, 04 Mar 2005 07:10:40 -0500 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j24C75kS003565; Fri, 4 Mar 2005 13:09:01 +0100 (MET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Mar 2005 13:09:33 +0100 Received: from [147.214.237.81] ([147.214.237.81]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Mar 2005 13:09:32 +0100 Message-ID: <42284FBF.1010806@levkowetz.com> Date: Fri, 04 Mar 2005 13:08:31 +0100 From: Henrik Levkowetz User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-announce@ietf.org, WG Chairs Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 04 Mar 2005 12:09:32.0985 (UTC) FILETIME=[067A7290:01C520B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: New tool prototypes X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working Group Chairs List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: wgchairs-bounces@ietf.org Errors-To: wgchairs-bounces@ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Tests: BAYES_05 X-RIPE-Spam-Status: N 0.173523 / -0.4 X-RIPE-Signature: 5eafa0e8817c9ce8aeb586e4f009b9a1 Content-Transfer-Encoding: 7bit Two prototypes of new tools for the IETF community are now available from the Tools-team website, http://tools.ietf.org/ : 1. Workgroup agenda pages with embedded html links to all drafts and URLs referred to in the agendas: http://tools.ietf.org/agenda/62/ 2. Workgroup status pages showing the current status of the drafts belonging to a workgroup: http://tools.ietf.org/wg/ There are links from the html-ized agenda page to both the html-ized WG agendas and to the WG status pages, and links from the WG status pages to the WG agendas. As these are prototypes, they are not expected to be perfect or complete, but they are expected to be useful to the community as-is, and comments on functionality, missing features and bugs are welcome! Comments will be taken as input to specification of full-fledged versions of similar tools, and may also be fed back into the prototypes. Henrik --------------000609050706050903020506-- -- 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 Mar 4 09:15:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21183 for ; Fri, 4 Mar 2005 09:15:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7DWb-000NmM-LC for namedroppers-data@psg.com; Fri, 04 Mar 2005 14:11:29 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7DWR-000Nlp-2G for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 14:11:19 +0000 Received: from [10.31.32.197] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j24EA7I4001848; Fri, 4 Mar 2005 09:10:08 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <42283F2D.2020108@algroup.co.uk> References: <42272AA8.3010403@algroup.co.uk> <42274417.4070504@algroup.co.uk> <42283F2D.2020108@algroup.co.uk> Date: Fri, 4 Mar 2005 09:10:10 -0500 To: Ben Laurie From: Edward Lewis Subject: Re: Proof of nonexistence for NSEC3 Cc: Edward Lewis , DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:57 +0000 3/4/05, Ben Laurie wrote: >The label at which the match failed (surely this is obvious from the general >form P.x.C?). Part of the comment is that, no, it wasn't obvious. It took me quite a few readings to get a grip on it. The P.x.C form is rather alien - the notion that there's a 'P' hanging off an 'x' that doesn't exist. >Or lower, depending which way up you draw your trees ;-) Per RFC 1034, section 3.1: "The domain name of a node is the list of the labels on the path from the node to the root of the tree. By convention, the labels that compose a domain name are printed or read left to right, from the most specific (lowest, farthest from the root) to the least specific (highest, closest to the root)." I've taken that to be "how DNS draws the tree." It's also where I got the most/least specific terminology I used in wcard. >OK, so are you saying that you agree that the response is sufficient, but you >would prefer the way it is presented to be more client-centric? Well, my comments were in response to the mail, I haven't made it through what's in the draft. What I am encouraging is to take the mathematical lingo you are using and try to force it into the context of a client-server protocol, and in particular, using the verbiage built up in years of DNS documents. The first step helps hammer out where wrinkles will need ironing, makes you think of the impacts at authoritative servers and caches, the impact of dynamic update, etc., the basic "corner cases." The latter - using consistent terminology - makes it easier to get a quality review. (Nothing of substance, more of a lecture I'm afraid.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 4 10:20:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27860 for ; Fri, 4 Mar 2005 10:20:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7EYd-0002df-5a for namedroppers-data@psg.com; Fri, 04 Mar 2005 15:17:39 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7EYY-0002dE-Ic for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 15:17:35 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j24FHSVd002191 for ; Fri, 4 Mar 2005 10:17:28 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j24FHS4K002190 for namedroppers@ops.ietf.org; Fri, 4 Mar 2005 10:17:28 -0500 (EST) (envelope-from namedroppers) Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6x9y-0001N0-Mn for namedroppers@ops.ietf.org; Thu, 03 Mar 2005 20:43:02 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j23Kh2Yf006734 for ; Thu, 3 Mar 2005 12:43:02 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 3 Mar 2005 12:43:02 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD370381A6@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "'namedroppers@ops.ietf.org'" Subject: RE: Weird Wildcards Work item (on wildcards vs RR types, was Fau x wildcards) Date: Thu, 3 Mar 2005 12:43:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C52031.7ADA4526" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C52031.7ADA4526 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some folk could not read the pdf through a non-adobe reader. Here it is in HTML. > -----Original Message----- > From: Hallam-Baker, Phillip=20 > Sent: Thursday, March 03, 2005 2:05 PM > To: 'David Blacka'; namedroppers@ops.ietf.org > Subject: RE: Weird Wildcards Work item (on wildcards vs RR=20 > types, was Faux wildcards) >=20 >=20 > It might simplify the second issue somewhat if people=20 > consider why people want wildcard SRV. They want to express=20 > policy statements such as 'every email whose source DNS zone=20 > matches the lexical expression *.verisign.com is signed'.=20 >=20 >=20 > Having considered this problem at some length for a non-IETF=20 > WG I think that there is a mechanism that would allow us to=20 > achieve the same effect as an SRV wildcard without the need=20 > to mess arround with DNS. >=20 > The basic idea is to introduce a pointer record that does not=20 > require a prefix and hence works with the existing wildcard=20 > scheme. We then define a lookup algorithm that says 'first=20 > look for the prefixed SRV, if that is not found look for the=20 > pointer, if that exists follow it and look for the prefixed=20 > SRV there, otherwise return not found'. The algorithm=20 > terminates with a maxium of three lookups. >=20 > The introduction of a 'weird wildcard' that provides the=20 > expected semantics of * to administrator is also useful, this=20 > can be achieved by means of macro-preprocessing if necessary. >=20 >=20 > The attached file provides additional info and considers the=20 > alternative options. >=20 > With respect to the Area Directors comments on the subject of=20 > 'instant gratification' in the W3C call, yes I do want=20 > instant gratification and I see no reason to have to=20 > appologise for doing so. I am dealling with a problem of=20 > Internet crime that is currently costing $500 million a year=20 > and is likely to rise to $5 billion. I believe that the=20 > architecture that I have proposed is just as well founded and=20 > considerably better justified than alternatives that=20 > introduce significant delays and deployment risk. >=20 >=20 > This morning a major bank in Indonesia turned off their=20 > online banking service.=20 >=20 > https://www.bankbii.com/information.asp >=20 >=20 > I am entirely willing to accept an alternative proposal that=20 > also achieves instant gratification. A proposal that does not=20 > provide instant gratification does not meet my needs. >=20 > > -----Original Message----- > > From: owner-namedroppers@ops.ietf.org > > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of David Blacka > > Sent: Friday, January 21, 2005 12:12 PM > > To: namedroppers@ops.ietf.org > > Subject: Re: Weird Wildcards Work item (on wildcards vs RR=20 > > types, was Faux wildcards) > >=20 > >=20 > > =D3lafur Gudmundsson/DNSEXT co-chair wrote: > > >=20 > > > There seems to be in some peoples mind a "need" for > > mechanism to do a > > > wild-card "like" thing. > > >=20 > > > Without having clear requirements and usage examples it is hard = to > > > judge > > > what > > > is wanted by the different people that have posted on the "Faux=20 > > > wildcards" and > > > "wildcards vs RR types" topic. On the other hand we think=20 > > that, given > > > that we > > > have been going in circles, continuing on list will not > > lead us anywhere. > >=20 > > While I'm not personally invested in a new wildcard > > mechanism, I would like to attempt to contribute to the=20 > > discussion of what the issues are at the risk of restating=20 > > the obvious. > >=20 > > It seems to me that when non-experts look at wildcards they > > come to one of two conclusions: > >=20 > > 1. Wildcards don't match enough. > >=20 > > 2. Wildcards match too much. > >=20 > >=20 > > Don't match enough: > >=20 > > My experience has generally shown that when a naive user is > > introduced to wildcards, they generally expect the wildcards=20 > > to apply in more situations than they actually do, leading to=20 > > long-standing common errors (c.f. RFC 1034, section 4.3.3). =20 > > The classic wildcard MX: > >=20 > > $ORIGIN example.com > > * IN MX 10 a > > a IN A 1.2.3.4 > > b IN A 1.2.3.5 > > mail IN MX b > >=20 > > The naive user generally expects the wildcard to match=20 > > MX> (which it will), (which it won't), and > > possibly even , but not . > >=20 > > That is, a possibly more natural interpretation of the=20 > wildcard is one > > of: this is the default MX record for the zone, use it when > > no other MX in the zone applies. > >=20 > >=20 > > Match too much: > >=20 > > This typically comes up when folks struggle with wildcards > > interacting with DNS records that use so-called "name hacks",=20 > > like the SRV. "Why can't I have a wildcard SRV?", they ask. =20 > > Why cannot a DNS server exhibit a great deal of control over=20 > > how a wildcard matches? So we see proposals that look like: > >=20 > > _http._tcp.*.example.com. IN SRV .... > >=20 > > where the expected behavior is that > > <_http._tcp.foo.example.com, SRV> matches, but=20 > > does not, and=20 > > <_smtp._tcp.foo.example.com., SRV> certainly does not. > >=20 > > The limits of how much control this wildcard mechanism should > > have are not typically well explored by such proposals. =20 > > However, the example above might be considered a lower bound=20 > > of control. An upper bound might be to use regular=20 > > expressions as wildcard matching rules. (Not that regular=20 > > expressions represent a real upper limit -- any arbitrarily=20 > > complex language could be defined). > >=20 > > While I personally cannot think of many interesting uses for > > an expressive (say regular expression-based) selectively=20 > > matching wildcard, my gut feeling is that there would be. > >=20 > > I do not necessarily think that there is a call for multiple > > new wildcard mechanisms. The first issue (match too little)=20 > > could be handled by a zone pre-processor (by which I mean=20 > > that the desired semantics are *expressible* using current=20 > > DNS, but just verbose), and/or a single new mechanism could=20 > > encompass both behavioral issues. > >=20 > > --=20 > > David Blacka > > Sr. Engineer VeriSign Applied Research > >=20 > > -- > > to unsubscribe send a message to > > namedroppers-request@ops.ietf.org with the word 'unsubscribe'=20 > > in a single line as the message text body. > > archive: > >=20 >=20 ------_=_NextPart_000_01C52031.7ADA4526 Content-Type: application/octet-stream; name="DNS Policy Inheritance Options.htm" Content-Disposition: attachment; filename="DNS Policy Inheritance Options.htm" Content-Transfer-Encoding: quoted-printable DNS Policy Inheritance Options

DNS Policy Inheritance Options

Phillip = Hallam-Baker

Principal Scientist
VeriSign Inc.

Abstract

The problem of creating a signature policy that is automatically inherited by all sub-domains within a domain hierarchy is considered. Although the immediate application of interest is Domain Keys Identified Internet Mail the same considerations also apply to SPF/Sender ID and to any DNS based policy publication mechanism.

1. Requirements

A core requirement of Domain Keys Identified = Internet Mail (DKIIM) is the ability to inform email recipients that they should = expect all email from a particular source to carry a signature. This allows email infrastructure to automatically cause email messages that do not carry = a signature to be rejected and/or raise exceptions.

Such a policy statement may be expressed for a = given domain in the form of a DNS record. For example we might consider a statement = in a hypothetical policy language that stated =91all email from the domain = name example.com is signed using a key record that is located in the _keys.example.com hierarchy.

example.com DKIIM=A0=A0=A0=A0 signed=3Dall = key=3D_keys.example.com

This approach allows the sending policy for the = domain example.com to be specified but does not provide any information on the = signing policy for sub-domains within the example.com hierarchy. This allows an attacker to perform a downgrade attack by sending mail that purports to = come from a user account at a sub-domain such as =91admin@security.example.com=92.

A simple approach to this problem is to allow a = policy record to apply to all sub-domains where no more specific policy is declared = and require an email recipient to search for a matching DNS policy record by = iterating the DNS tree in an upwards or downwards fashion until a match is found. = This approach creates a serious efficiency problem that may allow an = attacker to perform a denial of service attack. A DNS name can contain up to 255 = characters and each level of delegation requires 2 characters. This means that an = attacker can cause a simple iterative search algorithm to perform over a hundred = name lookups by creating a name of the form security.a.a.a.a=85.example.com.

A second problem with the iterative approach is = that it does not provide sufficient guidance for cases where the DNS name cannot be resolved. When the DNS system was originally deployed every DNS name = was visible to every Internet user. Today this is no longer the case and = most enterprises employ some form of =91split DNS=92 such that the DNS names = of machines on the internal network are not externally visible. This means that it = is entirely possible for a machine to be the genuine source of a = legitimate email even though the recipient cannot resolve the DNS name specified in the = email from address. Such a machine can still receive mail by means of a = wildcard mail exchange (MX) record.

Another approach to the policy inheritance problem = would be to re-engineer the DNS system to provide explicit support for this = feature. Such a solution is practical in technical terms but is impractical from = a deployment standpoint. Any proposed policy inheritance mechanism must = have minimal impact on the legacy infrastructure and in particular should = not require =91double-ended=92 deployment of an infrastructure change where = both the sender and receiver of the data must upgrade their infrastructure in = order to take advantage of the change.

Our requirements for inheritable email signing = policy mechanism are thus:

Efficiency
The mechanism must be efficient, allowing the email signature policy corresponding to any node, whether existing or not to be obtained = within a small, bounded number of operations.

Inheritable
It must be possible to specify the email signing policy for every = sub-domain within a domain regardless of whether the node exists or not

Minimal Impact
The mechanism must have minimal operational impact and in particular = must not require extensive deployment of new infrastructure or attempt to = restrict established administration conventions such as the use of split = DNS.

Minimize Administration Errors
The mechanism should be robust when used over an extended time period. = Routine administration processes such as changing DNS server configuration = should not result in side effects that result in unexpected changes to the = interpretation of policy.

Extensible
The mechanism should allow for extension to publication of security = policies and other types of policy information for other protocols.

2. Constraints

2.1 The DNS Zone Cut

Another solution that is often proposed in the = context of the policy inheritance problem is to make use of the DNS =91zone = cut=92. The DNS is a hierarchical name space that permits (but does not require) = delegation at each level in the hierarchy.

For example the name security.example.com would = typically require queries to three separate DNS servers. The DNS =91root=92 is = first queried to discover the address of the authoritative servers for the .com domain. An = authoritative server for the .com domain is = then queried in turn to discover the authoritative server for the .example.com domain which in = this case services all sub-domains within the .example.com domain and returns the answer. The same server could also provide an authoritative response for mail.security.example.com without the need to respond with a delegation statement.

The DNS =91authoritative server=92 delegation = point is sometimes referred to as the =91zone cut=92. The zone cut may be used to create a = simple algorithm for establishing a policy inheritance. The recipient first = queries for policy data associated with the full domain name. If no policy data = is available for the full domain name the recipient queries for a policy = record associated with the apex of the zone cut.

For example if no data is found for mail.security.example.com the node example.com is examined for = a wildcard record.

The zone cut is a feature of the DNS architecture = that is visible at the administrative level but frequently opaque at the client = level. DNS is explicitly designed as an intermediated protocol in which each = network connects to the core DNS infrastructure by means of a local caching DNS = server. Many enterprises operate transparent DNS proxies which ensure that all = DNS queries are funneled through the authorized DNS connection = infrastructure either to limit the use of DNS as an unauthorized covert channel or to = prevent outbound Denial of Service attacks via the DNS protocol. The Zone cut = mechanism thus fails the requirement Minimal Impact.

The net result of the intermediated DNS = architecture is that a DNS client application cannot rely on obtaining the necessary data to determine the location of the zone cut.

A second difficulty with the use of the zone cut = is that it means that changing a DNS server configuration to add or remove a = delegation point has new and significant consequences for the semantics of the = policy records. A DNS administrator for an enterprise who delegates control = over a sub-domain to a separate server must remember to copy the default = policy. The Zone cut mechanism thus fails the requirement Minimize = Administration Errors.

2.2 Limitations of the DNS Wildcard Mechanism

The DNS specification defines a form of wildcard = mechanism but the matching rules are considerably more limited than would = generally be expected for a wildcard mechanism. A DNS wildcard may be used to = specify default records but only for DNS nodes that do not exist at = all.

For example the zone example.com might contain a = wildcard MX at the zone apex and an A record for the name pc.example.com. A query = for the MX record for the name pc.example.com returns an empty result and not = the wildcard value.

The limitations of the DNS wildcard mechanism = affect many other administrative tasks including coding records for the Sender-ID = policy mechanism. One way to overcome these limitations is to define a new = type of wildcard that provides a match if a domain exists but has no record = entry corresponding to the query. The use of the % character has been = proposed for this purpose.

Support for the % wildcard can be implemented by = means of a macro processor. For this reason this type of wildcard is sometimes = referred to as a =91macro=92 wildcard.

2.3 Limited Support for New Resource Record Types

The existing DNS infrastructure provides only a = limited degree of support for newly defined DNS Resource Record (RR) formats. = Although support for new RR types is defined in RFC 3597 this only became a = proposed standard in September 2003. A significant proportion of the deployed = DNS servers do not tolerate unknown resource records.

In particular no version of the Windows operating = system provides native support for new DNS RR types. The DNS server is closely integrated into the Active Directory subsystem and cannot be adequately substituted by third party product. Although the native DNS service = supports caching of new RR types and can even be persuaded to emit new RR data = items under certain circumstances critical features such as the ability to = survive a reboot are not supported.

Another area for serious concern is that many = embedded systems including firewalls and low cost =91cable-routers=92 include = embedded DNS servers that may not provide the necessary level of support.

Accordingly the introduction of new RR types is = not considered to currently meet the requirement Minimal = Impact.

2.4 Limitations of the Prefix Extension Mechanism

On means of overcoming the difficulties associated = with the deployment of new resource record is to use a prefix to modify the = semantics of an existing record. In this scheme Resource Record definitions are = considered to describe the syntax of the record and the semantics = are described by means of the prefix.

This mechanism was first applied in the definition = of the SRV (service) record. The prefix mechanism allows new service records = to be defined without the need for the delay that definition and deployment of a new = RR type inevitably incurs.

The main architectural limitation of the prefix = scheme is that use of wildcards results in ambiguity. A DNS wildcard cannot be = specified at a midpoint within a DNS name so it is not possible to define a = prefix of the form _prefix.*.example.com. If a wildcard is applied at the domain apex (*.example.com) it will match queries for any service prefix.

Although wildcards are implemented as a server = feature and are only exchanged on the wire in very limited circumstances in the = traditional DNS protocol this situation is changed when DNSSEC is used to sign a = zone. The DNSSEC protocols do not currently support midpoint wildcards and = although there is no reason why they could not be supported in principle the protocol = is already overdue and it is desirable to avoid further changes to the = specification if at all possible.

3. Proposal

We propose the use of the following features to = address the requirements:

  • Prefixed TXT Records to express policy information for an existing node
  • Use of the Wildcard mechanism to describe the = location where default policy information can be retrieved for non-existent = nodes.
  • Use of synthetic Wildcards to provide an = administrative convenience to describe default policy information for existing = nodes that do not have explicit policy information specified.

The retrieval algorithm for the policy = corresponding to the policy _policy for DNS = node node.example.com is as = follows:

policy, location : = String

policy =3D DNS.Lookup ( = TXT,=A0 _policy.node.example.com)

IF (policy =3D=3D NULL) = THEN

location =3D = DNS.Lookup ( ???,=A0 node.example.com)

IF (location !=3D = NULL)=A0 THEN

policy =3D DNS.Lookup = ( TXT,=A0 "_policy." + = location)

ELSE

policy =3D NULL

RETURN policy

Note that the retrieval algorithm never requires = more than three DNS lookups in any circumstance.

For example consider the following definition for = the DNS zone example.com:

*.example.com=A0=A0=A0=A0=A0=A0=A0 ???=A0=A0 = _d.example.com

%.example.com=A0=A0=A0=A0=A0=A0=A0 ???=A0=A0 = _x.example.com

a.example.com=A0=A0=A0=A0=A0=A0=A0 A=A0=A0=A0=A0 = 10.0.0.1

_dk.a.example.com=A0=A0=A0 TXT=A0=A0 = "signed=3Dall"

b.example.com=A0=A0=A0=A0=A0=A0=A0 A=A0=A0=A0=A0 = 10.0.0.2

_dk._d.example.com=A0=A0 TXT=A0=A0 = "signed=3Dunknown"

_dk._x.example.com=A0=A0 TXT=A0=A0 "signed=3Dnever"

After preprocessing the macro expression = %.example.com is removed and replaced with the entries:

a.example.com=A0=A0=A0=A0=A0=A0=A0 ???=A0=A0 = _x.example.com

b.example.com=A0=A0=A0=A0=A0=A0=A0 ???=A0=A0 = _x.example.com

Retrieving policy information for the sub-domains = a, b and c produces the following results:

a.example.com=A0=A0=A0=A0=A0=A0=A0 ???=A0=A0 = "signed=3Dall"

b.example.com=A0=A0=A0=A0=A0=A0=A0 ???=A0=A0 = "signed=3Dnever"

c.example.com=A0=A0=A0=A0=A0=A0=A0 ???=A0=A0 = "signed=3Dunknown"

Although the macro expansion causes a pointer = record to be created for the sub-domain a.example.com the explicit entry _dk.a.example.com takes priority.

Note that the indirect pointer mechanism provides = a convenient means of administering large domains where the number of = policies is much smaller than the number of machines. Each policy is specified in a separate record and pointer records are used to identify the policy = that applies to a particular machine.

This mechanism is readily extensible to a regime = where multiple policy record prefix are defined.

The main outstanding design choice is the choice = of resource record identifier to represent the pointer record ???.

References

[RFC3597] RFC 3597 Handling of Unknown DNS = Resource Record (RR) Types. A. Gustafsson. September 2003. IETF. (Status: = PROPOSED STANDARD)

------_=_NextPart_000_01C52031.7ADA4526-- -- 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 Mar 4 11:05:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01652 for ; Fri, 4 Mar 2005 11:05:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7FHG-000OKJ-4A for namedroppers-data@psg.com; Fri, 04 Mar 2005 16:03:46 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7FHE-000OBm-HE for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 16:03:44 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j24G08YY025599 for ; Fri, 4 Mar 2005 11:00:08 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAACLaW_X; Fri, 4 Mar 05 11:00:06 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j24G1qEX013361; Fri, 4 Mar 2005 11:01:52 -0500 (EST) Date: Fri, 4 Mar 2005 11:01:52 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Alex Bligh cc: namedroppers@ops.ietf.org Subject: Re: hash algorithm roll In-Reply-To: <58B1A3DDED729CBD261CB485@[192.168.100.25]> Message-ID: References: <200503032105.j23L5gBV005801@drugs.dv.isc.org> <42283711.2030404@algroup.co.uk> <42283AB0.3090203@ripe.net> <58B1A3DDED729CBD261CB485@[192.168.100.25]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 4 Mar 2005, Alex Bligh wrote: > > Yes, by means of changing the key algorithm (RSAMD5->RSASHA1). Some > > thought has been going into how to prevent attacks during the rollover. > > And the rolling can be done more or less gradually (you can have a period > > in which two signature algorithms are used). > > Isn't that a different kind of roll - i.e. a roll between one algorithm > the resolver MUST support and another algorithm the resolver MUST support > (in modern DNSSEC). > > I can't see why that kind of roll would be problematic in NSEC3. What > is problematic is a roll between one the resolver MUST support and > one the resolver MAY NOT support. Do those exist elswhere? Olaf's choice of example may have led you astray. We believe it is possible (read: safe) to roll between any algorithms, inlcuding new ones (CryptOlaf) and private ones (see -records section A.1.1 and the experiments draft), no matter the requirement level. We also believe that even for mandatory-for-resolvers-to-implement algorithms (except for ones defined now, contemporaneously with the other DNSSECbis changes, including DS and the type code roll) there will be old resolvers out there that don't implement them. > I don't think that works, because you just walk the hash linked list once, > downloading each NSEC3 record, then analyze the data off-line. The only > defense here is if the hash takes longer to crack that the data itself is > useful (rather than the hash taking longer to crack than the data stays up > for). Good analysis, and one that partially addresses Ben's point in a later message that "I'd argue that you only need to roll NSEC3's hash if you roll the hash for signing." -- The hash algorithm used as part of signing can actually be weaker than the NSEC3 one, since it doesn't need to withstand off-line attacks into the distant future. > May be I misunderstood the argument entirely, but noone is claiming > roll between salts is hard, or (for that matter) roll between algorithms > for which there is mandatory resolver support at release time. Are they? I have claimed that the NSEC3 doc fails to describe how to change salts (in fact, it says that the salt much be consistent throughout the zone, which weakly implies that a change cannot be made). I believe Ben's argument that rolling between salts is possible, but I think the document needs more explicit guidance on how to do it. http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00407.html Without having thought about it much, I also think I agree that the second item is possible -- you can roll between hash algorithms that are mandatory-to-implement when NSEC rolls off the assembly line. However, I urge caution in relying on that without signalling at the zone cut -- presumably the reason you want to roll is weakness in one of the hash algorithms. In which case, you may want to include resolver knobs to turn off an algorithm, which would then mean that "mandatory" wasn't. -- 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 Fri Mar 4 11:06:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01793 for ; Fri, 4 Mar 2005 11:06:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7FIu-0002Wt-Ex for namedroppers-data@psg.com; Fri, 04 Mar 2005 16:05:28 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7FIs-0002WE-AN for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 16:05:26 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5EB6233C33; Fri, 4 Mar 2005 16:05:24 +0000 (GMT) Message-ID: <422887C0.9030008@algroup.co.uk> Date: Fri, 04 Mar 2005 16:07:28 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis Cc: DNSEXT WG Subject: Re: Proof of nonexistence for NSEC3 References: <42272AA8.3010403@algroup.co.uk> <42274417.4070504@algroup.co.uk> <42283F2D.2020108@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 10:57 +0000 3/4/05, Ben Laurie wrote: > >> The label at which the match failed (surely this is obvious from the >> general >> form P.x.C?). > > > Part of the comment is that, no, it wasn't obvious. It took me quite a > few readings to get a grip on it. The P.x.C form is rather alien - the > notion that there's a 'P' hanging off an 'x' that doesn't exist. Better ways to express that are welcome! >> Or lower, depending which way up you draw your trees ;-) > > Per RFC 1034, section 3.1: > > "The domain name of a node is the list of the labels on the path from the > node to the root of the tree. By convention, the labels that compose a > domain name are printed or read left to right, from the most specific > (lowest, farthest from the root) to the least specific (highest, closest > to the root)." > > I've taken that to be "how DNS draws the tree." It's also where I got > the most/least specific terminology I used in wcard. Oh, then we both draw them the same way and I misunderstood your comment. >> OK, so are you saying that you agree that the response is sufficient, >> but you >> would prefer the way it is presented to be more client-centric? > > Well, my comments were in response to the mail, I haven't made it > through what's in the draft. The mail was what I intended to add to the draft. > What I am encouraging is to take the > mathematical lingo you are using and try to force it into the context of > a client-server protocol, and in particular, using the verbiage built up > in years of DNS documents. > > The first step helps hammer out where wrinkles will need ironing, makes > you think of the impacts at authoritative servers and caches, the impact > of dynamic update, etc., the basic "corner cases." The latter - using > consistent terminology - makes it easier to get a quality review. > > (Nothing of substance, more of a lecture I'm afraid.) Hmmm. Guess I'm buying you beer until I get substance then ;-) 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 Mar 4 11:30:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03720 for ; Fri, 4 Mar 2005 11:30:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7FeA-0003oU-Gk for namedroppers-data@psg.com; Fri, 04 Mar 2005 16:27:26 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7Fe8-0003oA-AW for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 16:27:24 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 44BF1C2DA6; Fri, 4 Mar 2005 16:27:23 +0000 (GMT) Date: Fri, 04 Mar 2005 16:27:25 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Samuel Weiler Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: hash algorithm roll Message-ID: <7E7F97ED3A8AC2740790939F@[192.168.100.25]> In-Reply-To: References: <200503032105.j23L5gBV005801@drugs.dv.isc.org> <42283711.2030404@algroup.co.uk> <42283AB0.3090203@ripe.net> <58B1A3DDED729CBD261CB485@[192.168.100.25]> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sam, --On 04 March 2005 11:01 -0500 Samuel Weiler wrote: >> May be I misunderstood the argument entirely, but noone is claiming >> roll between salts is hard, or (for that matter) roll between algorithms >> for which there is mandatory resolver support at release time. Are they? > > I have claimed that the NSEC3 doc fails to describe how to change > salts (in fact, it says that the salt much be consistent throughout > the zone, which weakly implies that a change cannot be made). I > believe Ben's argument that rolling between salts is possible, but I > think the document needs more explicit guidance on how to do it. > > http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00407.html > > Without having thought about it much, I also think I agree that the > second item is possible -- you can roll between hash algorithms that > are mandatory-to-implement when NSEC rolls off the assembly line. OK - understand you up to here (provided in the last line you mean NSEC3, NSEC' or whatever). > However, I urge caution in relying on that without signalling at the > zone cut -- presumably the reason you want to roll is weakness in one > of the hash algorithms. In which case, you may want to include > resolver knobs to turn off an algorithm, which would then mean that > "mandatory" wasn't. This bit I don't understand. Remember that if the NSEC3 hash is weak (in that it risks failing a preimage test, i.e. that someone may be able to deduce x from H(x) ), the effect is that the zone risks enumeration. This is not a comparable situation to signatures, where the resolver may say "Oh, that's been signed using BROKENHASH and though it says the hash is BROKENHASH(X), and thus the message is X, I know it is possible for an interloper to construct a Y such that BROKENHASH(X)=BROKENHASH(Y), so I no longer want to trust signatures with a hash generated with BROKENHASH". In the case of NSEC3, there is no advantage to the resolver in turning off a hash algorithm - it buys the resolver no extra security - the worst that happens is they get to determine that the signer of the zone may well have accidentally allowed people to enumerate it. What may well happen is the zone *signer* decides to sign no more zones with the (possibly) broken hash algorithm - he instead chooses another one (with mandatory support). My thesis is that it's only ever going to want to be a server (or rather signer) that wants to stop using a hash algorithm. For completeness (before someone else brings it up) there is one reason I can think of why a resolver MIGHT want to stop supporting an NSEC3 hash algorithm that is "mandatory-to-implement when NSEC3 rolls off the production line" - that's if it turns out there is some submarine patent on it. That's (incidentally) why I was proposing SHA-512 (truncated) be the only (serious) mandatory hash algorithm, on the basis that if it turns out the SHA family is subject to submarine patent claims, I think we can safely say we have more to worry about than NSEC3. 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 Mar 4 11:31:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03776 for ; Fri, 4 Mar 2005 11:31:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7FgL-00048Z-10 for namedroppers-data@psg.com; Fri, 04 Mar 2005 16:29:41 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7FgJ-00048M-Sd for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 16:29:40 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j24GQ4WC026898 for ; Fri, 4 Mar 2005 11:26:04 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA8yaaI0; Fri, 4 Mar 05 11:26:02 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j24GRmJS013846; Fri, 4 Mar 2005 11:27:48 -0500 (EST) Date: Fri, 4 Mar 2005 11:27:47 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Alex Bligh cc: namedroppers@ops.ietf.org Subject: Re: Validation states (was: comments on nsec3-01) In-Reply-To: Message-ID: References: <20050301165036.07BD013E3F@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > [ States are: Secure, Insecure, Bogus] > > Stay tuned for the longer version... > > Am I correct in my assumption that EACH of the states above can support > both proof of existence and denial of existence. > > IE you can have Secure existence, insecure existence, bogus existence, and > Secure denial of existence, insecure denial of existence, bogus denial of > existence. Generally, yes. In some sub-states of 'Bogus', it may not be possible to tell whether you're getting a claimed existence or non-existence proof, but generally, yes. > If that is the case, then opt-in (at either end) gives insecure denial > of existence (using your taxonomy) for a query for a non-existent > name not covered by a signed interval, yes? (just so I understand > the taxonomy). Yes. Normally, a resolver knows whether to expect data to be Secure on a per-zone basis -- it knows, as it enters the zone, whether all data in the zone is Insecure or whether it must do its DNSSEC magic to decide between Secure and Bogus. Opt-in changes that decision from being a per-zone thing to a per-answer thing. Opt-in allows Insecure answers (both non-existence and existence) within an otherwise Secure zone. I'm not sure what you mean by "at either end". I would prefer to avoid any case where NSEC3 does the same thing -- I want a resolver to know, when it enters an NSEC3 zone, whether it is marking the whole zone as Insecure or whether it is trying to decide between Secure and Bogus -- I don't want it deciding, in middle of a zone, between Bogus and Insecure. > Are error conditions separate states from the above, or are they mapped to > one of the six possibilities above (sometimes / always)? and who does the > mapping (resolver or thing using resolver)? i.e. what happens if SERVFAIL > is returned / injected? I'm not confident about the answer to this one -- perhaps others will step in. First pass: If you're in a zone that's supposed to be Secure, all errors map to Bogus. If you're in an Insecure zone, everything maps to Insecure. As for who does the mapping, I think that's a question for the DNSSEC API designers. -- 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 Fri Mar 4 11:42:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04438 for ; Fri, 4 Mar 2005 11:42:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7FrV-0006bR-3u for namedroppers-data@psg.com; Fri, 04 Mar 2005 16:41:13 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7FrU-0006bA-1y for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 16:41:12 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j24Gba62027623 for ; Fri, 4 Mar 2005 11:37:36 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0xaW71; Fri, 4 Mar 05 11:37:34 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j24GdJ4t014096; Fri, 4 Mar 2005 11:39:19 -0500 (EST) Date: Fri, 4 Mar 2005 11:39:18 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Alex Bligh cc: namedroppers@ops.ietf.org Subject: Re: hash algorithm roll In-Reply-To: <7E7F97ED3A8AC2740790939F@[192.168.100.25]> Message-ID: References: <200503032105.j23L5gBV005801@drugs.dv.isc.org> <42283711.2030404@algroup.co.uk> <42283AB0.3090203@ripe.net> <58B1A3DDED729CBD261CB485@[192.168.100.25]> <7E7F97ED3A8AC2740790939F@[192.168.100.25]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... you can roll between hash algorithms that are > > mandatory-to-implement when NSEC rolls off the assembly line. > > OK - understand you up to here (provided in the last line you mean > NSEC3, NSEC' or whatever). Oops. Yes, I meant NSEC3, NSEC++, etc. > > ... presumably the reason you want to roll is weakness in one of > > the hash algorithms. In which case, you may want to include > > resolver knobs to turn off an algorithm, ... > > This bit I don't understand. Remember that if the NSEC3 hash is weak > ... the effect is that the zone risks enumeration. This is not a > comparable situation to signatures, ... Thank you for patiently pointing that out -- I think you're right. -- 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 Fri Mar 4 11:44:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04514 for ; Fri, 4 Mar 2005 11:44:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7Ft3-0006s8-VG for namedroppers-data@psg.com; Fri, 04 Mar 2005 16:42:49 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7Fst-0006ql-IA for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 16:42:39 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 8C42CC2DA6; Fri, 4 Mar 2005 16:42:38 +0000 (GMT) Date: Fri, 04 Mar 2005 16:42:39 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Samuel Weiler Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Validation states (was: comments on nsec3-01) Message-ID: <73632257F2031A8E17DE0F18@[192.168.100.25]> In-Reply-To: References: <20050301165036.07BD013E3F@sa.vix.com> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sam, --On 04 March 2005 11:27 -0500 Samuel Weiler wrote: >> If that is the case, then opt-in (at either end) gives insecure denial >> of existence (using your taxonomy) for a query for a non-existent >> name not covered by a signed interval, yes? (just so I understand >> the taxonomy). > > Yes. > > Normally, a resolver knows whether to expect data to be Secure on a > per-zone basis -- it knows, as it enters the zone, whether all data in > the zone is Insecure or whether it must do its DNSSEC magic to decide > between Secure and Bogus. > > Opt-in changes that decision from being a per-zone thing to a > per-answer thing. Opt-in allows Insecure answers (both non-existence > and existence) within an otherwise Secure zone. Agree - that is indeed a complication. My argument is that as (normally) the security or otherwise of a zone (rather than a query) isn't presented externally to the resolver, it is an internal complication to the resolver only. > I'm not sure what you mean by "at either end". Me neither. Brain fart I think. Ignore. > I would prefer to avoid any case where NSEC3 does the same thing -- I > want a resolver to know, when it enters an NSEC3 zone, whether it is > marking the whole zone as Insecure or whether it is trying to decide > between Secure and Bogus -- I don't want it deciding, in middle of a > zone, between Bogus and Insecure. Sure (meaning I understand what you say). But this is a result of any proposal which includes opt-in like functionality (as NSEC3 as currently drafted does). It has nothing to do with the hash properties, verification states for unsupported hash algorithms, etc., does it? IE if one dropped support for the opt-in like functionality in NSEC3, this problem would go away for you. Similarly, if one introduced opt-in like functionality into any other NSEC variant (like the original opt-in), this problem would arise for you. So the above issue is entirely connected with the support of non-authenticated denial within otherwise secure zones, yes? And it is an "internal to resolver" issues, yes? I'm not saying these are non-issues, I am just trying to understand (a) their cause, and (b) their scope. >> Are error conditions separate states from the above, or are they mapped >> to one of the six possibilities above (sometimes / always)? and who does >> the mapping (resolver or thing using resolver)? i.e. what happens if >> SERVFAIL is returned / injected? > > I'm not confident about the answer to this one -- perhaps others will > step in. First pass: If you're in a zone that's supposed to be > Secure, all errors map to Bogus. Mmmm... that doesn't sound quite right if the effects are anything to go by. Is it then impossible for a resolver's client to distinguish between a SERVFAIL from the "real" server and a SERVFAIL injected by a man-in-the-middle, on the basis that in a secure zone "all errors map to Bogus" - if so, that seems like a rather obvious DoS vector. 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 Mar 4 12:23:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07905 for ; Fri, 4 Mar 2005 12:23:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7GTx-000ENM-1d for namedroppers-data@psg.com; Fri, 04 Mar 2005 17:20:57 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7GTn-000EGZ-DO for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 17:20:47 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j24HHCaF000361 for ; Fri, 4 Mar 2005 12:17:12 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA9iaGSa; Fri, 4 Mar 05 12:17:09 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j24HIs0J015171; Fri, 4 Mar 2005 12:18:54 -0500 (EST) Date: Fri, 4 Mar 2005 12:18:54 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Alex Bligh cc: namedroppers@ops.ietf.org Subject: Re: Validation states (was: comments on nsec3-01) In-Reply-To: <73632257F2031A8E17DE0F18@[192.168.100.25]> Message-ID: References: <20050301165036.07BD013E3F@sa.vix.com> <73632257F2031A8E17DE0F18@[192.168.100.25]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... My argument is that as (normally) the security or otherwise of a > zone (rather than a query) isn't presented externally to the > resolver, it is an internal complication to the resolver only. I really need to finish that longer rant (or just send it in its present form). I imagine, once we have a DNSSEC API and/or an ad-bit replacement, that more security information will get passed up the stack. Whether the security status of a zone, as such, is exposed, I'm not sure. I'm guessing it will be, since we're likely to expose the zone cut at which validation failed (hence a security state of the final answer's zone or its ancestor) or what trust anchor was used to validate the answer (hence an inference about the security state of all zones between that trust anchor and the answer). > > I'm not sure what you mean by "at either end". > > Me neither. Brain fart I think. Ignore. No problem. I had my own a few minutes ago, too (the need to disable NSEC3 hash algorithms in resolvers), which you were very patient in pointing out. > > I would prefer to avoid any case where NSEC3 does the same thing -- I > > want a resolver to know, when it enters an NSEC3 zone, whether it is > > marking the whole zone as Insecure or whether it is trying to decide > > between Secure and Bogus -- I don't want it deciding, in middle of a > > zone, between Bogus and Insecure. > > Sure (meaning I understand what you say). But this is a result of any > proposal which includes opt-in like functionality (as NSEC3 as currently > drafted does). It has nothing to do with the hash properties, verification > states for unsupported hash algorithms, etc., does it? IE if one dropped > support for the opt-in like functionality in NSEC3, this problem would go > away for you. Similarly, if one introduced opt-in like functionality into > any other NSEC variant (like the original opt-in), this problem would arise > for you. > > So the above issue is entirely connected with the support of > non-authenticated denial within otherwise secure zones, yes? > And it is an "internal to resolver" issues, yes? I'm not saying these > are non-issues, I am just trying to understand (a) their cause, and > (b) their scope. I was actually referring to reasons other than opt-in -- I could imagine cases (like facilitating graceful roll-over to non-mandatory hash algorithms) where one might mandate data in an NSEC3 zone being treated as Insecure even though some other data in the zone was Secure. It sounds like there's agreement on treating unknown hash algorithm NSEC3's as Bogus, not Insecure, so this concern is addressed. If we do opt-in as part of NSEC3 (which I wasn't thinking about, and I'm not generally keen on), then, yes, we will see Insecure answers in otherwise Secure/Bogus zones. That's not what I was objecting to. Perhaps this could be better stated as: I want a resolver to be able to tell definitively whether a zone (or, with opt-in, a part of a zone) is supposed to be Secure or not. That determination should not be based on what RRs it gets back in an answer UNLESS it knows to expect those RRs and they can be validated. > >> Are error conditions separate states from the above, or are they mapped > >> to one of the six possibilities above (sometimes / always)? and who does > >> the mapping (resolver or thing using resolver)? i.e. what happens if > >> SERVFAIL is returned / injected? > > > > I'm not confident about the answer to this one -- perhaps others will > > step in. First pass: If you're in a zone that's supposed to be > > Secure, all errors map to Bogus. > > Mmmm... that doesn't sound quite right if the effects are anything to go > by. Is it then impossible for a resolver's client to distinguish between a > SERVFAIL from the "real" server and a SERVFAIL injected by a > man-in-the-middle, on the basis that in a secure zone "all errors map to > Bogus" - if so, that seems like a rather obvious DoS vector. Welcome to DNSSEC. (I don't like it either.) I had a word for this, but my management sat me down and asked me to quit using it. Instead, I'll just say: More gentle failures (than SERVFAIL) should be possible, especially when we have richer interfaces (API's, AD-bit replacement) to the validation results. Another area to be explored is recovery from validation failures -- are there ways for resolvers to "try harder" to get a validatable answer? -- 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 Fri Mar 4 12:47:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11517 for ; Fri, 4 Mar 2005 12:47:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7GrB-000IpM-0J for namedroppers-data@psg.com; Fri, 04 Mar 2005 17:44:57 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7Gr7-000Ikt-Ie for namedroppers@ops.ietf.org; Fri, 04 Mar 2005 17:44:53 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id A1B63C2DA6; Fri, 4 Mar 2005 17:44:52 +0000 (GMT) Date: Fri, 04 Mar 2005 17:44:54 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Samuel Weiler Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Validation states (was: comments on nsec3-01) Message-ID: <763C8269F0D2119327074DB7@[192.168.100.25]> In-Reply-To: References: <20050301165036.07BD013E3F@sa.vix.com> <73632257F2031A8E17DE0F18@[192.168.100.25]> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sam, >> ... My argument is that as (normally) the security or otherwise of a >> zone (rather than a query) isn't presented externally to the >> resolver, it is an internal complication to the resolver only. > > I really need to finish that longer rant (or just send it in its > present form). > > I imagine, once we have a DNSSEC API and/or an ad-bit replacement, > that more security information will get passed up the stack. > Whether the security status of a zone, as such, is exposed, I'm not > sure. I'm guessing it will be, since we're likely to expose the zone > cut at which validation failed (hence a security state of the final > answer's zone or its ancestor) or what trust anchor was used to > validate the answer (hence an inference about the security state of > all zones between that trust anchor and the answer). Hmmm... OK and thus the allegation is that the API is "changed" because the API or users might otherwise assume that if the zone cut at which validation failed was "secure", an insecure result should never be given? Whilst I take this point, it seems to me (noting the "one we have a DNSSEC API" comment) that this can be handled by a "do not assume this" comment in the API document now - whether tri-state zones do or don't ever come into play. [side note: if you can indeed reliably expose the zone-cut at which validation failed, it will solve, at least for DNSSEC, the 'how do I find the zone cut' question posed here in relation to wildcard SRVs (ducks & runs)] > If we do opt-in as part of NSEC3 (which I wasn't thinking about, and > I'm not generally keen on), then, yes, we will see Insecure answers in > otherwise Secure/Bogus zones. That's not what I was objecting to. > > Perhaps this could be better stated as: I want a resolver to be able > to tell definitively whether a zone (or, with opt-in, a part of a > zone) is supposed to be Secure or not. That determination should not > be based on what RRs it gets back in an answer UNLESS it knows > to expect those RRs and they can be validated. Yes - I think we both agree, and that the above is satisfied (at least without support for hash roll to non-mandatory hashes, which neither of us now think is important). >> Mmmm... that doesn't sound quite right if the effects are anything to go >> by. Is it then impossible for a resolver's client to distinguish between >> a SERVFAIL from the "real" server and a SERVFAIL injected by a >> man-in-the-middle, on the basis that in a secure zone "all errors map to >> Bogus" - if so, that seems like a rather obvious DoS vector. > > Welcome to DNSSEC. (I don't like it either.) I had a word for this, > but my management sat me down and asked me to quit using it. Hmmm... OK. I will avoid using similar words then ( :-) ), and just say that in that case, if you consider: A) that it's possible for a man in the middle to create such a DoS by injecting a SERVFAIL B) now consider a protocol mod which allows injection by a man-in-the-middle of a packet that produces a resolver effect identical to the resolver receiving SERVFAIL (e.g. using an invalid protocol), and hence cause a similar DoS it less than tenable say (A) is unproblematic whereas (B) is problematic, given that for the interloper, (A) is rather easier to do than (B). I can't remember who it was (now) that was arguing treating unknown algorithm codes as a server error was dangerous (heh, perhaps it was me), but in view of what you say it would seem to be an erroneous view. 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 Mar 5 05:52:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02752 for ; Sat, 5 Mar 2005 05:52:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7WoM-000538-Kq for namedroppers-data@psg.com; Sat, 05 Mar 2005 10:47:06 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7WoK-0004z6-IA for namedroppers@ops.ietf.org; Sat, 05 Mar 2005 10:47:04 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5171B33C33; Sat, 5 Mar 2005 10:46:59 +0000 (GMT) Message-ID: <42298EA0.1010907@algroup.co.uk> Date: Sat, 05 Mar 2005 10:49:04 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh Cc: Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: hash algorithm roll References: <200503032105.j23L5gBV005801@drugs.dv.isc.org> <42283711.2030404@algroup.co.uk> <42283AB0.3090203@ripe.net> <58B1A3DDED729CBD261CB485@[192.168.100.25]> <7E7F97ED3A8AC2740790939F@[192.168.100.25]> In-Reply-To: <7E7F97ED3A8AC2740790939F@[192.168.100.25]> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > For completeness (before someone else brings it up) there is one reason I > can think of why a resolver MIGHT want to stop supporting an NSEC3 hash > algorithm that is "mandatory-to-implement when NSEC3 rolls off the > production line" - that's if it turns out there is some submarine patent on > it. That's (incidentally) why I was proposing SHA-512 (truncated) be the > only (serious) mandatory hash algorithm, on the basis that if it turns out > the SHA family is subject to submarine patent claims, I think we can safely > say we have more to worry about than NSEC3. Its possible that we should mandate both SHA-1 (despite recent weaknesses) and SHA-512, simply because not everyone has SHA-512 implementations yet. I am not religious on this point, however. 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 Sat Mar 5 11:54:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29138 for ; Sat, 5 Mar 2005 11:54:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7cSg-000556-Ek for namedroppers-data@psg.com; Sat, 05 Mar 2005 16:49:06 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7cSd-00054p-8d for namedroppers@ops.ietf.org; Sat, 05 Mar 2005 16:49:03 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 1D3B2C2DFD; Sat, 5 Mar 2005 16:49:02 +0000 (GMT) Date: Sat, 05 Mar 2005 16:49:02 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie Cc: Samuel Weiler , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: hash algorithm roll Message-ID: <771E55292EC3231A48E9847B@[192.168.100.25]> In-Reply-To: <42298EA0.1010907@algroup.co.uk> References: <200503032105.j23L5gBV005801@drugs.dv.isc.org> <42283711.2030404@algroup.co.uk> <42283AB0.3090203@ripe.net> <58B1A3DDED729CBD261CB485@[192.168.100.25]> <7E7F97ED3A8AC2740790939F@[192.168.100.25]> <42298EA0.1010907@algroup.co.uk> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 05 March 2005 10:49 +0000 Ben Laurie wrote: > Its possible that we should mandate both SHA-1 (despite recent > weaknesses) and SHA-512, simply because not everyone has SHA-512 > implementations yet. > > I am not religious on this point, however. But if you mandate both, everyone will have to implement SHA-512 anyway (at the resolver end). You only make life easier for the signers. 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 Mar 5 12:19:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01095 for ; Sat, 5 Mar 2005 12:19:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7cuP-000Az5-7b for namedroppers-data@psg.com; Sat, 05 Mar 2005 17:17:45 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7cuN-000Ayq-9A for namedroppers@ops.ietf.org; Sat, 05 Mar 2005 17:17:43 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 6991833C5F; Sat, 5 Mar 2005 17:17:41 +0000 (GMT) Message-ID: <4229EA32.6010304@algroup.co.uk> Date: Sat, 05 Mar 2005 17:19:46 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh Cc: Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: hash algorithm roll References: <200503032105.j23L5gBV005801@drugs.dv.isc.org> <42283711.2030404@algroup.co.uk> <42283AB0.3090203@ripe.net> <58B1A3DDED729CBD261CB485@[192.168.100.25]> <7E7F97ED3A8AC2740790939F@[192.168.100.25]> <42298EA0.1010907@algroup.co.uk> <771E55292EC3231A48E9847B@[192.168.100.25]> In-Reply-To: <771E55292EC3231A48E9847B@[192.168.100.25]> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > > > --On 05 March 2005 10:49 +0000 Ben Laurie wrote: > >> Its possible that we should mandate both SHA-1 (despite recent >> weaknesses) and SHA-512, simply because not everyone has SHA-512 >> implementations yet. >> >> I am not religious on this point, however. > > > But if you mandate both, everyone will have to implement SHA-512 anyway > (at the resolver end). You only make life easier for the signers. True. Doh. -- 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 Sat Mar 5 17:12:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21997 for ; Sat, 5 Mar 2005 17:12:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7hRa-000FB5-9A for namedroppers-data@psg.com; Sat, 05 Mar 2005 22:08:18 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7hRT-000FA6-Kt for namedroppers@ops.ietf.org; Sat, 05 Mar 2005 22:08:14 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j25M84ZU008797 for ; Sat, 5 Mar 2005 17:08:04 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j25M84FY008796 for namedroppers@ops.ietf.org; Sat, 5 Mar 2005 17:08:04 -0500 (EST) (envelope-from namedroppers) Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7a3L-000I5N-By for namedroppers@ops.ietf.org; Sat, 05 Mar 2005 14:14:47 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j25EEke3010825 for ; Sat, 5 Mar 2005 06:14:46 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 5 Mar 2005 06:14:46 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD370381CB@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: namedroppers@ops.ietf.org Subject: DNS Blackhole attack Date: Sat, 5 Mar 2005 06:13:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] This just appeared on the SANS list. Time to stop arguing and get DNSSEC deployed. Global DNS cache poisoning attack?; Update... We are currently investigating a report from several sites that indicate users being re-directed to malware sites. At this time it appears to be a DNS cache poisoning attack (not a spyware, adware, or browser hijack) and we are seeking more information. Popular domain names such as google.com, ebay.com, and weather.com are being directed to the following servers. Of course when connecting to these servers, "bad things" (tm) will happen, so don't go to them. www.7sir7.com (217.160.169.87) 123xxl.com (217.160.169.87, 207.44.240.79, 216.127.88.131) abx4.com (217.160.169.87, 207.44.240.79, 216.127.88.131) If your site has been affected, please submit the following information: 1. When the attack was first noticed and whether it is still occurring. 2. What DNS server software you having facing the Internet. This information will be kept in strictest confidence. 3. If you identified any other sites that users were being re-directed to (besides the ones listed above). Updates will be made to this diary as we find out more information. Update at 23:40 UTC There appear to be two issues at hand. The first is the DNS cache poisoning. At this time, it appears to be affecting Symantec firewalls with DNS caching. If you recall, there was a vulnerability back in July that made these products very succeptable to DNS cache poisoning. Some victims have responded that they applied the patch, but were still affected. So this could be a different vulnerability or the patch didn't work properly. Maybe someone at Symantec could enlighten us? http://securityresponse.symantec.com/avcenter/security/Content/2004.06.21.ht ml The second issue is the ABX toolbar spyware that gets loaded onto the machine when visiting the target servers. This appears to happen using an ActiveX control. Users running Windows XP SP2 or a web browser that does not support ActiveX will probably not get hit with the spyware if they visit the server. Unfortunately, information on the ABX toolbar spyware is very limited at this time and it doesn't seem to be detected yet by the normal toolset of spyware/antivirus tools. In the meantime, we have been working to get the IP addresses and DNS servers supporting this attack shutdown. Some of the IP addresses are already blackholed. [eof] -- 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 Mar 5 23:31:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14411 for ; Sat, 5 Mar 2005 23:31:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7nMa-000BoL-FN for namedroppers-data@psg.com; Sun, 06 Mar 2005 04:27:32 +0000 Received: from [204.127.202.56] (helo=sccrmhc12.comcast.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7nMY-000Bnv-1y for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 04:27:30 +0000 Received: from pothole.dnsalias.com ([24.62.71.160]) by comcast.net (sccrmhc12) with ESMTP id <20050306042728012001lntme>; Sun, 6 Mar 2005 04:27:29 +0000 Received: by pothole.dnsalias.com (Postfix, from userid 1026) id 4F45494EB5; Sat, 5 Mar 2005 23:27:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by pothole.dnsalias.com (Postfix) with ESMTP id 2106E94EAF; Sat, 5 Mar 2005 23:27:28 -0500 (EST) Date: Sat, 5 Mar 2005 23:27:27 -0500 (EST) From: Donald Eastlake III X-X-Sender: donaldeastlakeiii@mini.pothole.com To: Mark Andrews Cc: Donald Eastlake III , namedroppers@ops.ietf.org Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt In-Reply-To: <200503040003.j2403fCP019008@drugs.dv.isc.org> Message-ID: References: <200503040003.j2403fCP019008@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark, I just don't see that there is likely to be much problem in actual practice. What are plausible relationships between parties using TSIG? If they are under common administration, they will have been zapped to have compatible policies. If it is a less capable client buying service from a server, the client had better sign its queries in a way acceptable to the server and accept whatever the server sends back or it won't get any service. Only if there are indpendently administered peers using TSIG is there much possibility of a problem. And even then, the symptom will be immediately failure, which should motivate people to get it fixed pretty quick. I suppose it would be plausible to force an ordering of truction where longer signatures are always considered stronger. This is, you could have a rule that policies that would accept a signature with algorithm A truncated to T octets MUST also accept longer signatures. Getting somewhat flakier, you could, as a second rule, say that servers receiving a query and verifying a signature on that query truncated to T octets MUST reply with a signature having at least T octets. I certainly wouldn't go any further than these two rules and I'd be interested in the opinion of others as to whether such rules would be desireable. Thanks, Donald ==================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Fri, 4 Mar 2005, Mark Andrews wrote: > Date: Fri, 04 Mar 2005 11:03:41 +1100 > From: Mark Andrews > To: Donald Eastlake III > Cc: namedroppers@ops.ietf.org > Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt > >> TSIG is only used by prior agreement of the parties involved. Policies >> as to what algorithms to use and what truncation to allow are all >> deliberately left open. If they feel like it, the parties could not only >> use asymmetric amounts of truncation but different hash algorithms in >> each direction. But one would expect that in most real cases they would >> use a fixed algorithm and truncation. But, since amounts of truncation >> are clearly ordered and, arguably, current hash algorithms also are, I >> suppose that more flexible code could be configured with a minimum hash >> algorithm and a minimum number of octets of hash. If the signature is >> too weak for the receiver's policy, I don't see this as different form >> the signature being missing. This should be probably all be explicitly >> stated in the document. > > Truncation introduces lots of flexability. It would be > nice to constrain it or everybody will have to implement > lots of knobs to achieve interoperability. > > In addition to we now have query bits, > reply bits, whether they are absolute or minima. The > relationship between query bits and reply bits. > e.g. > * none > * reply bits == query bits. > * reply bits >= query bits > > For example I had a client configure to use hmac-sha512-400 > with a server configure to use hmac-sha512-256 both minima. > The server could verify the query but client couldn't verify > the response. The reason was that the server was sending > hmac-sha512-256. Making the server respond with the same > number bits as the the client sent allow the client to > verify the response. > >> Truncation is trivial and most IETF security protocols provide >> explicitly for things like SHA-1 truncated to 96 bits. There are people >> who believe that a little truncation improves security by revealing less >> information to crackers. I don't see any reason to fail to provide >> truncation cababilities in TSIG. >> >> Thanks, >> Donald >> ==================================================================== >> Donald E. Eastlake 3rd dee3@torque.pothole.com >> 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) >> Milford, MA 01757 USA Donald.Eastlake@motorola.com >> >> On Tue, 1 Mar 2005, Mark Andrews wrote: >> >>> Date: Tue, 01 Mar 2005 16:08:36 +1100 >>> From: Mark Andrews >>> To: namedroppers@ops.ietf.org >>> Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt >>> >>> >>> HMAC Truncation. >>> >>> Looking at this there is nothing to say whether a reply >>> has to use the same number of bits as the query? >>> >>> i.e. >>> Can a server respond to a truncated HMAC-SHA1 w/ >>> a full HMAC-SHA1? >>> >>> If you are rejecting a TSIG because the number of bits is >>> too small what is the RCODE in the TSIG? BADAUTH+???? >>> >>> Is the server supposed to auto adjust to the client within >>> limits (max(80 bits, half digest bits)) or is the server >>> supposed to specify a absolute number of expected bits or >>> a minimum number of expected bits. >>> >>> How does a server, if it rejecting because of too few bits, >>> signal the minimum number of bits it will accept for this >>> key. >>> >>> Is truncation just too much of a complication? >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org >>> >>> -- >>> 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: > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > -- 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 Mar 6 00:05:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16344 for ; Sun, 6 Mar 2005 00:05:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7nvJ-000FMH-70 for namedroppers-data@psg.com; Sun, 06 Mar 2005 05:03:25 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1D7nvG-000FLn-6F for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 05:03:22 +0000 Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j2653Kih029416 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 6 Mar 2005 00:03:21 -0500 Date: Sun, 6 Mar 2005 00:03:20 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack In-Reply-To: <198A730C2044DE4A96749D13E167AD370381CB@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 5 Mar 2005, Hallam-Baker, Phillip wrote: > This just appeared on the SANS list. Time to stop arguing and get DNSSEC > deployed. I've not been testing DNSSEC, but I understand it requires TCP. So, DNSSEC cannot be deployed on root servers, due to large number of root servers using anycast, and anycast conflict with the DNSSEC's TCP requirements. (Anycast only works on UDP single packet per transaction protocols. ISC mistakenly told root operators that anycast can be deployed with TCP.) So, DNSSEC probably won't be very effective at preventing cache poisoning attacks. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- 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 Mar 6 00:23:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17369 for ; Sun, 6 Mar 2005 00:23:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7oDF-000H80-J7 for namedroppers-data@psg.com; Sun, 06 Mar 2005 05:21:57 +0000 Received: from [200.160.2.4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7oDE-000H7n-Jy for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 05:21:56 +0000 Received: from localhost (localhost.registro.br [127.0.0.1]) by clone.registro.br (Postfix) with ESMTP id B85902A47C for ; Sun, 6 Mar 2005 02:21:55 -0300 (BRT) Received: from clone.registro.br ([127.0.0.1]) by localhost (clone.registro.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45797-03 for ; Sun, 6 Mar 2005 02:21:55 -0300 (BRT) Received: by clone.registro.br (Postfix, from userid 1000) id 6853F2A42A; Sun, 6 Mar 2005 02:21:55 -0300 (BRT) Date: Sun, 6 Mar 2005 02:21:55 -0300 From: Frederico A C Neves To: namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack Message-ID: <20050306052155.GG45025@registro.br> References: <198A730C2044DE4A96749D13E167AD370381CB@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: amavisd-new at registro.br X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, Mar 06, 2005 at 12:03:20AM -0500, Dean Anderson wrote: > On Sat, 5 Mar 2005, Hallam-Baker, Phillip wrote: > > This just appeared on the SANS list. Time to stop arguing and get DNSSEC > > deployed. > > I've not been testing DNSSEC, but I understand it requires TCP. No it doesn't. Please read 2671 and the 3 drafts draft-ietf-dnsext-dnssec-[intro|protocol|records] on RFC Ed Queue. ... (removed conclusions based on wrong assumption). -- 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 Mar 6 00:31:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17701 for ; Sun, 6 Mar 2005 00:31:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7oJf-000HtQ-TP for namedroppers-data@psg.com; Sun, 06 Mar 2005 05:28:35 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7oJd-000Hsl-KB for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 05:28:33 +0000 Received: from [10.84.119.45] (unknown [12.104.246.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 9E49C568C0; Sat, 5 Mar 2005 21:28:32 -0800 (PST) (envelope-from david.conrad@nominum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org From: David Conrad Subject: Re: DNS Blackhole attack Date: Sat, 5 Mar 2005 21:28:31 -0800 To: Dean Anderson X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, You don't need TCP for DNSSEC (see EDNS0). There is already discussion about deploying DNSSEC on the roots (in fact, there has been for quite a while -- the root ops are very conservative in deploying new stuff (as they should be)). TCP can be used for anycast, but that's not relevant for this WG. I'll let folks from ISC speak for themselves about what they may or may not have told the root operators. Rgds, -drc On Mar 5, 2005, at 9:03 PM, Dean Anderson wrote: > On Sat, 5 Mar 2005, Hallam-Baker, Phillip wrote: >> This just appeared on the SANS list. Time to stop arguing and get >> DNSSEC >> deployed. > > I've not been testing DNSSEC, but I understand it requires TCP. So, > DNSSEC > cannot be deployed on root servers, due to large number of root servers > using anycast, and anycast conflict with the DNSSEC's TCP requirements. > (Anycast only works on UDP single packet per transaction protocols. ISC > mistakenly told root operators that anycast can be deployed with TCP.) > So, > DNSSEC probably won't be very effective at preventing cache poisoning > attacks. > > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > > > -- > 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 Sun Mar 6 01:10:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17370 for ; Sun, 6 Mar 2005 00:23:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7oD2-000H6k-UT for namedroppers-data@psg.com; Sun, 06 Mar 2005 05:21:44 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D7oD0-000H6V-EK for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 05:21:42 +0000 Received: (qmail 36328 invoked from network); 6 Mar 2005 06:03:52 -0000 Received: from yahoobb219178198104.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.104) by necom830.hpcl.titech.ac.jp with SMTP; 6 Mar 2005 06:03:52 -0000 Message-ID: <422A93A1.9050801@necom830.hpcl.titech.ac.jp> Date: Sun, 06 Mar 2005 14:22:41 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Dean Anderson CC: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dean Anderson wrote: > On Sat, 5 Mar 2005, Hallam-Baker, Phillip wrote: > >>This just appeared on the SANS list. Time to stop arguing and get DNSSEC >>deployed. > > > I've not been testing DNSSEC, but I understand it requires TCP. So, DNSSEC > cannot be deployed on root servers, due to large number of root servers > using anycast, and anycast conflict with the DNSSEC's TCP requirements. That is not a valid reason to avoid DNSSEC. Anycast does work with short-lived TCP. However, the security problem, here, is not inherent to DNS but is caused by poor implementation of it, which is why we MUST avoid DNSSEC which is a lot more complex than DNS and is assured to make its implementations poor and insecure. 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 Sun Mar 6 06:07:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27319 for ; Sun, 6 Mar 2005 06:07:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7tWQ-000PBt-8c for namedroppers-data@psg.com; Sun, 06 Mar 2005 11:02:06 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7tWN-000PBE-Lf for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 11:02:03 +0000 Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1D7tWJ-00028Q-HI; Sun, 06 Mar 2005 12:01:59 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.50) id 1D7tWJ-0001NN-1T; Sun, 06 Mar 2005 12:01:59 +0100 From: Florian Weimer To: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack References: <198A730C2044DE4A96749D13E167AD370381CB@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Sun, 06 Mar 2005 12:01:59 +0100 In-Reply-To: <198A730C2044DE4A96749D13E167AD370381CB@MOU1WNEXMB04.vcorp.ad.vrsn.com> (Phillip Hallam-Baker's message of "Sat, 5 Mar 2005 06:13:04 -0800") Message-ID: <874qfpghqw.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Phillip Hallam-Baker: > This just appeared on the SANS list. Time to stop arguing and get DNSSEC > deployed. There are at least four types of cache poisoning attacks: (1) Attacks which blindly spoof name server replies. Because of the 16 bit message ID, these attacks are always practical (especially if a constant query source port is used), even if implementations use hard-to-guess IDs. (2) Attacks which exploit weaknesses in resolver implementations which fail to discard bogus data received from authoritative name servers they have queried. (3) Attacks which exploit DNS configuration management systems which do not correctly filter some records. (4) Some ISPs have broken DNS management procedures which set up delegations for customers even though they do not receive a delegation from a parent zone for it. From what I've heard, the current round of attacks is indeed in category (2). DNSSEC does not prevent this (and it doesn't help against (3) and (4), either). One could even argue that DNSSEC's complexity will result in further vulnerabilities in the interpretation of the meaning of DNS responses. -- 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 Mar 6 09:36:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12599 for ; Sun, 6 Mar 2005 09:36:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7wny-000L7P-Rn for namedroppers-data@psg.com; Sun, 06 Mar 2005 14:32:26 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7wnw-000L5t-QC for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 14:32:25 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j26EWLKN007870; Sun, 6 Mar 2005 14:32:21 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j26EWKQe007867; Sun, 6 Mar 2005 14:32:20 GMT Date: Sun, 6 Mar 2005 14:32:20 +0000 From: bmanning@vacation.karoshi.com To: Dean Anderson Cc: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack Message-ID: <20050306143220.GC7735@vacation.karoshi.com.> References: <198A730C2044DE4A96749D13E167AD370381CB@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, Mar 06, 2005 at 12:03:20AM -0500, Dean Anderson wrote: > On Sat, 5 Mar 2005, Hallam-Baker, Phillip wrote: > > This just appeared on the SANS list. Time to stop arguing and get DNSSEC > > deployed. > > I've not been testing DNSSEC, but I understand it requires TCP. So, DNSSEC you might want to try it out to be sure of your understandings. > cannot be deployed on root servers, due to large number of root servers > using anycast, and anycast conflict with the DNSSEC's TCP requirements. > (Anycast only works on UDP single packet per transaction protocols. ISC > mistakenly told root operators that anycast can be deployed with TCP.) So, they did? guess not everyone received the msg. > DNSSEC probably won't be very effective at preventing cache poisoning > attacks. prevent... perhaps not. but it could, if used properly. > > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > > > -- > 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 Sun Mar 6 11:08:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21899 for ; Sun, 6 Mar 2005 11:08:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7yEv-000663-B9 for namedroppers-data@psg.com; Sun, 06 Mar 2005 16:04:21 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D7yEs-00065T-5J for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 16:04:18 +0000 Received: (qmail 40067 invoked from network); 6 Mar 2005 16:46:33 -0000 Received: from yahoobb219001188026.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.26) by necom830.hpcl.titech.ac.jp with SMTP; 6 Mar 2005 16:46:33 -0000 Message-ID: <422B2A3B.6030608@necom830.hpcl.titech.ac.jp> Date: Mon, 07 Mar 2005 01:05:15 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Florian Weimer CC: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack References: <198A730C2044DE4A96749D13E167AD370381CB@MOU1WNEXMB04.vcorp.ad.vrsn.com> <874qfpghqw.fsf@deneb.enyo.de> In-Reply-To: <874qfpghqw.fsf@deneb.enyo.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Florian Weimer wrote: > (2) Attacks which exploit weaknesses in resolver implementations > which fail to discard bogus data received from authoritative > name servers they have queried. Actually, attacks can exploit weaknesses in resolver implementations which fail to distinguish and to separately cache unauthoritative (delegation) data received from authoritative name servers they have queried. DNSSEC can't be helpful, unless parent zones sign glues, which causes serious management troubles. 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 Sun Mar 6 11:30:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23687 for ; Sun, 6 Mar 2005 11:30:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7ycQ-0008Zx-NU for namedroppers-data@psg.com; Sun, 06 Mar 2005 16:28:38 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7ycP-0008Zk-W5 for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 16:28:38 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A1BC0190D4 for ; Sun, 6 Mar 2005 16:28:37 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack In-Reply-To: Message from Masataka Ohta of "Mon, 07 Mar 2005 01:05:15 +0900." <422B2A3B.6030608@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 06 Mar 2005 16:28:37 +0000 Message-Id: <20050306162837.A1BC0190D4@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > (2) Attacks which exploit weaknesses in resolver implementations > > which fail to discard bogus data received from authoritative name > > servers they have queried. > > Actually, attacks can exploit weaknesses in resolver implementations > which fail to distinguish and to separately cache unauthoritative > (delegation) data received from authoritative name servers they have > queried. both of those statements are true. > DNSSEC can't be helpful, unless parent zones sign glues, which > causes serious management troubles. this statement, however, is not. -- 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 Mar 6 12:00:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26150 for ; Sun, 6 Mar 2005 12:00:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7z5D-000BZp-Gu for namedroppers-data@psg.com; Sun, 06 Mar 2005 16:58:23 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7z5B-000BZH-4F for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 16:58:21 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 658A967503 for ; Sun, 6 Mar 2005 16:58:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j26GwCW0006525; Mon, 7 Mar 2005 03:58:13 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200503061658.j26GwCW0006525@drugs.dv.isc.org> To: Donald Eastlake III Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt In-reply-to: Your message of "Sat, 05 Mar 2005 23:27:27 CDT." Date: Mon, 07 Mar 2005 03:58:12 +1100 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark, > > I just don't see that there is likely to be much problem in actual > practice. What are plausible relationships between parties using TSIG? > If they are under common administration, they will have been zapped to > have compatible policies. If it is a less capable client buying service > from a server, the client had better sign its queries in a way > acceptable to the server and accept whatever the server sends back or it > won't get any service. Only if there are indpendently administered peers > using TSIG is there much possibility of a problem. And even then, the > symptom will be immediately failure, which should motivate people to get > it fixed pretty quick. Donald you are looking at this from the wrong direction. Implementations can constain available policy. We need to ensure that a implementation that implements >= bits will interoperate with a implementation that implements exact bits. There will also be implementations that will implement both giving more policy choices for the administator. In all cases the client needs to be able to choose the initial number of bits. The server will choose to accept or reject a signature with that number of bits on the request. It then has to send a reply. We need to make sure that the reply will be accepted regardless of the implementation type. > I suppose it would be plausible to force an ordering of truction where > longer signatures are always considered stronger. This is, you could > have a rule that policies that would accept a signature with algorithm A > truncated to T octets MUST also accept longer signatures. Getting > somewhat flakier, you could, as a second rule, say that servers > receiving a query and verifying a signature on that query truncated to T > octets MUST reply with a signature having at least T octets. I certainly > wouldn't go any further than these two rules and I'd be interested in > the opinion of others as to whether such rules would be desireable. > > Thanks, > Donald > ==================================================================== > Donald E. Eastlake 3rd dee3@torque.pothole.com > 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) > Milford, MA 01757 USA Donald.Eastlake@motorola.com We could may the first a MAY. I would make the second a reply MUST use the same number of bits in the digest as the request used. This allows forces servers that implement the MAY to interoperate with clients that do not implement the MAY. In other words the client set the number of bits for the transaction which may or may not be accepted by the server's policy but will be constant for the life of the transaction. Mark > On Fri, 4 Mar 2005, Mark Andrews wrote: > > > Date: Fri, 04 Mar 2005 11:03:41 +1100 > > From: Mark Andrews > > To: Donald Eastlake III > > Cc: namedroppers@ops.ietf.org > > Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt > > > >> TSIG is only used by prior agreement of the parties involved. Policies > >> as to what algorithms to use and what truncation to allow are all > >> deliberately left open. If they feel like it, the parties could not only > >> use asymmetric amounts of truncation but different hash algorithms in > >> each direction. But one would expect that in most real cases they would > >> use a fixed algorithm and truncation. But, since amounts of truncation > >> are clearly ordered and, arguably, current hash algorithms also are, I > >> suppose that more flexible code could be configured with a minimum hash > >> algorithm and a minimum number of octets of hash. If the signature is > >> too weak for the receiver's policy, I don't see this as different form > >> the signature being missing. This should be probably all be explicitly > >> stated in the document. > > > > Truncation introduces lots of flexability. It would be > > nice to constrain it or everybody will have to implement > > lots of knobs to achieve interoperability. > > > > In addition to we now have query bits, > > reply bits, whether they are absolute or minima. The > > relationship between query bits and reply bits. > > e.g. > > * none > > * reply bits == query bits. > > * reply bits >= query bits > > > > For example I had a client configure to use hmac-sha512-400 > > with a server configure to use hmac-sha512-256 both minima. > > The server could verify the query but client couldn't verify > > the response. The reason was that the server was sending > > hmac-sha512-256. Making the server respond with the same > > number bits as the the client sent allow the client to > > verify the response. > > > >> Truncation is trivial and most IETF security protocols provide > >> explicitly for things like SHA-1 truncated to 96 bits. There are people > >> who believe that a little truncation improves security by revealing less > >> information to crackers. I don't see any reason to fail to provide > >> truncation cababilities in TSIG. > >> > >> Thanks, > >> Donald > >> ==================================================================== > >> Donald E. Eastlake 3rd dee3@torque.pothole.com > >> 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) > >> Milford, MA 01757 USA Donald.Eastlake@motorola.com > >> > >> On Tue, 1 Mar 2005, Mark Andrews wrote: > >> > >>> Date: Tue, 01 Mar 2005 16:08:36 +1100 > >>> From: Mark Andrews > >>> To: namedroppers@ops.ietf.org > >>> Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt > >>> > >>> > >>> HMAC Truncation. > >>> > >>> Looking at this there is nothing to say whether a reply > >>> has to use the same number of bits as the query? > >>> > >>> i.e. > >>> Can a server respond to a truncated HMAC-SHA1 w/ > >>> a full HMAC-SHA1? > >>> > >>> If you are rejecting a TSIG because the number of bits is > >>> too small what is the RCODE in the TSIG? BADAUTH+???? > >>> > >>> Is the server supposed to auto adjust to the client within > >>> limits (max(80 bits, half digest bits)) or is the server > >>> supposed to specify a absolute number of expected bits or > >>> a minimum number of expected bits. > >>> > >>> How does a server, if it rejecting because of too few bits, > >>> signal the minimum number of bits it will accept for this > >>> key. > >>> > >>> Is truncation just too much of a complication? > >>> -- > >>> Mark Andrews, ISC > >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >>> PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > >>> > >>> -- > >>> 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: > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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 Mar 6 13:46:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09415 for ; Sun, 6 Mar 2005 13:46:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D80iP-000MmO-HY for namedroppers-data@psg.com; Sun, 06 Mar 2005 18:42:57 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D80iN-000MmA-M7 for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 18:42:55 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 Mar 2005 11:59:36 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,139,1107734400"; d="scan'208"; a="231903407:sNHT19345296" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j26IgqZV008704; Sun, 6 Mar 2005 10:42:53 -0800 (PST) Received: from rdroms-w2k01.cisco.com (sjc-vpn5-47.cisco.com [10.21.88.47]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APP16587; Sun, 6 Mar 2005 13:42:51 -0500 (EST) Message-Id: <4.3.2.7.2.20050306134203.02a9f960@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 06 Mar 2005 13:42:44 -0500 To: Paul Vixie From: Ralph Droms Subject: Re: DNS Blackhole attack Cc: namedroppers@ops.ietf.org In-Reply-To: <20050306162837.A1BC0190D4@sa.vix.com> References: <422B2A3B.6030608@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul - which part (or all) of "DNSSEC can't be helpful, unless parent zones sign glues, which causes serious management troubles." isn't true? - Ralph At 04:28 PM 3/6/2005 +0000, Paul Vixie wrote: > > > (2) Attacks which exploit weaknesses in resolver implementations > > > which fail to discard bogus data received from authoritative name > > > servers they have queried. > > > > Actually, attacks can exploit weaknesses in resolver implementations > > which fail to distinguish and to separately cache unauthoritative > > (delegation) data received from authoritative name servers they have > > queried. > >both of those statements are true. > > > DNSSEC can't be helpful, unless parent zones sign glues, which > > causes serious management troubles. > >this statement, however, is not. > >-- >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 Sun Mar 6 14:01:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10604 for ; Sun, 6 Mar 2005 14:01:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D80xu-000OZV-MF for namedroppers-data@psg.com; Sun, 06 Mar 2005 18:58:58 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D80xt-000OZA-9F for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 18:58:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j26IwgO12051; Sun, 6 Mar 2005 20:58:42 +0200 Date: Sun, 6 Mar 2005 20:58:42 +0200 (EET) From: Pekka Savola To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack In-Reply-To: <20050306162837.A1BC0190D4@sa.vix.com> Message-ID: References: <20050306162837.A1BC0190D4@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 6 Mar 2005, Paul Vixie wrote: >>> (2) Attacks which exploit weaknesses in resolver implementations >>> which fail to discard bogus data received from authoritative name >>> servers they have queried. >> >> Actually, attacks can exploit weaknesses in resolver implementations >> which fail to distinguish and to separately cache unauthoritative >> (delegation) data received from authoritative name servers they have >> queried. > > both of those statements are true. maybe this calls for working on specifying more clearly what resolvers (and other DNS components) must and must not do? -- 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 Sun Mar 6 14:29:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13808 for ; Sun, 6 Mar 2005 14:29:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D81OB-00019j-LN for namedroppers-data@psg.com; Sun, 06 Mar 2005 19:26:07 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D81OA-00019X-U4 for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 19:26:06 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9FAFB190D4 for ; Sun, 6 Mar 2005 19:26:06 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack In-Reply-To: Message from Ralph Droms of "Sun, 06 Mar 2005 13:42:44 EST." <4.3.2.7.2.20050306134203.02a9f960@flask.cisco.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 06 Mar 2005 19:26:06 +0000 Message-Id: <20050306192606.9FAFB190D4@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Paul - which part (or all) of "DNSSEC can't be helpful, unless parent > zones sign glues, which causes serious management troubles." isn't > true? > > - Ralph all of it. in security, all you have to show for each attack is either that you handle it, or you don't handle it, or it reduces to some other attack which you either do or don't handle. the case where the glue is MIM'd reduces to the case where your packets are destroyed by loss or congestion, which is something dnssec already doesn't handle (and that i can't think of a way to handle). there's huge FUD about dnssec. i'm disappointed in ohta-san and in djb for their parts in producing and/or amplifying this FUD. dnssec is very subtle and powerfully complex (or complexly powerful?) but both of these men are very much intelligent enough to know better than they've spoken. dnssec doesn't guaranty success, it just provides new paths toward failure. -- 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 Mar 6 17:54:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05321 for ; Sun, 6 Mar 2005 17:54:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D84ZZ-000GN8-6a for namedroppers-data@psg.com; Sun, 06 Mar 2005 22:50:05 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D84ZV-000GL3-Nd for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 22:50:01 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 49120C2E03; Sun, 6 Mar 2005 22:49:58 +0000 (GMT) Date: Sun, 06 Mar 2005 22:49:58 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: DNS Blackhole attack Message-ID: <065A74B680020B2B862AD9C9@[192.168.100.25]> In-Reply-To: <20050306192606.9FAFB190D4@sa.vix.com> References: <20050306192606.9FAFB190D4@sa.vix.com> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 06 March 2005 19:26 +0000 Paul Vixie wrote: > the case where the glue is MIM'd reduces to the case where your packets > are destroyed by loss or congestion, For my education: Why does an attack which involves *introducing* a spurious glue record (in vanilla DNS) reduce (in DNSSEC) to an attack where packets are destroyed by loss or congestion (which I agree in DNSSEC is insoluble)? IE if it reduces to a common denominator, what is the (unpreventable) attack on DNSSEC which produces the same result as MIM glue insertion in vanilla DNS? My (as yet uneducated) read had been that both were susceptible to DoS (in the truest sense) attacks due to packet loss, but that while vanilla DNS could suffer from injection of false information, the worst that could happen in a DNSSEC world is that participants could be prevented from receiving updated information or notification that old information was out of date. Should I be removing my ever-decreasingly-rose-tinted specs? 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 Sun Mar 6 23:15:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03604 for ; Sun, 6 Mar 2005 23:15:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D89Yi-0001KI-PN for namedroppers-data@psg.com; Mon, 07 Mar 2005 04:09:32 +0000 Received: from [192.71.80.105] (helo=defiant.autonomica.se) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D89Yf-0001K1-M3 for namedroppers@ops.ietf.org; Mon, 07 Mar 2005 04:09:30 +0000 Received: from oban.autonomica.se (unknown [12.104.246.1]) by defiant.autonomica.se (Postfix) with ESMTP id 1ADCA12129F; Mon, 7 Mar 2005 03:01:28 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by oban.autonomica.se (Postfix) with ESMTP id 493982FB2D4; Mon, 7 Mar 2005 03:01:20 +0100 (CET) In-Reply-To: <065A74B680020B2B862AD9C9@[192.168.100.25]> References: <20050306192606.9FAFB190D4@sa.vix.com> <065A74B680020B2B862AD9C9@[192.168.100.25]> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <72438e6589c87609acf30798043c0394@autonomica.se> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: =?ISO-8859-1?Q?Johan_Ihr=E9n?= Subject: Re: DNS Blackhole attack Date: Mon, 7 Mar 2005 03:01:18 +0100 To: Alex Bligh X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mar 6, 2005, at 23:49, Alex Bligh wrote: > --On 06 March 2005 19:26 +0000 Paul Vixie wrote: > >> the case where the glue is MIM'd reduces to the case where your >> packets >> are destroyed by loss or congestion, > > For my education: Why does an attack which involves *introducing* a > spurious glue record (in vanilla DNS) reduce (in DNSSEC) to an attack > where > packets are destroyed by loss or congestion (which I agree in DNSSEC is > insoluble)? > > IE if it reduces to a common denominator, what is the (unpreventable) > attack on DNSSEC which produces the same result as MIM glue insertion > in > vanilla DNS? I think you misunderstood Paul. His point is that with DNSSEC MIM'd glue eventually results in a response that doesn't validate and hence is discarded, which is basically the same outcome as the response packet being lost in transit. What DNSSEC cannot prevent is the spoofing as such, it can only help detect when it is happening. There is no unpreventable attack on DNSSEC that will produce the same result as MIM glue insertion in vanilla DNS (i.e. forged data being accepted as valid). > My (as yet uneducated) read had been that both were susceptible to DoS > (in > the truest sense) attacks due to packet loss, but that while vanilla > DNS > could suffer from injection of false information, the worst that could > happen in a DNSSEC world is that participants could be prevented from > receiving updated information or notification that old information was > out > of date. Signed glue is a red hering. DNSSEC isn't about securing server identities, it is about securing data. As most of you know for a signed delegation the referral will contain NS RRset for the child + DS for the child + RRSIG(DS) + possibly some glue. The RRSIG(DS) enables the validator to verify whether the data from the child is authentic or not regardlesss of whether it arrived from the right servers or not. I.e. it will work just fine even if the glue is spoofed as long as the bad guy serves data that validate. For an unsigned delegation there will be no DS nor RRSIG(DS) and hence no such protection for the child. In this case the semantics and risk of spoofing fall back to be the same as for standard DNS. This is not surprising, as an unsigned delegation is a statement of the child not having requested the data protection that would come from the delegation being signed. I.e. either the child isn't DNSSEC capable or it is DNSSEC capable, but, for whatever reason, does its own trust anchor distribution. > Should I be removing my ever-decreasingly-rose-tinted specs? No. Regards, Johan -- 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 Mar 6 23:20:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03946 for ; Sun, 6 Mar 2005 23:19:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D89hL-000279-RJ for namedroppers-data@psg.com; Mon, 07 Mar 2005 04:18:27 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D89hL-00026w-3U for namedroppers@ops.ietf.org; Mon, 07 Mar 2005 04:18:27 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5AF531B1CE for ; Sun, 6 Mar 2005 23:15:56 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack In-Reply-To: Message from Alex Bligh of "Sun, 06 Mar 2005 22:49:58 GMT." <065A74B680020B2B862AD9C9@[192.168.100.25]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 06 Mar 2005 23:15:56 +0000 Message-Id: <20050306231556.5AF531B1CE@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > the case where the glue is MIM'd reduces to the case where your > > packets are destroyed by loss or congestion, > > For my education: Why does an attack which involves *introducing* a > spurious glue record (in vanilla DNS) reduce (in DNSSEC) to an attack > where packets are destroyed by loss or congestion (which I agree in > DNSSEC is insoluble)? it you contact an address which was introduced to you as an authority for some zone, and it can't answer with a key corresponding to that zone's DS in the parent zone, then you'll be throwing their answers away, which is exactly the same in dnssec terms as never having received those answers, which is exactly what would happen if they never hear your questions. -- 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 Mar 7 01:15:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14731 for ; Mon, 7 Mar 2005 01:15:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8BRr-0005q0-Tl for namedroppers-data@psg.com; Mon, 07 Mar 2005 06:10:35 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D8BRq-0005po-EH for namedroppers@ops.ietf.org; Mon, 07 Mar 2005 06:10:35 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j276AOas027588 for ; Mon, 7 Mar 2005 01:10:25 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j276AOC1027587 for namedroppers@ops.ietf.org; Mon, 7 Mar 2005 01:10:24 -0500 (EST) (envelope-from namedroppers) Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7y12-0004B8-ER for namedroppers@ops.ietf.org; Sun, 06 Mar 2005 15:50:00 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j26Fnxbn010890 for ; Sun, 6 Mar 2005 07:49:59 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 6 Mar 2005 07:49:59 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD370381D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: DNS Blackhole attack Date: Sun, 6 Mar 2005 07:49:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,TO_EMPTY autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] First we have to understand that we are dealling with a very different security problem to the one that was considered when DNSSEC was first proposed. At that time the governing paradigm was 'security perfectionism'. We are facing a rather different problem, criminal gangs with significant but finite resources. We do not need to preclude an attack absolutely, but we do need to reduce the incentive to try. In particular we want to make it such that an attacker is unlikely to believe that they will be able to recover the cost of developing an attack before it is closed. DNSSEC might be overdesigned for the current set of attacks but as a pragmatic matter it is very unlikely that it would be possible to get agreement on a simpler scheme in less time than it would take to deploy the current DNSSEC. Also the combination of four years further action of Moore's law, the use of DNS to distribute security policy information and an imminent pain point mean that deployment possibilities are now open that did not exist in 2000. To answer Florian's point, yes it looks like this particular attack is a bug exploit, not a protocol exploit, but the attack is illustrative of the type of measure being used to perform phishing type attacks. It takes us much longer to respond than it takes the attacker to switch tactics. -- 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 Mar 7 04:30:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19543 for ; Mon, 7 Mar 2005 04:30:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8EUU-0002pj-Mm for namedroppers-data@psg.com; Mon, 07 Mar 2005 09:25:30 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8EUS-0002pU-IZ for namedroppers@ops.ietf.org; Mon, 07 Mar 2005 09:25:28 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 14D6CC2DA8; Mon, 7 Mar 2005 09:25:27 +0000 (GMT) Date: Mon, 07 Mar 2005 09:25:26 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: DNS Blackhole attack Message-ID: In-Reply-To: <20050306231556.5AF531B1CE@sa.vix.com> References: <20050306231556.5AF531B1CE@sa.vix.com> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 06 March 2005 23:15 +0000 Paul Vixie wrote: > it you contact an address which was introduced to you as an authority for > some zone, and it can't answer with a key corresponding to that zone's DS > in the parent zone, then you'll be throwing their answers away, which is > exactly the same in dnssec terms as never having received those answers, > which is exactly what would happen if they never hear your questions. Yes I see what you are saying. 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 Tue Mar 8 13:34:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29249 for ; Tue, 8 Mar 2005 13:34:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8jSX-000NE1-L9 for namedroppers-data@psg.com; Tue, 08 Mar 2005 18:29:33 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D8jSM-000NDK-Sa for namedroppers@ops.ietf.org; Tue, 08 Mar 2005 18:29:23 +0000 Received: from [IPv6???1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 1EBA533C45 for ; Tue, 8 Mar 2005 18:29:19 +0000 (GMT) Message-ID: <422DE0DA.3000504@algroup.co.uk> Date: Tue, 08 Mar 2005 17:28:58 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: DNSEXT WG Subject: Revised NSEC3 proof of nonexistence text X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In response to Ed's lecture, here's my second attempt: In order to prove there are no wildcards for a domain, as well as no RRs that match directly, an RR must be shown for the closest encloser, and non-existence must be shown for all enclosers that could be closer, and for the wildcard at the closest encloser. This can be done as follows. If the QNAME in the query is p1.p2...pn.c1.c2...cm (the reason for this notation will become apparent) and the closest encloser is c1.c2...cm (note that p1.p2...pn might, in practice, be a single label, but must be at least one label long, since otherwise the QNAME would exist), then the server should return an NSEC3 that demonstrates the nonexistence of pn.c1.c2...cm, and NSEC3 that demonstrates the nonexistence of *.c1.c2...cm, and any RR that demonstrates the existence of c1.c2...cm (if c1.c2...cm is an empty non-terminal, then this will also have to be an NSEC3). When a verifier checks this response, then the existence of c1.c2...cm together with the non-existence of pn.c1.c2...cm proves to it that the closest encloser is indeed c1.c2...cm (which, of course, also proves that p1.p2...pn.c1.c2...cm does not exist). The non-existence of *.c1.c2...cm shows that there is no wildcard at the closest encloser, and so no source of synthesis for p1.p2...pn.c1.c2...cm. These two facts are sufficient to satisfy the resolver that the QNAME cannot be resolved. In practice, since the NSEC3 owner and next names are hashed, if the server responds with an NSEC3 for c1.c2...cm, the resolver will have to try successively longer names, starting with cm, moving to cm-1.cm, cm-2.cm-1.cm, and so on, until one of them hashes to a value enclosed by one of the returned NSEC3s. Once it has done this, it knows the closest encloser (i.e. c1.c2...cm), and can then easily check the other two required proofs. Note that it is not possible for one of the shorter names tried by the resolver to be denied by one of the returned NSEC3s, since, by definition, all these names exist and so cannot appear within the range covered by an NSEC3. Note, however, that the first name that the resolver tries MUST be the apex of the zone, since names above the apex could be denied by one of the returned NSEC3s. -- 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 Mar 8 14:05:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02582 for ; Tue, 8 Mar 2005 14:05:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8jyi-0000f2-V5 for namedroppers-data@psg.com; Tue, 08 Mar 2005 19:02:48 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D8jyY-0000dT-EG for namedroppers@ops.ietf.org; Tue, 08 Mar 2005 19:02:38 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j28J2PMP004370; Tue, 8 Mar 2005 14:02:28 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.1.2.2.20050308114811.02c94960@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 08 Mar 2005 14:02:26 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: Key-rollover IPR disclosure In-Reply-To: <6.2.0.14.2.20050215104624.03d3d278@localhost> References: <6.2.0.14.2.20050215104624.03d3d278@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE,PORN_URL_SEX autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable We have received a response from Diversinet.com about more detailed licence terms and the status of their patent applications in other countries and here is their response: "Diversinet's position at this time is that it is worthwhile, from a public= =20 relations perspective, for it to license its technology on terms that are=20 reciprocal, reasonable and royalty free, if such technology is incorporated= =20 into a specification. Our general license would contain terms that are=20 typical in a commercial intellectual property license, and would include a= =20 requirement that any organization using the technology covered by our=20 patent would have to disclose prescribed language indicating that the=20 licensee's service or product incorporates intellectual property owned by=20 Diversinet, and that such organization would agree to be referenceable by=20 Diversinet in any publicity regarding Diversinet's patent portfolio." We also have a patent application #2306505 that was filed in Canada on Aug= =20 13, 1998. The application is identical to the patent that was obtained from= =20 Israel. I am planning to update our 2 IPR filed for IETF to include the above=20 paragraph and the Canadian patent application. Chairs are not sure what exactly what the next step is, but we will keep you posted when we find out. Olafur & Olaf At 13:21 15/02/2005, =D3lafur Gudmundsson/DNSEXT co-chair wrote: >Dear Colleagues, > >An IPR[*] disclosure has been made. It relates to two drafts in our >working group: > draft-ietf-dnsext-trustupdate-timers > draft-ietf-dnsext-trustupdate-threshold > >The disclosure has been made by "Diversinet.com" and can be found >in the IETF IPR disclosure database: >https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D530 >and >https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D531 > >Copies of the patent application can be found on >http://stora.ogud.com/DNSSEC/key-rollover/key-rollover-patent-Application.p= df >a copy of the patent certificate can be found in >http://stora.ogud.com/DNSSEC/key-rollover/key-rollover-patent-certificate.p= df > >The licensing terms of this patent are not known yet. The chairs >will inquire about licensing terms in neutral terms and report to the= group. > >We want to issue is a "rat hole" alert: >Working groups tend to discuss the validity of patent claims, the >licensing terms and such at great lengths. In the end patent issues >are not technical but legal issues. It is up to the implementors of >technology under IPR to deal with these issues, not the working group. >If the IPR prohibits implementation than the WG would like to know, >from implementors. As rough consensus without running code does not make=20 >sense. > >Or to paraphrase the above: we all have an opinion on IPR, this >is not the list to rehash those. > >--Olaf and Olafur > DNSEXT WG Chairs > >We'll try to maintain documentation on our (experimental) DNSEXT twiki:=20 >http://dnsext.secret-wg.org > >[*] IPR =3D=3D Intellectual PRoperty i.e. patent > >-- >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 Tue Mar 8 14:10:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03011 for ; Tue, 8 Mar 2005 14:10:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8k4G-0001lw-Sa for namedroppers-data@psg.com; Tue, 08 Mar 2005 19:08:32 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8k4D-0001kr-LJ for namedroppers@ops.ietf.org; Tue, 08 Mar 2005 19:08:29 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id B0D02C2DA7; Tue, 8 Mar 2005 19:08:28 +0000 (GMT) Date: Tue, 08 Mar 2005 19:08:25 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie , DNSEXT WG Cc: Alex Bligh Subject: Re: Revised NSEC3 proof of nonexistence text Message-ID: In-Reply-To: <422DE0DA.3000504@algroup.co.uk> References: <422DE0DA.3000504@algroup.co.uk> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 08 March 2005 17:28 +0000 Ben Laurie wrote: > In response to Ed's lecture, here's my second attempt: Must be something wrong here - I understood it first parse! 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 Tue Mar 8 14:52:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07731 for ; Tue, 8 Mar 2005 14:52:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8kh4-0005a0-Pe for namedroppers-data@psg.com; Tue, 08 Mar 2005 19:48:38 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D8kgv-0005Z4-M4 for namedroppers@ops.ietf.org; Tue, 08 Mar 2005 19:48:29 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 7A5F42DF2A; Tue, 8 Mar 2005 20:48:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 5C2442DF20 for ; Tue, 8 Mar 2005 20:48:27 +0100 (CET) Date: Tue, 8 Mar 2005 20:48:27 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: an example on wildcard proof. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Here is an example to complement Ben's text on wildcard proof. Given a zone, com, an existing record example.com and a qname for test1.test2.example.com, the authoritative server needs to return three NSEC3 records. The set of NSEC3 proves the following: 1) example.com exist. 2) test2.example.com does not exist. 3) *.example.com does not exist. where: 1 and 2 prove the closest encloser: Since test2.example.com does not exist, while example.com does, the latter must be the closest encloser. Since there may be a wildcard RRset at example.com (thus being *.example.com), we need the third NSEC3 to prove that the wildcard RRset does not exist. Note that there is no need to prove the nonexistence of test1.test2.example.com, since test2.example.com 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 Tue Mar 8 15:22:53 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13896 for ; Tue, 8 Mar 2005 15:22:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8lBk-00091l-EV for namedroppers-data@psg.com; Tue, 08 Mar 2005 20:20:20 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8lBh-00091U-9O for namedroppers@ops.ietf.org; Tue, 08 Mar 2005 20:20:17 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j28KGeBJ023874 for ; Tue, 8 Mar 2005 15:16:40 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAboaONU; Tue, 8 Mar 05 15:16:37 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j28KIQs3016592 for ; Tue, 8 Mar 2005 15:18:26 -0500 (EST) Date: Tue, 8 Mar 2005 15:18:26 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: new epsilon draft In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > A new version of the on-line signing (epsilon) draft has been > submitted. Major changes include examples covering the wildcard name > and explicit verbiage relaxing constraints on the 'next name' field in > NSEC RRs. > > Also available from: > > http://dnssec-tools.sourceforge.net/docs/draft-weiler-dnsext-dnssec-online-signing-01.txt Two questions, which I'll ask again tomorrow morning: would the WG like to adopt this draft as a WG work item? Is the doc ready for WG last call? I have heard one broadly-supported change request, which is to explicitly relax (or note that we're ignoring) -protocol section 2.3, which says: An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name. That is, the signing process MUST NOT create NSEC or RRSIG RRs for owner names nodes which were not the owner name of any RRset before the zone was signed. I'll probably include a directive that resolvers MUST NOT reject NSEC RR's with only RRSIG and NSEC bits set. One alternative is to suggest that synthesized NSEC records set another bit in the typemap (beyond NSEC and RRSIG), but my impression is that the former solution (just say that having only those two set is okay) is sufficient and preferred. -- 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 Mar 8 15:31:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15616 for ; Tue, 8 Mar 2005 15:31:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8lKq-000AA2-VH for namedroppers-data@psg.com; Tue, 08 Mar 2005 20:29:44 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8lKq-000A9n-0C for namedroppers@ops.ietf.org; Tue, 08 Mar 2005 20:29:44 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j28KQ74S024524 for ; Tue, 8 Mar 2005 15:26:07 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAlQaq5V; Tue, 8 Mar 05 15:26:04 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j28KRrNn016876 for ; Tue, 8 Mar 2005 15:27:53 -0500 (EST) Date: Tue, 8 Mar 2005 15:27:53 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: new DNSSECbis implementation notes doc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In an effort to keep minor DNSSECbis clarifications in one place, I started this document. There won't be an announcement 'til next week, but it's in the repository now. Comments, suggestions, and contributions are welcome. Would the WG like to adopt this as a WG work item? What else needs to be included (send text)? http://www.ietf.org/internet-drafts/draft-weiler-dnsext-dnssec-bis-updates-00.txt -- 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 Mar 8 17:53:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28128 for ; Tue, 8 Mar 2005 17:53:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8nUw-000NQV-QG for namedroppers-data@psg.com; Tue, 08 Mar 2005 22:48:18 +0000 Received: from [212.69.37.4] (helo=buffy.gnomon.org.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D8nUv-000NQF-7r for namedroppers@ops.ietf.org; Tue, 08 Mar 2005 22:48:17 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by buffy.gnomon.org.uk (8.13.1/8.13.1) with ESMTP id j28Mm7Ei062275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Mar 2005 22:48:12 GMT (envelope-from roy+dated+1112914084.e1618d@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.2/8.13.0) with ESMTP id j28Mm9h0029304 for ; Tue, 8 Mar 2005 22:48:09 GMT (envelope-from roy+dated+1112914084.e1618d@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.2/8.13.0/Submit) id j28Mm47O029303 for namedroppers@ops.ietf.org; Tue, 8 Mar 2005 22:48:04 GMT (envelope-from roy+dated+1112914084.e1618d@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 08 Mar 2005 22:48:04 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16942.11172.322966.49275@giles.gnomon.org.uk> Date: Tue, 8 Mar 2005 22:48:04 +0000 To: namedroppers@ops.ietf.org Subject: Dumb question about NSEC3 and opt-in X-Mailer: VM 7.19 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (buffy.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.80/752/Mon Mar 7 16:40:04 2005 clamav-milter version 0.80j on buffy.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Having only skimmed the draft, and the thread of comments on it, I may have missed something, so apologies if this is a dumb question. Is it the case that, with opt-in (authoritive only bit set), that: 1. When the nameserver responds with an insecure delegation, it MUST still prove it to be insecure, by including the covering NSEC3 record that proves non-existence of a DS record? 2. When the nameserver responds with NXDOMAIN, it MUST still prove the absence of authoritative data (even though it can't prove the absence of the domain) by including the covering NSEC3 record. 3. That a security-aware resolver MUST veryify (1) and (2) above and return 'bogus' if they're not satisfied? I'm assuming/hopeing the answer is 'yes' in all three cases... -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 Mar 8 21:35:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15376 for ; Tue, 8 Mar 2005 21:35:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8qzp-000KLK-OW for namedroppers-data@psg.com; Wed, 09 Mar 2005 02:32:25 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D8qzk-000KKP-LO for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 02:32:21 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id DE3D22DF7D; Wed, 9 Mar 2005 03:32:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id C1F7A2DF2B; Wed, 9 Mar 2005 03:32:17 +0100 (CET) Date: Wed, 9 Mar 2005 03:32:17 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Roy Badami Cc: namedroppers@ops.ietf.org Subject: Re: Dumb question about NSEC3 and opt-in In-Reply-To: <16942.11172.322966.49275@giles.gnomon.org.uk> Message-ID: References: <16942.11172.322966.49275@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 8 Mar 2005, Roy Badami wrote: > Having only skimmed the draft, and the thread of comments on it, I may > have missed something, so apologies if this is a dumb question. > > Is it the case that, with opt-in (authoritive only bit set), that: > > 1. When the nameserver responds with an insecure delegation, it MUST > still prove it to be insecure, by including the covering NSEC3 > record that proves non-existence of a DS record? Yes. > 2. When the nameserver responds with NXDOMAIN, it MUST still prove the > absence of authoritative data (even though it can't prove the > absence of the domain) by including the covering NSEC3 record. Yes. > 3. That a security-aware resolver MUST veryify (1) and (2) above and > return 'bogus' if they're not satisfied? Yes. > I'm assuming/hopeing the answer is 'yes' in all three cases... Correct :) 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 Mar 8 22:11:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21101 for ; Tue, 8 Mar 2005 22:11:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8rY2-000Oja-7b for namedroppers-data@psg.com; Wed, 09 Mar 2005 03:07:46 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D8rY0-000OiQ-7O for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 03:07:44 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j2937fD1013330 for ; Tue, 8 Mar 2005 22:07:41 -0500 Received: from gorilla ([129.6.220.24]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id j2936pEY007000 for ; Tue, 8 Mar 2005 22:06:52 -0500 (EST) From: "Scott Rose" To: Subject: RE: new DNSSECbis implementation notes doc Date: Tue, 8 Mar 2005 21:06:53 -0600 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think the cause of the inconsistency in section 4 of the document is actually just because of poor wording. Section 4.2 is correct, NS queries should be used to find the parent of a given zone. B.8 (and C.8) is actually an example of a DNS query that generates a NSEC response. In that scenario, a resolver is trying to obtain a DS RR for a given zone, and mistakenly sending the query to the child zone. It gets back the NSEC RR showing it is the child zone, and therefor the wrong zone server to ask. The query for the DS RRType is only for the example purpose. So it is actually 2 different topics in the two sections, and should not be read together. Admittedly, it may need further clarification. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Samuel Weiler > Sent: Tuesday, March 08, 2005 2:28 PM > To: namedroppers@ops.ietf.org > Subject: new DNSSECbis implementation notes doc > > > In an effort to keep minor DNSSECbis clarifications in one place, I > started this document. There won't be an announcement 'til next week, > but it's in the repository now. Comments, suggestions, and > contributions are welcome. > > Would the WG like to adopt this as a WG work item? What else needs to > be included (send text)? > > http://www.ietf.org/internet-drafts/draft-weiler-dnsext-dnssec-bis > -updates-00.txt > > -- 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: > -- 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 Mar 9 05:37:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13933 for ; Wed, 9 Mar 2005 05:37:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8yV1-000IPk-I5 for namedroppers-data@psg.com; Wed, 09 Mar 2005 10:33:07 +0000 Received: from [212.69.37.4] (helo=buffy.gnomon.org.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D8yV0-000IPX-FG for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 10:33:06 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by buffy.gnomon.org.uk (8.13.1/8.13.1) with ESMTP id j29AWt5g065386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Mar 2005 10:33:00 GMT (envelope-from roy+dated+1112956376.d9f5b3@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.2/8.13.0) with ESMTP id j29AWvT9033291 for ; Wed, 9 Mar 2005 10:32:57 GMT (envelope-from roy+dated+1112956376.d9f5b3@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.2/8.13.0/Submit) id j29AWuiL033285 for namedroppers@ops.ietf.org; Wed, 9 Mar 2005 10:32:56 GMT (envelope-from roy+dated+1112956376.d9f5b3@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 09 Mar 2005 10:32:46 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16942.53454.273740.645145@giles.gnomon.org.uk> Date: Wed, 9 Mar 2005 10:32:46 +0000 To: Roy Arends Cc: Roy Badami , namedroppers@ops.ietf.org Subject: Re: Dumb question about NSEC3 and opt-in In-Reply-To: References: <16942.11172.322966.49275@giles.gnomon.org.uk> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (buffy.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.80/752/Mon Mar 7 16:40:04 2005 clamav-milter version 0.80j on buffy.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I'm assuming/hopeing the answer is 'yes' in all three cases... Roy> Correct :) Thanks... -- 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 Mar 9 06:00:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16651 for ; Wed, 9 Mar 2005 06:00:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8yu6-000Lhn-Q9 for namedroppers-data@psg.com; Wed, 09 Mar 2005 10:59:02 +0000 Received: from [212.69.37.4] (helo=buffy.gnomon.org.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D8yu5-000LhV-Ly for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 10:59:01 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by buffy.gnomon.org.uk (8.13.1/8.13.1) with ESMTP id j29Awpwu065494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Mar 2005 10:58:56 GMT (envelope-from roy+dated+1112957934.2fe68a@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.2/8.13.0) with ESMTP id j29AwsUs033517 for ; Wed, 9 Mar 2005 10:58:54 GMT (envelope-from roy+dated+1112957934.2fe68a@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.2/8.13.0/Submit) id j29Awsbb033516 for namedroppers@ops.ietf.org; Wed, 9 Mar 2005 10:58:54 GMT (envelope-from roy+dated+1112957934.2fe68a@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 09 Mar 2005 10:58:54 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16942.55022.2320.731606@giles.gnomon.org.uk> Date: Wed, 9 Mar 2005 10:58:54 +0000 To: namedroppers@ops.ietf.org Subject: DNSSECbis question (authenticated denial) X-Mailer: VM 7.19 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (buffy.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.80/752/Mon Mar 7 16:40:04 2005 clamav-milter version 0.80j on buffy.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit When a security-aware resolver is validating an NXDOMAIN response (say, when querying for b.a.com of a nameserver authoritative for .com) then the resolver has to verify that: 1. The response proves that b.a.com doesn't exist; and 2. The response proves that *.a.com doesn't exist. Doesn't the resolver also need to verify that 3. The response proves tha a.com is not a delegation point? Is there some reason I'm missing why this isn't necessary? The response always will prove point 3, but I can't see where the spec says the resolver needs to verify it. -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 Mar 9 07:00:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22809 for ; Wed, 9 Mar 2005 07:00:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8zob-00048m-HV for namedroppers-data@psg.com; Wed, 09 Mar 2005 11:57:25 +0000 Received: from [212.69.37.4] (helo=buffy.gnomon.org.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D8zoa-00048Q-Gm for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 11:57:24 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by buffy.gnomon.org.uk (8.13.1/8.13.1) with ESMTP id j29BvEYF065736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Mar 2005 11:57:19 GMT (envelope-from roy+dated+1112961437.46264c@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.2/8.13.0) with ESMTP id j29BvHCI033924 for ; Wed, 9 Mar 2005 11:57:17 GMT (envelope-from roy+dated+1112961437.46264c@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.2/8.13.0/Submit) id j29BvHuT033923 for namedroppers@ops.ietf.org; Wed, 9 Mar 2005 11:57:17 GMT (envelope-from roy+dated+1112961437.46264c@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 09 Mar 2005 11:57:17 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16942.58524.788818.947885@giles.gnomon.org.uk> Date: Wed, 9 Mar 2005 11:57:16 +0000 To: namedroppers@ops.ietf.org Subject: DNSSECbis question (authenticated denial) In-Reply-To: <16942.55022.2320.731606@giles.gnomon.org.uk> References: <16942.55022.2320.731606@giles.gnomon.org.uk> X-Mailer: VM 7.19 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (buffy.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.80/752/Mon Mar 7 16:40:04 2005 clamav-milter version 0.80j on buffy.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit More specifically, the case I'm thinking of is: .com implements DNSSECbis, and a.com is securely delegated. I query for b.a.com, but a man in the middle returns a name error with the following proof: a.com. NSEC aa.com. NS DS NSEC RRSIG a.com. RRSIG NSEC ... Clearly the NSEC RR indicates I've been spoofed; the presence of NS records at a.com indicates that there is a delegation there. However it seems to me that a naive implementation of a resolver according to -protocol section 5.4 might accept this proof, since it both proves that b.a.com does not exist in the zone, and that no relevent wildcard exists in the zone, which is all that -protocol instructs resolvers to verify. I could just be confused 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 Wed Mar 9 08:46:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03083 for ; Wed, 9 Mar 2005 08:46:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D91TE-000F3R-FI for namedroppers-data@psg.com; Wed, 09 Mar 2005 13:43:28 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D91T8-000F31-TS for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 13:43:23 +0000 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1D91T7-000DTW-L2 for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 08:43:21 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j29DhKc30812 for ; Wed, 9 Mar 2005 05:43:20 -0800 Date: Wed, 9 Mar 2005 05:43:20 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Revised resolution to Issue 78: UNIQUEness Probing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The LLMNR Issues list is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html Here is a proposed resolution to Issue 78 (UNIQUEness Probing) that addresses the issue of ongoing conflict detection and uniqueness probing deadlocks. Thomas suggested defining a 'T'entative bit along the lines of what is used in Neighbor Discovery, in addition to use of the 'C'onflict bit. A version of the document incorporating the changes is available for inspection here: http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-39.txt The proposed resolution is as follows: In Section 2.1.1 add the following paragraphs: "C Conflict. When set within a request, the 'C'onflict bit indicates that a sender has received multiple LLMNR responses to this query. In an LLMNR response, if one or more resource records in the answer section is UNIQUE, then the 'C' bit is clear, otherwise it is set. LLMNR senders do not retransmit queries with the 'C' bit set. Responders MUST NOT respond to LLMNR queries with the 'C' bit set, but may start the uniqueness verification process, as described in Section 4.2. T Tentative. The 'T'entative bit is set in a response if the responder is authoritative for the name, but has not yet verified the uniqueness of one or more of the resource record(s) in the answer section. A responder MUST ignore the 'T' bit in a query, if set. When a response with the 'T' bit set is received in response to a uniqueness query, a conflict has been detected and a responder MUST resolve the conflict as described in Section 4.1." Change Sections 4, 4.1 and 4.2 to the following: "4. Conflict resolution The uniqueness of a resource record MAY depend on the nature of the name in the query and type of the query. For example, multiple hosts may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster). By default, a responder SHOULD be configured to behave as though all RRs are UNIQUE on each interface on which LLMNR is enabled. To detect duplicate use of a name, an administrator can use a name resolution utility which employs LLMNR and lists both responses and responders. This would allow an administrator to diagnose behavior and potentially to intervene and reconfigure LLMNR responders who should not be configured to respond to the same name. 4.1. Uniqueness Verification Prior to including a UNIQUE resource record in a response with the 'T' bit clear, for each UNIQUE resource record in a given interface's configuration, the host MUST verify that there is no other host within the scope of LLMNR query propagation that can return a resource record for the same name, type and class on that interface. Once a responder has verified the uniqueness of a UNIQUE resource record, if it receives an LLMNR query for that resource record, with the 'C' bit clear, it MUST respond, with the 'T' bit clear. Prior to verifying uniqueness, a responder MUST set the 'T' bit in responses. Uniqueness verification is carried out when the host: - starts up or is rebooted - wakes from sleep (if the network interface was inactive during sleep) - is configured to respond to LLMNR queries on an interface enabled for transmission and reception of IP traffic - is configured to respond to LLMNR queries using additional UNIQUE resource records - verifies the acquisition of a new IP address and configuration on an interface To verify uniqueness, a responder MUST send an LLMNR query with the 'C' bit clear, over all protocols on which it responds to LLMNR queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify uniqueness of a name by sending a query for the name with type='ANY'. If no response is received, the sender retransmits the query, as specified in Section 2.7. If a response is received with the 'T' bit clear, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). If a response is received with the 'T' bit set, the responder MUST check if the source IP address in the response, interpreted as an unsigned integer, is less than the source IP address in the query. If so, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). For the purpose of uniqueness verification, the contents of the answer section of a response is irrelevant. Periodically carrying out uniqueness verification in an attempt to detect name conflicts is not necessary, wastes network bandwidth, and may actually be detrimental. For example, if network links are joined only briefly, and are separated again before any new communication is initiated, temporary conflicts are benign and no forced reconfiguration is required. LLMNR responders SHOULD NOT periodically attempt uniqueness verification. 4.2. Conflict Detection and Defense Hosts on disjoint network links may configure the same name for use with LLMNR. If these separate network links are later joined or bridged together, then there may be multiple hosts which are now on the same link, trying to use the same name. In order to enable ongoing detection of name conflicts, when an LLMNR sender receives multiple LLMNR responses to a query, it MUST check if the 'C' bit is clear in any of the responses. If so, the sender SHOULD send another query for the same name, type and class, this time with the 'C' bit set, with the potentially conflicting resource records included in the additional section. Queries with the 'C' bit set are considered advisory and responders MUST verify the existence of a conflict before acting on it. A responder receiving a query with the 'C' bit set MUST NOT respond. If the query is for UNIQUE resource record(s), then the responder MUST send its own query for the same name, type and class, with the 'C' bit clear. If a response is received, then a conflict has been detected. An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD log them. Upon detecting a conflict, an LLMNR responder MUST immediately stop using the conflicting name in response to LLMNR queries received over any supported protocol, if the source IP address in the response, interpreted as an unsigned integer, is less than the source IP address in the uniqueness verification query. After stopping the use of a name, the responder MAY elect to configure a new name. However, since name reconfiguration may be disruptive, this is not required, and a responder may have been configured to respond to multiple names so that alternative names may already be available." Delete DEFEND_INTERVAL from Section 7. -- 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 Mar 9 11:26:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21137 for ; Wed, 9 Mar 2005 11:26:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D93v1-00051U-Pa for namedroppers-data@psg.com; Wed, 09 Mar 2005 16:20:19 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D93uq-00050M-Hu for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 16:20:08 +0000 Received: from stjohns-lap2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 3886B568AD; Wed, 9 Mar 2005 08:20:06 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.2.0.14.2.20050309110847.04853eb0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 09 Mar 2005 11:20:05 -0500 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: Key-rollover IPR disclosure In-Reply-To: <6.2.1.2.2.20050308114811.02c94960@localhost> References: <6.2.0.14.2.20050215104624.03d3d278@localhost> <6.2.1.2.2.20050308114811.02c94960@localhost> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4032398==.ALT" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,HTML_20_30, HTML_MESSAGE,MIME_QP_LONG_LINE,PORN_URL_SEX autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=====================_4032398==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable As requested by the chair, I'm posting text from another IPR disclosure=20 that describes terms that would be less onerous than the terms currently=20 offered by the discloser. The current terms in disclosures 548 and 549=20 require "any organization using the technology" to also agree to be cited=20 in publicity material from Diversinet and I'm fairly sure that will be a=20 deal breaker for many implementers, and definitely for the "users". >Regarding this internet draft "IMAP Extension for CHECKPOINT= Synchronization", >draft-wener-lemonade-checkpoint-01.txt, to the extent this draft is= included >into final IETF standard specification, Nokia agrees not to assert those=20 >claims >in Nokia patents that apply to this submission and are technically=20 >necessary to >implement the IETF standard spesification against any other party in=20 >respect of >its implementation of the specification, provided that the party relying=20 >on thiscommitment does not assert its patents against Nokia. At 02:02 PM 3/8/2005, =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote: >We have received a response from Diversinet.com about more detailed >licence terms and the status of their patent applications in other >countries and here is their response: > > >"Diversinet's position at this time is that it is worthwhile, from a=20 >public relations perspective, for it to license its technology on terms=20 >that are reciprocal, reasonable and royalty free, if such technology is=20 >incorporated into a specification. Our general license would contain terms= =20 >that are typical in a commercial intellectual property license, and would= =20 >include a requirement that any organization using the technology covered= =20 >by our patent would have to disclose prescribed language indicating that=20 >the licensee's service or product incorporates intellectual property owned= =20 >by Diversinet, and that such organization would agree to be referenceable= =20 >by Diversinet in any publicity regarding Diversinet's patent portfolio." > >We also have a patent application #2306505 that was filed in Canada on Aug= =20 >13, 1998. The application is identical to the patent that was obtained=20 >from Israel. > >I am planning to update our 2 IPR filed for IETF to include the above=20 >paragraph and the Canadian patent application. > > >Chairs are not sure what exactly what the next step is, but we will >keep you posted when we find out. > > Olafur & Olaf > > >At 13:21 15/02/2005, =D3lafur Gudmundsson/DNSEXT co-chair wrote: >>Dear Colleagues, >> >>An IPR[*] disclosure has been made. It relates to two drafts in our >>working group: >> draft-ietf-dnsext-trustupdate-timers >> draft-ietf-dnsext-trustupdate-threshold >> >>The disclosure has been made by "Diversinet.com" and can be found >>in the IETF IPR disclosure database: >>https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D530 >>and >>https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D531 >> >>Copies of the patent application can be found on >>http://stora.ogud.com/DNSSEC/key-rollover/key-rollover-patent-Application.= pdf >>a copy of the patent certificate can be found in >>http://stora.ogud.com/DNSSEC/key-rollover/key-rollover-patent-certificate.= pdf >> >>The licensing terms of this patent are not known yet. The chairs >>will inquire about licensing terms in neutral terms and report to the= group. >> >>We want to issue is a "rat hole" alert: >>Working groups tend to discuss the validity of patent claims, the >>licensing terms and such at great lengths. In the end patent issues >>are not technical but legal issues. It is up to the implementors of >>technology under IPR to deal with these issues, not the working group. >>If the IPR prohibits implementation than the WG would like to know, >>from implementors. As rough consensus without running code does not make= =20 >>sense. >> >>Or to paraphrase the above: we all have an opinion on IPR, this >>is not the list to rehash those. >> >>--Olaf and Olafur >> DNSEXT WG Chairs >> >>We'll try to maintain documentation on our (experimental) DNSEXT twiki:=20 >>http://dnsext.secret-wg.org >> >>[*] IPR =3D=3D Intellectual PRoperty i.e. patent >> >>-- >>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: --=====================_4032398==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As requested by the chair, I'm posting text from another IPR disclosure that describes terms that would be less onerous than the terms currently offered by the discloser.  The current terms in disclosures 548 and 549 require "
any organization using the technology" to
also agree to be cited in publicity material from Diversinet and I'm
fairly sure that will be a deal breaker for many implementers, and
definitely for the "users".=20



Regarding this internet draft
"IMAP Extension for CHECKPOINT Synchronization",
draft-wener-lemonade-checkpoint-01.txt, to the extent this draft is
included
into final IETF standard specification, Nokia agrees not to assert those
claims
in Nokia patents that apply to this submission and are technically
necessary to
implement the IETF standard spesification against any other party in
respect of
its implementation of the specification, provided that the party relying
on thiscommitment does not assert its patents against
Nokia.



At 02:02 PM 3/8/2005, =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote:
We have received a response f= rom Diversinet.com about more detailed
licence terms and the status of their patent applications in other
countries and here is their response:

<quote>
"Diversinet's position at this time is that it is worthwhile, from a public relations perspective, for it to license its technology on terms that are reciprocal, reasonable and royalty free, if such technology is incorporated into a specification. Our general license would contain terms that are typical in a commercial intellectual property license, and would include a requirement that any organization using  the technology covered by our patent would have to disclose prescribed language indicating that the licensee's service or product incorporates intellectual property owned by Diversinet, and that such organization would agree to be referenceable by Diversinet in any publicity regarding Diversinet's patent portfolio."

We also have a patent application #2306505 that was filed in Canada on Aug 13, 1998. The application is identical to the patent that was obtained from Israel.

I am planning to update our 2 IPR filed for IETF to include the above paragraph and the Canadian patent application.
</quote>

Chairs are not sure what exactly what the next step is, but we will
keep you posted when we find out.

        Olafur & Olaf


At 13:21 15/02/2005, =D3lafur Gudmundsson/DNSEXT co-chair wrote:
Dear Colleagues,

An IPR[*] disclosure has been made. It relates to two drafts in our
working group:
        draft-ietf-dnsext-trustupdate-timers
        draft-ietf-dnsext-trustupdate-threshold

The  disclosure has been made by "Diversinet.com" and can be found
in the IETF IPR disclosure database:
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D530
and
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D531

Copies of the patent application can be found on
http://stora.ogud.com/DNSSEC/key-rollover/key-rollover-patent-Application.pd= f
a copy of the patent certificate can be found in
http://stora.ogud.com/DNSSEC/key-rollover/key-rollover-patent-certificate.pd= f

The licensing terms of this patent are not known yet. The chairs
will inquire about licensing terms in neutral terms and report to the group.

We want to issue is a "rat hole" alert:
Working groups tend to discuss the validity of patent claims, the
licensing terms and such at great lengths. In the end patent issues
are not technical but legal issues. It is up to the implementors of
technology under IPR to deal with these issues, not the working group.
If the IPR prohibits implementation than the WG would like to know,
from implementors. As rough consensus without running code does not make sense.

Or to paraphrase the above: we all have an opinion on IPR, this
is not the list to rehash those.

--Olaf and Olafur
  DNSEXT WG Chairs

We'll try to maintain documentation on our (experimental) DNSEXT twiki: http://dnsext.secret-wg.org

[*] IPR =3D=3D Intellectual PRoperty i.e. patent

--
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/>


--
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/>
--=====================_4032398==.ALT-- -- 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 Mar 9 11:46:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23321 for ; Wed, 9 Mar 2005 11:46:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D94HQ-0007UT-FO for namedroppers-data@psg.com; Wed, 09 Mar 2005 16:43:28 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D94HP-0007UC-Lg for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 16:43:27 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j29GhRKN022221 for ; Wed, 9 Mar 2005 16:43:27 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j29GhRjB022218 for namedroppers@ops.ietf.org; Wed, 9 Mar 2005 16:43:27 GMT Date: Wed, 9 Mar 2005 16:43:27 +0000 From: bmanning@vacation.karoshi.com To: namedroppers@ops.ietf.org Subject: semantic overload Message-ID: <20050309164327.GF22057@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ok, Ed is btwn a rock and a hard place. He has done great work with wild cards, working out most of the kinks. I'm still in favor of allowing all labels to exist, the tough call is trying to properly represent a "wildcard" in a zone file. e.g. having the character "*" represent both a valid label as well as a trigger for other processing. perhaps we could use something else to indicate "wildcard" functions should be involked.... like /null :) --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 Mar 9 11:59:31 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25201 for ; Wed, 9 Mar 2005 11:59:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D94UL-0009RQ-Si for namedroppers-data@psg.com; Wed, 09 Mar 2005 16:56:49 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D94UI-0009Ql-Li for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 16:56:46 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id EB0992DF32; Wed, 9 Mar 2005 17:56:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id E5F6F2DF21; Wed, 9 Mar 2005 17:56:43 +0100 (CET) Date: Wed, 9 Mar 2005 17:56:42 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: bmanning@vacation.karoshi.com Cc: namedroppers@ops.ietf.org Subject: Re: semantic overload In-Reply-To: <20050309164327.GF22057@vacation.karoshi.com.> Message-ID: References: <20050309164327.GF22057@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 9 Mar 2005 bmanning@vacation.karoshi.com wrote: > ok, > Ed is btwn a rock and a hard place. He has done great work > with wild cards, working out most of the kinks. I'm still > in favor of allowing all labels to exist, the tough call is > trying to properly represent a "wildcard" in a zone file. > > e.g. having the character "*" represent both a valid label > as well as a trigger for other processing. perhaps we could > use something else to indicate "wildcard" functions should be > involked.... like /null :) So I can't delegate /null anymore :) 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 Mar 9 12:03:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25864 for ; Wed, 9 Mar 2005 12:03:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D94YX-000A4c-6B for namedroppers-data@psg.com; Wed, 09 Mar 2005 17:01:09 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D94YW-000A4J-50 for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 17:01:08 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 17287C2DA6; Wed, 9 Mar 2005 17:01:07 +0000 (GMT) Date: Wed, 09 Mar 2005 17:01:06 +0000 From: Alex Bligh Reply-To: Alex Bligh To: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: semantic overload Message-ID: <29488C5E180E0C7724D850E9@[192.168.100.25]> In-Reply-To: <20050309164327.GF22057@vacation.karoshi.com.> References: <20050309164327.GF22057@vacation.karoshi.com.> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 09 March 2005 16:43 +0000 bmanning@vacation.karoshi.com wrote: > Ed is btwn a rock and a hard place. He has done great work > with wild cards, working out most of the kinks. I'm still > in favor of allowing all labels to exist, the tough call is > trying to properly represent a "wildcard" in a zone file. > > e.g. having the character "*" represent both a valid label > as well as a trigger for other processing. perhaps we could > use something else to indicate "wildcard" functions should be > involked.... like /null :) Why is this a qualitatively different problem from other characters (e.g. CR, LF) which can (for the masochistic) be valid constituent components of labels? Can't we just say that in some circumstance (presumably "on disk" format at a minimum, but also presumably AXFR) some characters need to be escaped if you don't want them to assume their special meaning? IE I'm pretty sure that having $ORIGIN example.com \052 IN MX notawildcardmx.example.com. * IN MX wildcardmx.example.com. isn't going to break very much, is it? Not sure how this affects AXFR though... 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 Wed Mar 9 12:06:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26076 for ; Wed, 9 Mar 2005 12:06:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D94as-000Abw-Tj for namedroppers-data@psg.com; Wed, 09 Mar 2005 17:03:34 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D94ar-000AbW-2I for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 17:03:33 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 3F88D677F2 for ; Wed, 9 Mar 2005 17:03:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j29H30Id008195 for ; Thu, 10 Mar 2005 04:03:00 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200503091703.j29H30Id008195@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: semantic overload In-reply-to: Your message of "Wed, 09 Mar 2005 16:43:27 -0000." <20050309164327.GF22057@vacation.karoshi.com.> Date: Thu, 10 Mar 2005 04:03:00 +1100 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ok, > Ed is btwn a rock and a hard place. He has done great work > with wild cards, working out most of the kinks. I'm still > in favor of allowing all labels to exist, the tough call is > trying to properly represent a "wildcard" in a zone file. > > e.g. having the character "*" represent both a valid label > as well as a trigger for other processing. perhaps we could > use something else to indicate "wildcard" functions should be > involked.... like /null :) > > --bill Wildcard label type? '\*' it indicate. > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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 Mar 9 12:27:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28945 for ; Wed, 9 Mar 2005 12:27:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D94up-000DHS-W5 for namedroppers-data@psg.com; Wed, 09 Mar 2005 17:24:11 +0000 Received: from [213.154.224.50] (helo=bartok.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D94um-000DH6-Kn for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 17:24:09 +0000 Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j29HO4Wn043720; Wed, 9 Mar 2005 18:24:04 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200503091724.j29HO4Wn043720@bartok.nlnetlabs.nl> To: Alex Bligh cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: semantic overload In-reply-to: Your message of Wed, 09 Mar 2005 17:01:06 +0000. <29488C5E180E0C7724D850E9@[192.168.100.25]> Date: Wed, 09 Mar 2005 18:24:04 +0100 From: Jaap Akkerhuis X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk $ORIGIN example.com \052 IN MX notawildcardmx.example.com. * IN MX wildcardmx.example.com. Should actually be \042 jaap -- 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 Mar 9 14:15:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09110 for ; Wed, 9 Mar 2005 14:15:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D96bb-000PtJ-E3 for namedroppers-data@psg.com; Wed, 09 Mar 2005 19:12:27 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D96bZ-000Pt1-L4 for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 19:12:25 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id E9660677F2 for ; Wed, 9 Mar 2005 19:12:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j29JC89f008419; Thu, 10 Mar 2005 06:12:08 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200503091912.j29JC89f008419@drugs.dv.isc.org> To: Jaap Akkerhuis Cc: Alex Bligh , bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: semantic overload In-reply-to: Your message of "Wed, 09 Mar 2005 18:24:04 BST." <200503091724.j29HO4Wn043720@bartok.nlnetlabs.nl> Date: Thu, 10 Mar 2005 06:12:08 +1100 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > $ORIGIN example.com > \052 IN MX notawildcardmx.example.com. > * IN MX wildcardmx.example.com. > > Should actually be \042 > > jaap One needs to change the wire format. > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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 Mar 9 14:23:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09731 for ; Wed, 9 Mar 2005 14:23:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D96kx-0000mx-Dl for namedroppers-data@psg.com; Wed, 09 Mar 2005 19:22:07 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D96kw-0000mc-Hv for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 19:22:06 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id AB027C2DA6; Wed, 9 Mar 2005 19:22:05 +0000 (GMT) Date: Wed, 09 Mar 2005 19:22:08 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Mark Andrews , Jaap Akkerhuis Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org, Alex Bligh Subject: Re: semantic overload Message-ID: <76D3C10604B7685D18F973D8@[192.168.100.25]> In-Reply-To: <200503091912.j29JC89f008419@drugs.dv.isc.org> References: <200503091912.j29JC89f008419@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 10 March 2005 06:12 +1100 Mark Andrews wrote: > One needs to change the wire format. I presume you mean by that that if non-wildcard asterisk labels are legitimate, then some wire format packets are ambiguous as to whether they mean a wildcard or an non-wildcard asterisk label? If so, and if this is a "real problem", then surely it's easier to change wire format for the (hardly ever used because of this problem) non-wildcard asterisk label than for (relatively frequently used) wildcards? 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 Wed Mar 9 17:16:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26112 for ; Wed, 9 Mar 2005 17:16:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D99Op-0005he-Jh for namedroppers-data@psg.com; Wed, 09 Mar 2005 22:11:27 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D99Og-0005cO-Bl for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 22:11:18 +0000 Received: from [IPv6???1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id E864D33C45 for ; Wed, 9 Mar 2005 22:11:15 +0000 (GMT) Message-ID: <422F665D.9060304@algroup.co.uk> Date: Wed, 09 Mar 2005 21:10:53 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'namedroppers@ops.ietf.org'" Subject: draft-ietf-dnsext-rfc2538bis-01 X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olafur asked for people to confirm they had read this and it looked OK. I have read it (again) and it looks OK. -- 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 Mar 9 17:50:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29114 for ; Wed, 9 Mar 2005 17:50:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D99yd-0009XL-Sr for namedroppers-data@psg.com; Wed, 09 Mar 2005 22:48:27 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D99ya-0009WV-BB for namedroppers@ops.ietf.org; Wed, 09 Mar 2005 22:48:24 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.3/8.13.3/Debian-6) with ESMTP id j29MmBq5002991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2005 23:48:12 +0100 From: Simon Josefsson To: Ben Laurie Cc: "'namedroppers@ops.ietf.org'" Subject: Re: draft-ietf-dnsext-rfc2538bis-01 References: <422F665D.9060304@algroup.co.uk> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Blog: http://www.livejournal.com/users/jas4711/ X-Hashcash: 1:21:050309:namedroppers@ops.ietf.org::y3WYOlmbT6aPOkU6:1uBA X-Hashcash: 1:21:050309:ben@algroup.co.uk::n4uzovtt4TNF9sgv:EOVh Date: Wed, 09 Mar 2005 23:47:55 +0100 In-Reply-To: <422F665D.9060304@algroup.co.uk> (Ben Laurie's message of "Wed, 09 Mar 2005 21:10:53 +0000") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie writes: > Olafur asked for people to confirm they had read this and it looked OK. > I have read it (again) and it looks OK. Thanks! FWIW, I just updated with a list of outstanding items that should be taken care of: 1. SPKI: drop references to SPKI WG, and reserve the SPKI types, if ever SPKI hits the standard track. Would require an update of RFC 2538bis as well. Comment: The SPKI documents are on the Experimental track, so we can't reference them normatively. Since nobody has expressed any interest in SPKI in combination with CERT RR [that I have seen], I believe it is easier to simply reserve them for use with SPKI according to a future updated version of 2538bis. What do you think? 2. Add references for S/MIME, SSL/TLS, and IPSEC. 3. Move acknowledgements of RFC 2538 authors to a "Contributor" section. If there other open issues or questions on -01, I'm all ears. I have to admit that I'm not sure the content-based owner name rules will ever be useful for anyone. However, removing them seem to be bad for the document, process-wise. There may be a slight problem in that this fact is not properly reflected in the document, but I can't think of anything to add that would be appropriate. Thoughts on this would be useful as well. 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 Wed Mar 9 21:46:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20712 for ; Wed, 9 Mar 2005 21:46:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9Daq-0004HF-AK for namedroppers-data@psg.com; Thu, 10 Mar 2005 02:40:08 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9Dap-0004Ge-BH for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 02:40:07 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 572062DF5C; Thu, 10 Mar 2005 03:40:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 320382DF32; Thu, 10 Mar 2005 03:40:02 +0100 (CET) Date: Thu, 10 Mar 2005 03:40:02 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Roy Badami Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis question (authenticated denial) In-Reply-To: <16942.58524.788818.947885@giles.gnomon.org.uk> Message-ID: References: <16942.55022.2320.731606@giles.gnomon.org.uk> <16942.58524.788818.947885@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 9 Mar 2005, Roy Badami wrote: > More specifically, the case I'm thinking of is: > > .com implements DNSSECbis, and a.com is securely delegated. > > I query for b.a.com, but a man in the middle returns a name error with > the following proof: > > a.com. NSEC aa.com. NS DS NSEC RRSIG > a.com. RRSIG NSEC ... > > Clearly the NSEC RR indicates I've been spoofed; the presence of NS > records at a.com indicates that there is a delegation there. > > However it seems to me that a naive implementation of a resolver > according to -protocol section 5.4 might accept this proof, since it > both proves that b.a.com does not exist in the zone, and that no > relevent wildcard exists in the zone, which is all that -protocol > instructs resolvers to verify. > > I could just be confused though ;-) You're not confused. You have found a major oversight in the dnssec-bis -protocol draft. We'll need to add text in section 5.4 and possible other sections that a security aware resolver MUST check the absence of the NS bit and the DNAME bit. 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 Wed Mar 9 21:58:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21779 for ; Wed, 9 Mar 2005 21:58:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9DrG-0006Mj-5C for namedroppers-data@psg.com; Thu, 10 Mar 2005 02:57:06 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9Dqy-0006Hf-81 for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 02:56:48 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2A2ucHA005094 for ; Wed, 9 Mar 2005 21:56:39 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.1.2.2.20050309172309.02d4c7c8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 09 Mar 2005 21:35:20 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT WGLC Summary: TSIG SHA1 document Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The working group last call has concluded. The document was reviewed by working group members and security area directorate member. The working group supports the document advancement. Following changes/clarifications are needed in the document before it is advanced. #1 Add text saying implementations can reject messages signed by a particular algorithm even if that algorithm is mandatory to implement. (important in TKEY environments) #2 Set lower bound on truncation (for each algorithm), default lower bound is half of original digest. #3 add new TSIG error code that sender is using excessive truncation #4 add text if responder can use different truncation than sender and rules for that. #5 Remove unused reference to 2434 #6 Add text that defines what is included in subsequent digest when truncation is used (full or truncated digest) Olafur -- 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 Mar 10 02:02:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19700 for ; Thu, 10 Mar 2005 02:02:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9HcC-0007li-3A for namedroppers-data@psg.com; Thu, 10 Mar 2005 06:57:48 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9Hc8-0007kE-RU for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 06:57:45 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2A6s7fM023719 for ; Thu, 10 Mar 2005 01:54:07 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKYaOuU; Thu, 10 Mar 05 01:54:05 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j2A6to9x009025; Thu, 10 Mar 2005 01:55:50 -0500 (EST) Date: Thu, 10 Mar 2005 01:55:50 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: TSIG SHA1 document In-Reply-To: <6.2.1.2.2.20050309172309.02d4c7c8@localhost> Message-ID: References: <6.2.1.2.2.20050309172309.02d4c7c8@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The working group last call has concluded. I'm confused. Perhaps you can explain. I thought the WG last call on this doc wasn't going to close for another three days. http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00391.html -- 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 Thu Mar 10 05:41:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00354 for ; Thu, 10 Mar 2005 05:41:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9L3g-0006kb-RD for namedroppers-data@psg.com; Thu, 10 Mar 2005 10:38:24 +0000 Received: from [212.69.37.4] (helo=buffy.gnomon.org.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9L3f-0006kJ-4X for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 10:38:23 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by buffy.gnomon.org.uk (8.13.1/8.13.1) with ESMTP id j2AAc9DW071476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Mar 2005 10:38:14 GMT (envelope-from roy+dated+1113043095.5b0837@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.2/8.13.0) with ESMTP id j2AAcF9J044510 for ; Thu, 10 Mar 2005 10:38:15 GMT (envelope-from roy+dated+1113043095.5b0837@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.2/8.13.0/Submit) id j2AAcFpB044504 for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 10:38:15 GMT (envelope-from roy+dated+1113043095.5b0837@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 10 Mar 2005 10:38:11 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16944.9107.103627.602775@giles.gnomon.org.uk> Date: Thu, 10 Mar 2005 10:38:11 +0000 To: Roy Arends Cc: Roy Badami , namedroppers@ops.ietf.org Subject: NSEC3 (was: DNSSECbis question (authenticated denial)) In-Reply-To: References: <16942.55022.2320.731606@giles.gnomon.org.uk> <16942.58524.788818.947885@giles.gnomon.org.uk> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (buffy.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.80/752/Mon Mar 7 16:40:04 2005 clamav-milter version 0.80j on buffy.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy> You're not confused. You have found a major oversight in the Roy> dnssec-bis -protocol draft. Oh well... Anyway, here is why I was thinking about this... With NSEC, the proof that there is no delegation ends up being kind of implicit, at least for the nameserver. A MITM would necessarily reveal the presence of the delegation when proving that there is no wildcard under it, so the nameserver doesn't need to do anything special to prove the lack of delegation in its responses. However this only works because the place where the wildcard would fall is always adjacent to its parent label in canonical order (ie if a.com is a delegation, then the NSEC record proving there is no wildcard *.a.com will always have a.com as its owner name). However once you hash the entire owner name, this ceases to be the case -- any number of other names could hash between a.com and *.a.com. So an NSEC3 nameserver will have to explicitly prove the non-existence of an NS record at each label up to the closest non-empty encloser by returning the appropriate NSEC3 record of each parent label. In the case of opt-in, you still want to do this, to prove there is no secure delegation above the query name, in order to prevent a MITM attack similar to the one in my previous mail. -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 Mar 10 05:44:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00538 for ; Thu, 10 Mar 2005 05:44:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9L82-0007KF-EO for namedroppers-data@psg.com; Thu, 10 Mar 2005 10:42:54 +0000 Received: from [212.69.37.4] (helo=buffy.gnomon.org.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9L81-0007K2-Hb for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 10:42:53 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by buffy.gnomon.org.uk (8.13.1/8.13.1) with ESMTP id j2AAgeZT071497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Mar 2005 10:42:45 GMT (envelope-from roy+dated+1113043366.ee3c1c@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.2/8.13.0) with ESMTP id j2AAgkGR044619 for ; Thu, 10 Mar 2005 10:42:46 GMT (envelope-from roy+dated+1113043366.ee3c1c@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.2/8.13.0/Submit) id j2AAgkoI044618 for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 10:42:46 GMT (envelope-from roy+dated+1113043366.ee3c1c@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 10 Mar 2005 10:42:45 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16944.9381.287214.23244@giles.gnomon.org.uk> Date: Thu, 10 Mar 2005 10:42:45 +0000 To: Roy Badami Cc: Roy Arends , namedroppers@ops.ietf.org Subject: NSEC3 (was: DNSSECbis question (authenticated denial)) In-Reply-To: <16944.9107.103627.602775@giles.gnomon.org.uk> References: <16942.55022.2320.731606@giles.gnomon.org.uk> <16942.58524.788818.947885@giles.gnomon.org.uk> <16944.9107.103627.602775@giles.gnomon.org.uk> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (buffy.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.80/752/Mon Mar 7 16:40:04 2005 clamav-milter version 0.80j on buffy.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy> So an NSEC3 nameserver will have to explicitly prove the Roy> non-existence of an NS record at each label up to the closest Roy> non-empty encloser by returning the appropriate NSEC3 record Roy> of each parent label. Oops, that dosn't make sense. Let me try again... An NSEC3 nameserver will have to explictly prove the non-existence of an NS record at each label up to and including the closest encloser, by returning appropriate covering NSEC3 records. -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 Mar 10 10:16:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23748 for ; Thu, 10 Mar 2005 10:16:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9PKz-000Htr-Fj for namedroppers-data@psg.com; Thu, 10 Mar 2005 15:12:33 +0000 Received: from [12.168.96.11] (helo=s-utl01-slpop.stsn.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D9PKy-000Htd-IY for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 15:12:32 +0000 Received: from slpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-slpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2005031008123116746 for ; Thu, 10 Mar 2005 08:12:31 -0700 Received: from ernie.secret-wg.org ([10.84.118.153]) by slpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Mar 2005 08:12:31 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 07BE7151260 for ; Thu, 10 Mar 2005 09:11:58 -0600 (CST) Message-ID: <423063BD.4040504@ripe.net> Date: Thu, 10 Mar 2005 09:11:57 -0600 From: "Olaf M. Kolkman" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers Subject: Re: DNSSECbis question (authenticated denial) References: <16942.55022.2320.731606@giles.gnomon.org.uk> <16942.58524.788818.947885@giles.gnomon.org.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2005 15:12:31.0949 (UTC) FILETIME=[94EDE7D0:01C52583] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Badami wrote: >> >>Clearly the NSEC RR indicates I've been spoofed; the presence of NS >>records at a.com indicates that there is a delegation there. >> >>However it seems to me that a naive implementation of a resolver >>according to -protocol section 5.4 might accept this proof, since it >>both proves that b.a.com does not exist in the zone, and that no >>relevent wildcard exists in the zone, which is all that -protocol >>instructs resolvers to verify. >> >>I could just be confused though ;-) >> >> > > > Roy Arends acknowledged: >You're not confused. You have found a major oversight in the dnssec-bis >-protocol draft. > >We'll need to add text in section 5.4 and possible other sections that a >security aware resolver MUST check the absence of the NS bit and the >DNAME bit. > > > Roy B, this is a good catch! It is very tempting to fix this in AUTH48. Actually thre are a few other things that could be addressed in AUTH48 too, such as the "protocol violation" that white lies cause. But I am very hesitative to touch the documents. When Sam Weiler came up with a few nits a week or two ago, I asked him if he could live with documenting them in an "DNSSEC Implementation Notes I-D". My motivation for this approach is that the class of nits that are found now are typically the things that are fixed when a document is advanced from proposed to draft standard. It would not surprise me if we were to find more places where we have to clarify behaviour or even stretch normative language when we get more experience with implementing and running the protocol. The issue that Roy B. brought up is not a "protocol-bug" but text that is worthy to be highlighted in an implementation note. I propose _not_ to touch the DNSSECbis document set (which are at the top of the RFC queue so the timescale on which they will apear is going to be weeks instead of months) but document this issue in the I-D that Weiler will be editing (see http://www.ietf.org/internet-drafts/draft-weiler-dnsext-dnssec-bis-updates-00.txt). The idea is to keep this document around for a year or two, untill we have seen multiple implementations operated in the field, and then use the document, together with interoperability reports, to move DNSSECbis from proposed to draft. Please speak up if you think this is not a good approach and/or the 'implementation notes' document should not become a working group document. --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 Thu Mar 10 10:18:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24025 for ; Thu, 10 Mar 2005 10:18:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9PPF-000IHy-8J for namedroppers-data@psg.com; Thu, 10 Mar 2005 15:16:57 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9PPE-000IHi-Bd for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 15:16:56 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2AFGo3l007647; Thu, 10 Mar 2005 10:16:50 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.1.2.2.20050310100854.02bcf298@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 10 Mar 2005 10:16:24 -0500 To: Samuel Weiler , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: DNSEXT WGLC Summary: TSIG SHA1 document Cc: namedroppers@ops.ietf.org In-Reply-To: References: <6.2.1.2.2.20050309172309.02d4c7c8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:55 10/03/2005, Samuel Weiler wrote: > > The working group last call has concluded. > >I'm confused. Perhaps you can explain. Yes, I'm wrong, we originally scheduled the LC to conclude the day before the WG meeting and I forgot to update my calendar when we changed the deadline. >I thought the WG last call on this doc wasn't going to close for >another three days. > >http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00391.html > >-- Sam So my list posted is the changes that are needed at this point, and we have enough support to advance the document unless number of people speak up against the document in the next 3 days. sorry about the confusion -- 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 Mar 10 10:42:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26763 for ; Thu, 10 Mar 2005 10:42:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9PmH-000KbJ-Hl for namedroppers-data@psg.com; Thu, 10 Mar 2005 15:40:45 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9PmG-000Kb1-G4 for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 15:40:44 +0000 Received: from [IPv6???1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id B4D9C33C45; Thu, 10 Mar 2005 15:40:40 +0000 (GMT) Message-ID: <42305C51.1060308@algroup.co.uk> Date: Thu, 10 Mar 2005 14:40:17 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Badami Cc: Roy Arends , namedroppers@ops.ietf.org Subject: Re: NSEC3 References: <16942.55022.2320.731606@giles.gnomon.org.uk> <16942.58524.788818.947885@giles.gnomon.org.uk> <16944.9107.103627.602775@giles.gnomon.org.uk> In-Reply-To: <16944.9107.103627.602775@giles.gnomon.org.uk> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Badami wrote: > Roy> You're not confused. You have found a major oversight in the > Roy> dnssec-bis -protocol draft. > > Oh well... > > Anyway, here is why I was thinking about this... > > With NSEC, the proof that there is no delegation ends up being kind of > implicit, at least for the nameserver. A MITM would necessarily > reveal the presence of the delegation when proving that there is no > wildcard under it, so the nameserver doesn't need to do anything > special to prove the lack of delegation in its responses. > > However this only works because the place where the wildcard would > fall is always adjacent to its parent label in canonical order (ie if > a.com is a delegation, then the NSEC record proving there is no > wildcard *.a.com will always have a.com as its owner name). > > However once you hash the entire owner name, this ceases to be the > case -- any number of other names could hash between a.com and > *.a.com. > > So an NSEC3 nameserver will have to explicitly prove the non-existence > of an NS record at each label up to the closest non-empty encloser by > returning the appropriate NSEC3 record of each parent label. No, because there should be no records below the NS record in the parent zone, so if there is an NS, it will be at the closest encloser. The same argument applies to NSEC, as far as I can see. > In the case of opt-in, you still want to do this, to prove there is no > secure delegation above the query name, in order to prevent a MITM > attack similar to the one in my previous mail. I'm less sure about the opt-in situation. Thinking about it. -- 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 Mar 10 12:13:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07257 for ; Thu, 10 Mar 2005 12:13:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9RBC-0006mJ-H1 for namedroppers-data@psg.com; Thu, 10 Mar 2005 17:10:34 +0000 Received: from [13.13.138.218] (helo=wbmler3.mail.xerox.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1D9RBB-0006m6-Jy for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 17:10:33 +0000 Received: from wbmlir3.mail.xerox.com (wbmlir3.mail.xerox.com [13.131.8.223]) by wbmler3.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2AHA1Rb018690; Thu, 10 Mar 2005 12:10:14 -0500 Received: from wbmlir3.mail.xerox.com (localhost [127.0.0.1]) by wbmlir3.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2AH9RQR015976; Thu, 10 Mar 2005 12:09:27 -0500 Received: from usa0300gw04.na.xerox.net (usa0300gw04.na.xerox.net [13.129.0.46]) by wbmlir3.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2AH9QX9015966; Thu, 10 Mar 2005 12:09:27 -0500 Received: from usa0300ms03.na.xerox.net ([13.135.34.12]) by usa0300gw04.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Mar 2005 12:08:28 -0500 Received: from mail pickup service by usa0300ms03.na.xerox.net with Microsoft SMTPSVC; Thu, 10 Mar 2005 12:08:11 -0500 Received: from usa0300bh02.na.xerox.net ([13.129.0.50]) by usa0300ms03.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Mar 2005 08:45:59 -0500 Received: from wbmlir2.mail.xerox.com ([13.131.8.222]) by usaxeroxbh1.USA.XEROX.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FD0DRMAC; Thu, 10 Mar 2005 05:46:07 -0500 Received: from wbmler1.mail.xerox.com (localhost [127.0.0.1]) by wbmlir2.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2AAj3fw012371 for ; Thu, 10 Mar 2005 05:45:05 -0500 Received: from wbmler1.mail.xerox.com (localhost [127.0.0.1]) by wbmler1.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2AAhQUU032638 for ; Thu, 10 Mar 2005 05:43:26 -0500 Received: from psg.com (psg.com [147.28.0.62]) by wbmler1.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2AAhP95032631 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 10 Mar 2005 05:43:26 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9L3g-0006kb-RD for namedroppers-data@psg.com; Thu, 10 Mar 2005 10:38:24 +0000 MIME-Version: 1.0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary Received: from [212.69.37.4] (helo=buffy.gnomon.org.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9L3f-0006kJ-4X for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 10:38:23 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by buffy.gnomon.org.uk (8.13.1/8.13.1) with ESMTP id j2AAc9DW071476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Mar 2005 10:38:14 GMT (envelope-from roy+dated+1113043095.5b0837@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.2/8.13.0) with ESMTP id j2AAcF9J044510 for ; Thu, 10 Mar 2005 10:38:15 GMT (envelope-from roy+dated+1113043095.5b0837@giles.gnomon.org.uk) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.2/8.13.0/Submit) id j2AAcFpB044504 for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 10:38:15 GMT (envelope-from roy+dated+1113043095.5b0837@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 10 Mar 2005 10:38:11 +0000 (GMT) in-reply-to: X-Mailer: VM 7.19 under Emacs 21.3.1 x-virus-scanned: ClamAV 0.80/752/Mon Mar 7 16:40:04 2005 clamav-milter version 0.80j on buffy.gnomon.org.uk x-brightmail-flag: NO x-envelope-trace: wbmler1.j2AAhQUU032638 x-envelope-from: Content-Class: urn:content-classes:message Subject: NSEC3 (was: DNSSECbis question (authenticated denial)) Date: Thu, 10 Mar 2005 05:38:11 -0500 Message-ID: <16944.9107.103627.602775@giles.gnomon.org.uk> X-MS-TNEF-Correlator: <16944.9107.103627.602775@giles.gnomon.org.uk> Thread-Topic: NSEC3 (was: DNSSECbis question (authenticated denial)) thread-index: AcUlXl5Z9FL7b9ejQ26UGaY+015Fhg== From: "Roy Badami" To: "Roy Arends" Cc: "Roy Badami" , X-OriginalArrivalTime: 10 Mar 2005 13:45:59.0272 (UTC) FILETIME=[7DDA4680:01C52577] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: binary xŸ>"; €¤ä€ó Àset2 ã €† Q ðd up bþe(R(A Ày¿ô @*Å0Án2P¿.Q*Ã,‰'` ð+v(Rï+~ôð2 ±FB `-°E1 8Pß PþrW‘Tó!AH”<³3QFQ¿ 1‚IU@=’ ÁcE ' m_B3P¿,ðÐ 1$;R-`?2ÕôW@ô:ñàsu¾bòV14! 2bg^c¿0’#àg ÀÐi: ô}…Ð -- 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 Mar 10 12:13:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07321 for ; Thu, 10 Mar 2005 12:13:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9RB5-0006lw-SO for namedroppers-data@psg.com; Thu, 10 Mar 2005 17:10:27 +0000 Received: from [13.13.138.218] (helo=wbmler3.mail.xerox.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1D9RB2-0006lZ-LQ for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 17:10:24 +0000 Received: from wbmlir3.mail.xerox.com (wbmlir3.mail.xerox.com [13.131.8.223]) by wbmler3.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2AHA1wR018684; Thu, 10 Mar 2005 12:10:13 -0500 Received: from wbmlir3.mail.xerox.com (localhost [127.0.0.1]) by wbmlir3.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2AH98l2015519; Thu, 10 Mar 2005 12:09:08 -0500 Received: from usa0300gw03.na.xerox.net (usa0300gw03.na.xerox.net [13.129.0.44]) by wbmlir3.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2AH98kZ015479; Thu, 10 Mar 2005 12:09:08 -0500 Received: from usa0300ms03.na.xerox.net ([13.135.34.12]) by usa0300gw03.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Mar 2005 12:08:28 -0500 Received: from mail pickup service by usa0300ms03.na.xerox.net with Microsoft SMTPSVC; Thu, 10 Mar 2005 12:08:23 -0500 Received: from usa0300bh02.na.xerox.net ([13.129.0.50]) by usa0300ms03.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Mar 2005 08:46:02 -0500 Received: from wvmlir1.mail.xerox.com ([13.147.8.221]) by usaxeroxbh2.MC.USA.XEROX.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GDFZZFSN; Thu, 10 Mar 2005 05:48:06 -0500 Received: from wvmler3.mail.xerox.com (localhost [127.0.0.1]) by wvmlir1.mail.xerox.com (8.13.2/8.13.1) with ESMTP id j2AAl21E011963 for ; Thu, 10 Mar 2005 02:47:02 -0800 Received: from wvmler3.mail.xerox.com (localhost [127.0.0.1]) by wvmler3.mail.xerox.com (8.13.2/8.13.1) with ESMTP id j2AAjFer023714 for ; Thu, 10 Mar 2005 02:45:15 -0800 Received: from psg.com (psg.com [147.28.0.62]) by wvmler3.mail.xerox.com (8.13.2/8.13.1) with ESMTP id j2AAjEUR023695 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 10 Mar 2005 02:45:15 -0800 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9L82-0007KF-EO for namedroppers-data@psg.com; Thu, 10 Mar 2005 10:42:54 +0000 MIME-Version: 1.0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary Received: from [212.69.37.4] (helo=buffy.gnomon.org.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9L81-0007K2-Hb for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 10:42:53 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by buffy.gnomon.org.uk (8.13.1/8.13.1) with ESMTP id j2AAgeZT071497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Mar 2005 10:42:45 GMT (envelope-from roy+dated+1113043366.ee3c1c@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.2/8.13.0) with ESMTP id j2AAgkGR044619 for ; Thu, 10 Mar 2005 10:42:46 GMT (envelope-from roy+dated+1113043366.ee3c1c@giles.gnomon.org.uk) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.2/8.13.0/Submit) id j2AAgkoI044618 for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 10:42:46 GMT (envelope-from roy+dated+1113043366.ee3c1c@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 10 Mar 2005 10:42:45 +0000 (GMT) in-reply-to: <16944.9107.103627.602775@giles.gnomon.org.uk> X-Mailer: VM 7.19 under Emacs 21.3.1 x-virus-scanned: ClamAV 0.80/752/Mon Mar 7 16:40:04 2005 clamav-milter version 0.80j on buffy.gnomon.org.uk x-brightmail-flag: NO x-envelope-trace: wvmler3.j2AAjFer023714 x-envelope-from: Content-Class: urn:content-classes:message Subject: NSEC3 (was: DNSSECbis question (authenticated denial)) Date: Thu, 10 Mar 2005 05:42:45 -0500 Message-ID: <16944.9381.287214.23244@giles.gnomon.org.uk> X-MS-TNEF-Correlator: <16944.9381.287214.23244@giles.gnomon.org.uk> Thread-Topic: NSEC3 (was: DNSSECbis question (authenticated denial)) thread-index: AcUlXqT92yAx4yOtTH6blmLXZ0ZVkg== From: "Roy Badami" To: "Roy Badami" Cc: "Roy Arends" , X-OriginalArrivalTime: 10 Mar 2005 13:46:02.0429 (UTC) FILETIME=[7FBBFED0:01C52577] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: binary xŸ>" €¤ä€ó Àset2 ã €& Q ± ð@$³.ôeôO)s,!!$1dÙ%Ðn'@ P"À@-á.ý ÀÐBi2°: ô}M@ s -- 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 Mar 10 12:14:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07522 for ; Thu, 10 Mar 2005 12:14:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9RCm-0006xZ-Mr for namedroppers-data@psg.com; Thu, 10 Mar 2005 17:12:12 +0000 Received: from [13.13.138.218] (helo=wbmler3.mail.xerox.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1D9RCl-0006x8-T9 for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 17:12:12 +0000 Received: from wbmlir3.mail.xerox.com (wbmlir3.mail.xerox.com [13.131.8.223]) by wbmler3.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2AHC162020696; Thu, 10 Mar 2005 12:12:07 -0500 Received: from wbmlir3.mail.xerox.com (localhost [127.0.0.1]) by wbmlir3.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2AHBmWD017803; Thu, 10 Mar 2005 12:11:48 -0500 Received: from usa0300gw04.na.xerox.net (usa0300gw04.na.xerox.net [13.129.0.46]) by wbmlir3.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2AHBZqa017560; Thu, 10 Mar 2005 12:11:44 -0500 Received: from usa0300ms03.na.xerox.net ([13.135.34.12]) by usa0300gw04.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Mar 2005 12:11:34 -0500 Received: from mail pickup service by usa0300ms03.na.xerox.net with Microsoft SMTPSVC; Thu, 10 Mar 2005 12:11:18 -0500 Received: from usa0300bh01.na.xerox.net ([13.129.0.48]) by usa0300ms03.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Mar 2005 09:08:42 -0500 Received: from wbmlir3.mail.xerox.com ([13.131.8.223]) by usaxeroxbh1.USA.XEROX.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FD0DR2B1; Thu, 10 Mar 2005 02:07:01 -0500 Received: from wbmler3.mail.xerox.com (localhost [127.0.0.1]) by wbmlir3.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2A762cV018093 for ; Thu, 10 Mar 2005 02:06:04 -0500 MIME-Version: 1.0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary Received: from wbmler3.mail.xerox.com (localhost [127.0.0.1]) by wbmler3.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2A74umV011906 for ; Thu, 10 Mar 2005 02:04:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: from psg.com (psg.com [147.28.0.62]) by wbmler3.mail.xerox.com (8.13.1/8.13.1) with ESMTP id j2A74t05011893 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 10 Mar 2005 02:04:56 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9HcC-0007li-3A for namedroppers-data@psg.com; Thu, 10 Mar 2005 06:57:48 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9Hc8-0007kE-RU for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 06:57:45 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2A6s7fM023719 for ; Thu, 10 Mar 2005 01:54:07 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKYaOuU; Thu, 10 Mar 05 01:54:05 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j2A6to9x009025; Thu, 10 Mar 2005 01:55:50 -0500 (EST) in-reply-to: <6.2.1.2.2.20050309172309.02d4c7c8@localhost> X-Envelope-From: X-Brightmail-Flag: NO X-Envelope-Trace: wbmler3.j2A74umV011906 Content-Class: urn:content-classes:message Subject: Re: DNSEXT WGLC Summary: TSIG SHA1 document Date: Thu, 10 Mar 2005 01:55:50 -0500 Message-ID: X-MS-TNEF-Correlator: Thread-Topic: DNSEXT WGLC Summary: TSIG SHA1 document thread-index: AcUlP8JQ+68lLzxbTaWMUhWJifdarA== From: "Samuel Weiler" To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT__co-chair?= Cc: X-OriginalArrivalTime: 10 Mar 2005 14:08:42.0171 (UTC) FILETIME=[AA3428B0:01C5257A] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: binary xŸ>") €¤ä€ó Àset2 @ ¢ „‘ €I'mfu± Pàp ~y`q À S¬ äth`gh@#À0´}=€ -- 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 Mar 10 12:14:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07646 for ; Thu, 10 Mar 2005 12:14:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9RD5-00070s-2E for namedroppers-data@psg.com; Thu, 10 Mar 2005 17:12:31 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9RD4-00070a-88 for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 17:12:30 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A3BAF13E3F; Thu, 10 Mar 2005 17:12:29 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Ben Laurie Cc: Roy Badami , Roy Arends , namedroppers@ops.ietf.org Subject: Re: NSEC3 In-Reply-To: Message from Ben Laurie of "Thu, 10 Mar 2005 14:40:17 GMT." <42305C51.1060308@algroup.co.uk> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 10 Mar 2005 17:12:29 +0000 Message-Id: <20050310171229.A3BAF13E3F@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > So an NSEC3 nameserver will have to explicitly prove the non-existence > > of an NS record at each label up to the closest non-empty encloser by > > returning the appropriate NSEC3 record of each parent label. > > No, because there should be no records below the NS record in the parent > zone, so if there is an NS, it will be at the closest encloser. The same > argument applies to NSEC, as far as I can see. i don't think this holds. the parent can contain in-child glue, which will never appear in answer sections. this is how zones are "reachable" even if all nameservers are in-zone or below-zone. that means $ORIGIN . net NS a.gtld-servers.net. a.gtld-servers.net. A i.p.v.4 -- 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 Mar 10 12:36:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09884 for ; Thu, 10 Mar 2005 12:36:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9RYk-0009cC-U3 for namedroppers-data@psg.com; Thu, 10 Mar 2005 17:34:54 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9RYk-0009bv-0q for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 17:34:54 +0000 Received: from [IPv6???1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 3120333C45; Thu, 10 Mar 2005 17:34:51 +0000 (GMT) Message-ID: <42307714.50809@algroup.co.uk> Date: Thu, 10 Mar 2005 16:34:28 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie Cc: Roy Badami , Roy Arends , namedroppers@ops.ietf.org Subject: Re: NSEC3 References: <20050310171229.A3BAF13E3F@sa.vix.com> In-Reply-To: <20050310171229.A3BAF13E3F@sa.vix.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>So an NSEC3 nameserver will have to explicitly prove the non-existence >>>of an NS record at each label up to the closest non-empty encloser by >>>returning the appropriate NSEC3 record of each parent label. >> >>No, because there should be no records below the NS record in the parent >>zone, so if there is an NS, it will be at the closest encloser. The same >>argument applies to NSEC, as far as I can see. > > > i don't think this holds. the parent can contain in-child glue, which > will never appear in answer sections. this is how zones are "reachable" > even if all nameservers are in-zone or below-zone. that means > > $ORIGIN . > net NS a.gtld-servers.net. > a.gtld-servers.net. A i.p.v.4 Glue records are not authoritative, so they don't appear in NSEC(3)s. Cheers, Ben. -- 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 Mar 10 18:11:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18339 for ; Thu, 10 Mar 2005 18:11:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9WiZ-0006ft-8F for namedroppers-data@psg.com; Thu, 10 Mar 2005 23:05:23 +0000 Received: from [212.69.37.4] (helo=buffy.gnomon.org.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9WiX-0006fR-Iv for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 23:05:21 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by buffy.gnomon.org.uk (8.13.1/8.13.1) with ESMTP id j2AN56sO074466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Mar 2005 23:05:11 GMT (envelope-from roy+dated+1113087913.e46360@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.2/8.13.0) with ESMTP id j2AN5DFv048755 for ; Thu, 10 Mar 2005 23:05:13 GMT (envelope-from roy+dated+1113087913.e46360@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.2/8.13.0/Submit) id j2AN5DOB048752 for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 23:05:13 GMT (envelope-from roy+dated+1113087913.e46360@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 10 Mar 2005 23:05:06 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16944.53922.293156.623714@giles.gnomon.org.uk> Date: Thu, 10 Mar 2005 23:05:06 +0000 To: Ben Laurie Cc: Roy Badami , Roy Arends , namedroppers@ops.ietf.org Subject: Re: NSEC3 In-Reply-To: <42305C51.1060308@algroup.co.uk> References: <16942.55022.2320.731606@giles.gnomon.org.uk> <16942.58524.788818.947885@giles.gnomon.org.uk> <16944.9107.103627.602775@giles.gnomon.org.uk> <42305C51.1060308@algroup.co.uk> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (buffy.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.80/752/Mon Mar 7 16:40:04 2005 clamav-milter version 0.80j on buffy.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben> No, because there should be no records below the NS record in Ben> the parent zone, so if there is an NS, it will be at the Ben> closest encloser. The same argument applies to NSEC, as far Ben> as I can see. Indeed there shouldn't. So presenting an NSEC record that proves that such a name exists proves that the delegation doesn't. DNSSECbis non-existence proofs implicitly rely on this. When I query for a.b.c.d.e and get the response: _.b.c.d.e. NSEC aa.b.c.d.e. A this implicitly proves to me that no delegation exists between the name I queried for and the zone apex, because if it did then the NSEC owner name and target name wouldn't be in-zone. When I query for a.c.d.e.e and get the response: b.c.d.e. NSEC aa.b.c.d.e. A this explicitly proves to me that b.c.d.e is not a delegations point (no NS record) and implictly proves that there is no delegation between b.c.d.e and the zone apex, for the same reason. So with DNSSECbis the set of NSEC records you construct to prove that there is no relevent wildcard that could have matched also happen to prove that there is no delegation for which you should have received a referal. Since the NSEC3 records are ordered by hash, not original owner name (I think) it seems to me that you don't get this proof for free, and have to explictly provide covering NSEC3 records for all the places a delegation could have existed, to prove that it doesn't. But I haven't thought about this deeply, and could be mistaken... -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 Mar 10 18:15:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19088 for ; Thu, 10 Mar 2005 18:15:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9WqU-0007nZ-UO for namedroppers-data@psg.com; Thu, 10 Mar 2005 23:13:34 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9WqT-0007nH-OG for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 23:13:34 +0000 Received: from [IPv6???1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id D981C33C45; Thu, 10 Mar 2005 23:13:30 +0000 (GMT) Message-ID: <4230C672.1040508@algroup.co.uk> Date: Thu, 10 Mar 2005 22:13:06 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Badami Cc: Roy Arends , namedroppers@ops.ietf.org Subject: Re: NSEC3 References: <16942.55022.2320.731606@giles.gnomon.org.uk> <16942.58524.788818.947885@giles.gnomon.org.uk> <16944.9107.103627.602775@giles.gnomon.org.uk> <42305C51.1060308@algroup.co.uk> <16944.53922.293156.623714@giles.gnomon.org.uk> In-Reply-To: <16944.53922.293156.623714@giles.gnomon.org.uk> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Badami wrote: > Ben> No, because there should be no records below the NS record in > Ben> the parent zone, so if there is an NS, it will be at the > Ben> closest encloser. The same argument applies to NSEC, as far > Ben> as I can see. > > Indeed there shouldn't. So presenting an NSEC record that proves that > such a name exists proves that the delegation doesn't. DNSSECbis > non-existence proofs implicitly rely on this. > > When I query for a.b.c.d.e and get the response: > > _.b.c.d.e. NSEC aa.b.c.d.e. A > > this implicitly proves to me that no delegation exists between the > name I queried for and the zone apex, because if it did then the NSEC > owner name and target name wouldn't be in-zone. > > When I query for a.c.d.e.e and get the response: > > b.c.d.e. NSEC aa.b.c.d.e. A > > this explicitly proves to me that b.c.d.e is not a delegations point > (no NS record) and implictly proves that there is no delegation > between b.c.d.e and the zone apex, for the same reason. > > So with DNSSECbis the set of NSEC records you construct to prove that > there is no relevent wildcard that could have matched also happen to > prove that there is no delegation for which you should have received a > referal. > > Since the NSEC3 records are ordered by hash, not original owner name > (I think) it seems to me that you don't get this proof for free, and > have to explictly provide covering NSEC3 records for all the places a > delegation could have existed, to prove that it doesn't. > > But I haven't thought about this deeply, and could be mistaken... I believe that since NSEC3 also shows the record at the closest encloser, the same check works. -- 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 Mar 10 18:24:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20332 for ; Thu, 10 Mar 2005 18:24:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9Wzk-00093M-1O for namedroppers-data@psg.com; Thu, 10 Mar 2005 23:23:08 +0000 Received: from [212.69.37.4] (helo=buffy.gnomon.org.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9Wzi-000932-V2 for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 23:23:07 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by buffy.gnomon.org.uk (8.13.1/8.13.1) with ESMTP id j2ANMqb4074538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Mar 2005 23:22:57 GMT (envelope-from roy+dated+1113088979.71fcb5@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.2/8.13.0) with ESMTP id j2ANN0bi048876 for ; Thu, 10 Mar 2005 23:23:00 GMT (envelope-from roy+dated+1113088979.71fcb5@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.2/8.13.0/Submit) id j2ANMxlY048875 for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 23:22:59 GMT (envelope-from roy+dated+1113088979.71fcb5@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 10 Mar 2005 23:22:58 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16944.54994.247339.361660@giles.gnomon.org.uk> Date: Thu, 10 Mar 2005 23:22:58 +0000 To: "Olaf M. Kolkman" Cc: namedroppers Subject: Re: DNSSECbis question (authenticated denial) In-Reply-To: <423063BD.4040504@ripe.net> References: <16942.55022.2320.731606@giles.gnomon.org.uk> <16942.58524.788818.947885@giles.gnomon.org.uk> <423063BD.4040504@ripe.net> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (buffy.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.80/752/Mon Mar 7 16:40:04 2005 clamav-milter version 0.80j on buffy.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf> The issue that Roy B. brought up is not a "protocol-bug" Olaf> but text that is worthy to be highlighted in an Olaf> implementation note. Hmm, I think it's borderline, but it feels like a protocol bug to me. At the moment a resolver could fail to check that the NS and DNAME bits are clear, and still be conformant with -protocol. Which means that the protocol specified in that document has a security flaw. Sure, it may be obvious to you guys who designed the protocol that you always _meant_ for the resolver to check that, so it's just an editorial bug to you. But that's not the way it seems to someone coming to the documents without the history... That said, I understand the desire not to mess with the documents at this late stage, and there are other aspects of the non-existence and wildcard proofs that took me a long time to figure out just from -protocol (and I'm still not sure I've got them right) so maybe a new document is pragmatically the right place to document these issues. (I'll post about the bits I find unclear shortly, though it will be a couple of days before I have time...) Olaf> The idea is to keep this document around for a year or two, Olaf> untill we have seen multiple implementations operated in the Olaf> field, and then use the document, together with Olaf> interoperability reports, to move DNSSECbis from proposed to Olaf> draft. I would suggest that, depending on the number and significance of issues, an initial version should be advanced as an informational RFC _much_ sooner than that, maybe a early as a matter of months after publication of DNSSECbis as RFC.... -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 Mar 10 18:29:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20858 for ; Thu, 10 Mar 2005 18:29:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9X4v-0009ZW-VO for namedroppers-data@psg.com; Thu, 10 Mar 2005 23:28:29 +0000 Received: from [212.69.37.4] (helo=buffy.gnomon.org.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9X4v-0009ZG-3R for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 23:28:29 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by buffy.gnomon.org.uk (8.13.1/8.13.1) with ESMTP id j2ANSEUG074557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Mar 2005 23:28:20 GMT (envelope-from roy+dated+1113089302.83f9ee@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.2/8.13.0) with ESMTP id j2ANSMYl048925 for ; Thu, 10 Mar 2005 23:28:22 GMT (envelope-from roy+dated+1113089302.83f9ee@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.2/8.13.0/Submit) id j2ANSM9O048922 for namedroppers@ops.ietf.org; Thu, 10 Mar 2005 23:28:22 GMT (envelope-from roy+dated+1113089302.83f9ee@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 10 Mar 2005 23:28:20 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16944.55316.333600.996850@giles.gnomon.org.uk> Date: Thu, 10 Mar 2005 23:28:20 +0000 To: Ben Laurie Cc: Roy Badami , Roy Arends , namedroppers@ops.ietf.org Subject: Re: NSEC3 In-Reply-To: <4230C672.1040508@algroup.co.uk> References: <16942.55022.2320.731606@giles.gnomon.org.uk> <16942.58524.788818.947885@giles.gnomon.org.uk> <16944.9107.103627.602775@giles.gnomon.org.uk> <42305C51.1060308@algroup.co.uk> <16944.53922.293156.623714@giles.gnomon.org.uk> <4230C672.1040508@algroup.co.uk> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (buffy.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.80/752/Mon Mar 7 16:40:04 2005 clamav-milter version 0.80j on buffy.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben> I believe that since NSEC3 also shows the record at the Ben> closest encloser, the same check works. But what about names between the query name and the closest encloser? Don't you need to not only prove that a wildcard doesn't exist at each of those names, but also that a delegation doesn't exist at each of those names? The same NSEC3 record won't generally cover the wildcard and the NS record. -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 Mar 10 19:45:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26210 for ; Thu, 10 Mar 2005 19:45:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9YEc-000HO4-9b for namedroppers-data@psg.com; Fri, 11 Mar 2005 00:42:34 +0000 Received: from [212.69.37.4] (helo=buffy.gnomon.org.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9YEZ-000HNf-6H for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 00:42:31 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by buffy.gnomon.org.uk (8.13.1/8.13.1) with ESMTP id j2B0gGaw074837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 11 Mar 2005 00:42:21 GMT (envelope-from roy+dated+1113093743.a1b46f@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.2/8.13.0) with ESMTP id j2B0gNsi049192 for ; Fri, 11 Mar 2005 00:42:23 GMT (envelope-from roy+dated+1113093743.a1b46f@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.2/8.13.0/Submit) id j2B0gN8t049191 for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 00:42:23 GMT (envelope-from roy+dated+1113093743.a1b46f@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 11 Mar 2005 00:42:23 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16944.59759.232989.579130@giles.gnomon.org.uk> Date: Fri, 11 Mar 2005 00:42:23 +0000 To: namedroppers@ops.ietf.org Subject: Minor editorial NSEC3 comments X-Mailer: VM 7.19 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (buffy.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.80/752/Mon Mar 7 16:40:04 2005 clamav-milter version 0.80j on buffy.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 6.4.2 says.... A collision resistant hash function has a second-preimage resistance property. The second-preimage resistance property means that I am not a cryptographer, but... While true, I don't think this is relevent. I would reword this to say A cryptographic hash function has a ... Collision resistance is another specific property of cyrtographic hashes, namely that it is computationally infeasable to construct a pair of messages that hash to the same value, and AFAICS NSEC3 doesn't actually require a collision resitant hash function. Collision restistance implies second pre-image resitance: if you've managed to break second pre-image resitance then you have necessarily constructed a collision, but second pre-image resitance is a weaker property of a hash than collision resitance. Weaker in the sense that it is possible to break the collision resistance of a hash without breaking second pre-image resistance (ie I may be able to construct one or more pairs of messages that hash to the same value, assuming I get to choose both messages, but that doesn't mean I can construct a message that hashes to the same value as a message _you_ choose... The probability of finding a second preimage is 1 in 2^160 for SHA-1 on average This is clearly not true, unless the adversary simply tries one possible preimage at random and gives up if he hasn't succeeded. Just by trying two random preimages you can increase the probability to 1 in 2^159, and perfoming two SHA-1 operations within a reasonably timeframe is possible even on the most modest of hardware :-) An attacker can clearly attempt a very large number of test hashes, but also cryptanalysis of SHA-1 may allow less computationally intensive attacks than random tests... You can't put a figure on the probability of breaking second preimage resistance; cryptography doesn't work that way. It's conceivable (though incredibly inplausible) that someone (perhaps the NSA?) is capable of producing a second preimage with probablility 1. -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 Mar 10 22:22:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09273 for ; Thu, 10 Mar 2005 22:22:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9acI-0007ys-B5 for namedroppers-data@psg.com; Fri, 11 Mar 2005 03:15:10 +0000 Received: from [208.218.130.11] (helo=gis.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9acH-0007xo-2j for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 03:15:09 +0000 Received: from tecotoo.localhost ([207.7.207.208]) by mx03.gis.net; Thu, 10 Mar 2005 22:14:59 -0500 Received: from tecotoo (tecotoo [127.0.0.1]) by tecotoo.localhost (NTMail 3.03.0017/1.aaaa) with ESMTP id ha001333 for ; Thu, 10 Mar 2005 21:30:45 +0000 Message-Id: <4.3.1.2.20050310212616.0431ec60@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 10 Mar 2005 21:30:37 -0500 To: Roy Arends , namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: an example on wildcard proof. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 02:48 PM 3/8/2005, Roy Arends wrote: >Note that there is no need to prove the nonexistence of >test1.test2.example.com, since test2.example.com does not exist. I'm not sure that that is true. If I add the following A record to the example.com zone: test1.test2 10800 IN A 1.2.3.4 and I don't create any records for test2 does test2.example.com exist, and if I ask won't I get an NXDOMAIN response? Danny -- 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 Mar 11 03:46:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26453 for ; Fri, 11 Mar 2005 03:46:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9fim-000I7J-2c for namedroppers-data@psg.com; Fri, 11 Mar 2005 08:42:12 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9fik-000I6p-0z for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 08:42:10 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id EFB28C2DA4; Fri, 11 Mar 2005 08:42:08 +0000 (GMT) Date: Fri, 11 Mar 2005 08:42:08 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Roy Badami , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: Minor editorial NSEC3 comments Message-ID: <624397D2AA7D72A581503267@[192.168.100.25]> In-Reply-To: <16944.59759.232989.579130@giles.gnomon.org.uk> References: <16944.59759.232989.579130@giles.gnomon.org.uk> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 11 March 2005 00:42 +0000 Roy Badami wrote: > Collision resistance is another specific property of cyrtographic > hashes, namely that it is computationally infeasable to construct a > pair of messages that hash to the same value, and AFAICS NSEC3 doesn't > actually require a collision resitant hash function. > > Collision restistance implies second pre-image resitance: if you've > managed to break second pre-image resitance then you have necessarily > constructed a collision, but second pre-image resitance is a weaker > property of a hash than collision resitance. I think there are actually 2 separate requirements: * Second pre-image resistance - to stop enumeration "the obvious way" (work backwards from the hashes). * Collision resistance - to stop a "nit" in the protocol. This is the one everyone talked about for a ages here. If there isn't collision resistance, then can't an attacker find QNAMEs with the same hash value as labels in the zone? If they do this, we are then left with the problem of what the server should return when a query is made for that (presumably nonexistant) QNAME. I think the consensus was to return an NSEC3 record with the identity (1:1) hash. This enumerates a single label. This isn't dangerous if the main algorithm is collision resistant. No caffeine yet so my brain may not work, but I *think* this means that both collision resistance AND second-preimage resistance are necessary. I think you are right that collision resistance implies second pre-image resistance, but I don't think that's the issue here, as both are required anyway. You are right in another way though: NSEC3 doesn't (well IMHO shouldn't) require ANY of those properties of its hash function, UNLESS you care about enumeration. NSEC3 should be able to cope with ANY function (whatsoever) as the hash function, though the worse hash function it is (and the smaller its range is compared to its domain), the more important a functional fall-back to the identity hash becomes. 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 Mar 11 05:47:53 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06172 for ; Fri, 11 Mar 2005 05:47:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9hdH-0006Md-G0 for namedroppers-data@psg.com; Fri, 11 Mar 2005 10:44:39 +0000 Received: from [204.152.189.154] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9hdE-0006Lz-24 for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 10:44:36 +0000 Received: from guava.araneus.fi ([195.238.197.162]) by gusto.araneus.fi (8.12.10/8.12.10) with ESMTP id j2BAiLqX004884; Fri, 11 Mar 2005 02:44:22 -0800 (PST) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id j2BAiOLG029978; Fri, 11 Mar 2005 12:44:24 +0200 (EET) Received: (from gson@localhost) by guava.araneus.fi (8.12.10/8.12.6/Submit) id j2BAiMuX021442; Fri, 11 Mar 2005 12:44:22 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16945.30342.344183.997781@guava.araneus.fi> Date: Fri, 11 Mar 2005 12:44:22 +0200 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair CC: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: TSIG SHA1 document In-Reply-To: <6.2.1.2.2.20050309172309.02d4c7c8@localhost> References: <6.2.1.2.2.20050309172309.02d4c7c8@localhost> X-Mailer: VM 7.17 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =D3lafur Gu=F0mundsson /DNSEXT co-chair writes: > Following changes/clarifications are needed in the document > before it is advanced. >=20 > #1 Add text saying implementations can reject messages signed by a > particular algorithm even if that algorithm is mandatory to implement= =2E > (important in TKEY environments) I agree that implementations must be allowed to reject messages signed with a mandatory to implement algorithm (that's part of what I meant by "the distinction between implementing an algorithm and having a policy of accepting it"), but what does TKEY have to do with it=3F > #2 Set lower bound on truncation (for each algorithm), > default lower bound is half of original digest. Does this "default lower bound" mean that in the absence of explicit configuration to the contrary, a receiving implementation should accept digests truncated to half the original length=3F If a slave server has an existing agreement with its master to accept zone transfers signed with HMAC-MD5 and is upgraded to conform to the new specification without changing its configuration, will it start accepting transfers signed with HMAC-MD5-truncated-to-64-bits because that's the "default lower bound", thereby becoming 2^64 times easier to attack by brute force and disregarding the administrator's original intent to require 128-bit HMAC-MD5 signatures=3F I don't think that's = a good idea. I find this whole discussion about complicated policies to accept multiple algorithms and ranges of truncation lengths worrisome. Since TSIG is based on mutual agreement, what's wrong with a policy of accepting only messages signed with the exact key, algorithm, and truncation length that were mutually agreed on=3F This is what existin= g TSIG implementations do with respect to the key and algorithm, and I would like this to continue to be the norm and the default behavior. If there has been no explicit agreement regarding truncation, as in the case of agreements predating the draft, the full digest should be sent by the sender and nothing less than the full digest should be accepted by the receiver. > #4 add text if responder can use different truncation than sender > and rules for that. This seems like an unnecessary complication. RFC2845 doesn't allow a response to use an algorithm or key different from the request; why should truncation be treated any differently=3F --=20 Andreas Gustafsson, gson@araneus.fi -- 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 Mar 11 10:35:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04666 for ; Fri, 11 Mar 2005 10:35:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9m6T-000GGA-WE for namedroppers-data@psg.com; Fri, 11 Mar 2005 15:31:06 +0000 Received: from [129.188.136.101] (helo=ftpbox.mot.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9m6R-000GFk-HE for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 15:31:04 +0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j2BFV1CW004260 for ; Fri, 11 Mar 2005 08:31:01 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j2BFVXZN014033 for ; Fri, 11 Mar 2005 09:31:34 -0600 (CST) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id <1LP6PYND>; Fri, 11 Mar 2005 10:30:59 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF238105CD45BB@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: "'gson@araneus.fi'" Cc: namedroppers@ops.ietf.org, =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_/D?= =?iso-8859-1?Q?NSEXT___co-chair?= Subject: RE: DNSEXT WGLC Summary: TSIG SHA1 document Date: Fri, 11 Mar 2005 10:30:58 -0500 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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable See below at @@@ -----Original Message----- From: owner-namedroppers@ops.ietf.org = [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of gson@araneus.fi Sent: Friday, March 11, 2005 5:44 AM To: =D3lafur Gu=F0mundsson /DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: TSIG SHA1 document =D3lafur Gu=F0mundsson /DNSEXT co-chair writes: > Following changes/clarifications are needed in the document > before it is advanced. >=20 > #1 Add text saying implementations can reject messages signed by a > particular algorithm even if that algorithm is mandatory to = implement. > (important in TKEY environments) I agree that implementations must be allowed to reject messages signed with a mandatory to implement algorithm (that's part of what I meant by "the distinction between implementing an algorithm and having a policy of accepting it"), but what does TKEY have to do with it? > #2 Set lower bound on truncation (for each algorithm), > default lower bound is half of original digest. Does this "default lower bound" mean that in the absence of explicit configuration to the contrary, a receiving implementation should accept digests truncated to half the original length? If a slave server has an existing agreement with its master to accept zone transfers signed with HMAC-MD5 and is upgraded to conform to the new specification without changing its configuration, will it start accepting transfers signed with HMAC-MD5-truncated-to-64-bits because that's the "default lower bound", thereby becoming 2^64 times easier to attack by brute force and disregarding the administrator's original intent to require 128-bit HMAC-MD5 signatures? I don't think that's a good idea. @@@ No, the change to the draft will prohibit (MUST NOT) policies that would accept a truncation to less than the greater of 80 bits and half the original digest. I.E., the recommendation currently mentioned in the Security Considerations section will be made mandatory. I find this whole discussion about complicated policies to accept multiple algorithms and ranges of truncation lengths worrisome. Since TSIG is based on mutual agreement, what's wrong with a policy of accepting only messages signed with the exact key, algorithm, and truncation length that were mutually agreed on? This is what existing TSIG implementations do with respect to the key and algorithm, and I would like this to continue to be the norm and the default behavior. If there has been no explicit agreement regarding truncation, as in the case of agreements predating the draft, the full digest should be sent by the sender and nothing less than the full digest should be accepted by the receiver. @@@ Re your paragraph above and paragraph below, the change will be to (1) state that policies SHOULD be implemented such that if a particular runcation would be accepted, a longer signatures (less truncation) SHOULD also be accepted and (2) that if a request is received with a particular truncation, the corresponding reply SHOULD be sent with no less trncation than the request, even if the policy would normally allow greater truncation (shorter signature). These changes did not come out of thin air but were based on the implimentation experience of Mark Andrews. @@@ Donald > #4 add text if responder can use different truncation than sender > and rules for that. This seems like an unnecessary complication. RFC2845 doesn't allow a response to use an algorithm or key different from the request; why should truncation be treated any differently? --=20 Andreas Gustafsson, gson@araneus.fi -- 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 Mar 11 11:00:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07983 for ; Fri, 11 Mar 2005 11:00:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9mWy-000K3v-Ep for namedroppers-data@psg.com; Fri, 11 Mar 2005 15:58:28 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9mWu-000K3A-3z for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 15:58:24 +0000 Received: from [IPv6???1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id CE6C033C33; Fri, 11 Mar 2005 15:58:21 +0000 (GMT) Message-ID: <4231B1F6.70803@algroup.co.uk> Date: Fri, 11 Mar 2005 14:57:58 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Badami Cc: namedroppers@ops.ietf.org Subject: Re: Minor editorial NSEC3 comments References: <16944.59759.232989.579130@giles.gnomon.org.uk> In-Reply-To: <16944.59759.232989.579130@giles.gnomon.org.uk> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Badami wrote: > 6.4.2 says.... > > A collision resistant hash function has a second-preimage resistance > property. The second-preimage resistance property means that > > I am not a cryptographer, but... While true, I don't think this is > relevent. I would reword this to say > > A cryptographic hash function has a ... I managed to miss this one, you are, of course, correct. > Collision resistance is another specific property of cyrtographic > hashes, namely that it is computationally infeasable to construct a > pair of messages that hash to the same value, and AFAICS NSEC3 doesn't > actually require a collision resitant hash function. > > Collision restistance implies second pre-image resitance: if you've > managed to break second pre-image resitance then you have necessarily > constructed a collision, but second pre-image resitance is a weaker > property of a hash than collision resitance. > > Weaker in the sense that it is possible to break the collision > resistance of a hash without breaking second pre-image resistance (ie > I may be able to construct one or more pairs of messages that hash > to the same value, assuming I get to choose both messages, but that > doesn't mean I can construct a message that hashes to the same value > as a message _you_ choose... > > The probability of finding a second preimage is 1 in 2^160 for > SHA-1 on average > > This is clearly not true, unless the adversary simply tries one > possible preimage at random and gives up if he hasn't succeeded. Just > by trying two random preimages you can increase the probability to 1 > in 2^159, and perfoming two SHA-1 operations within a reasonably > timeframe is possible even on the most modest of hardware :-) I thought I'd already fixed this language. > > An attacker can clearly attempt a very large number of test hashes, > but also cryptanalysis of SHA-1 may allow less computationally > intensive attacks than random tests... > > You can't put a figure on the probability of breaking second preimage > resistance; cryptography doesn't work that way. It's conceivable > (though incredibly inplausible) that someone (perhaps the NSA?) is > capable of producing a second preimage with probablility 1. Yes, what we should say is that the work factor for finding a second preimage is of the order of 2^160. Cheers, Ben. -- 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 Mar 11 11:27:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11037 for ; Fri, 11 Mar 2005 11:27:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9mwG-000Mny-Ik for namedroppers-data@psg.com; Fri, 11 Mar 2005 16:24:36 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9mw8-000Mmf-Fq for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 16:24:28 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id D5AE3677FA for ; Fri, 11 Mar 2005 16:24:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j2BGOAKc005469; Sat, 12 Mar 2005 03:24:10 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200503111624.j2BGOAKc005469@drugs.dv.isc.org> To: Alex Bligh Cc: Roy Badami , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Minor editorial NSEC3 comments In-reply-to: Your message of "Fri, 11 Mar 2005 08:42:08 -0000." <624397D2AA7D72A581503267@[192.168.100.25]> Date: Sat, 12 Mar 2005 03:24:10 +1100 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > You are right in another way though: NSEC3 doesn't (well IMHO shouldn't) > require ANY of those properties of its hash function, UNLESS you > care about enumeration. NSEC3 should be able to cope with ANY function > (whatsoever) as the hash function, though the worse hash function it > is (and the smaller its range is compared to its domain), the more > important a functional fall-back to the identity hash becomes. Not quite ANY function. The size of the hash space must be bigger than the number of records in the NSEC3 chain. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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 Mar 11 11:41:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12375 for ; Fri, 11 Mar 2005 11:41:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9n8p-000O9w-Qx for namedroppers-data@psg.com; Fri, 11 Mar 2005 16:37:35 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9n8f-000O8h-Ft for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 16:37:25 +0000 Received: from [IPv6???1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 0AD9C33C5F; Fri, 11 Mar 2005 16:37:22 +0000 (GMT) Message-ID: <4231BB1B.1080702@algroup.co.uk> Date: Fri, 11 Mar 2005 15:36:59 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Mayer Cc: Roy Arends , namedroppers@ops.ietf.org Subject: Re: an example on wildcard proof. References: <4.3.1.2.20050310212616.0431ec60@pop.gis.net> In-Reply-To: <4.3.1.2.20050310212616.0431ec60@pop.gis.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Danny Mayer wrote: > At 02:48 PM 3/8/2005, Roy Arends wrote: > >> Note that there is no need to prove the nonexistence of >> test1.test2.example.com, since test2.example.com does not exist. > > > I'm not sure that that is true. If I add the following A record to the > example.com zone: > > test1.test2 10800 IN A 1.2.3.4 > > and I don't create any records for test2 does test2.example.com > exist, and if I ask won't I get an NXDOMAIN response? test2.example.com is an empty non-terminal. This "exists" in DNS terminology. It will appear in the NSEC(3) chain. Cheers, Ben. -- 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 Mar 11 11:50:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13278 for ; Fri, 11 Mar 2005 11:50:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9nJn-000PH0-QV for namedroppers-data@psg.com; Fri, 11 Mar 2005 16:48:55 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9nJi-000PGI-T2 for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 16:48:51 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id D02BFC2DAB; Fri, 11 Mar 2005 16:48:49 +0000 (GMT) Date: Fri, 11 Mar 2005 16:48:50 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Mark Andrews Cc: Roy Badami , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Minor editorial NSEC3 comments Message-ID: In-Reply-To: <200503111624.j2BGOAKc005469@drugs.dv.isc.org> References: <200503111624.j2BGOAKc005469@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 12 March 2005 03:24 +1100 Mark Andrews wrote: >> You are right in another way though: NSEC3 doesn't (well IMHO shouldn't) >> require ANY of those properties of its hash function, UNLESS you >> care about enumeration. NSEC3 should be able to cope with ANY function >> (whatsoever) as the hash function, though the worse hash function it >> is (and the smaller its range is compared to its domain), the more >> important a functional fall-back to the identity hash becomes. > > Not quite ANY function. The size of the hash space must be > bigger than the number of records in the NSEC3 chain. Correct - I said I hadn't had enough caffeine - else you cannot create the signed file in the first place. In fact the requirement is stricter than that: the function must, with a suitable salt value, produce unique [*] values for each record in the NSEC3 hash chain, and it must be possible to find such a salt value with a reasonable period of time. Of course having the range of the hash function larger than the size of the domain of the existent input values (as you suggest) is a necessary condition, but it is not sufficient. Trivial example: H(x) = SHA-512(x, salt) if x is even 1 if x is odd Such a hash function satisfies your criterion, but is no use. [*] note that this type of potential collision between hashes of two existent labels is entirely different from the label / QNAME collision problem - I know you know that, this is for the benefit of those reading the archives... 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 Mar 11 11:58:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14309 for ; Fri, 11 Mar 2005 11:58:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9nQk-0000TB-Ex for namedroppers-data@psg.com; Fri, 11 Mar 2005 16:56:06 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9nQh-0000Sf-8m for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 16:56:03 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 723E72DE6B; Fri, 11 Mar 2005 17:56:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 70FCF2DE35; Fri, 11 Mar 2005 17:56:01 +0100 (CET) Date: Fri, 11 Mar 2005 17:56:01 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Danny Mayer cc: namedroppers@ops.ietf.org Subject: Re: an example on wildcard proof. In-Reply-To: <4.3.1.2.20050310212616.0431ec60@pop.gis.net> Message-ID: References: <4.3.1.2.20050310212616.0431ec60@pop.gis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 10 Mar 2005, Danny Mayer wrote: > At 02:48 PM 3/8/2005, Roy Arends wrote: > >Note that there is no need to prove the nonexistence of > >test1.test2.example.com, since test2.example.com does not exist. > > I'm not sure that that is true. If I add the following A record to the > example.com zone: > > test1.test2 10800 IN A 1.2.3.4 > > and I don't create any records for test2 does test2.example.com > exist, Yes, the name exist, but there is no data at test2. > and if I ask won't I get an NXDOMAIN response? You'd get a NOERROR/NODATA response. 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 Mar 11 12:50:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20866 for ; Fri, 11 Mar 2005 12:50:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9oE2-0005eG-Q3 for namedroppers-data@psg.com; Fri, 11 Mar 2005 17:47:02 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9oDx-0005dF-6y for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 17:46:57 +0000 Received: from [IPv6???1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4FA2633C33; Fri, 11 Mar 2005 17:46:54 +0000 (GMT) Message-ID: <4231CB66.6070607@algroup.co.uk> Date: Fri, 11 Mar 2005 16:46:30 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh Cc: Roy Badami , namedroppers@ops.ietf.org Subject: Re: Minor editorial NSEC3 comments References: <16944.59759.232989.579130@giles.gnomon.org.uk> <624397D2AA7D72A581503267@[192.168.100.25]> In-Reply-To: <624397D2AA7D72A581503267@[192.168.100.25]> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > > > --On 11 March 2005 00:42 +0000 Roy Badami wrote: > >> Collision resistance is another specific property of cyrtographic >> hashes, namely that it is computationally infeasable to construct a >> pair of messages that hash to the same value, and AFAICS NSEC3 doesn't >> actually require a collision resitant hash function. >> >> Collision restistance implies second pre-image resitance: if you've >> managed to break second pre-image resitance then you have necessarily >> constructed a collision, but second pre-image resitance is a weaker >> property of a hash than collision resitance. > > > I think there are actually 2 separate requirements: > > * Second pre-image resistance - to stop enumeration "the obvious way" > (work backwards from the hashes). > > * Collision resistance - to stop a "nit" in the protocol. This is the > one everyone talked about for a ages here. If there isn't collision > resistance, then can't an attacker find QNAMEs with the same hash > value as labels in the zone? If they do this, we are then left with > the problem of what the server should return when a query is made > for that (presumably nonexistant) QNAME. I think the consensus was > to return an NSEC3 record with the identity (1:1) hash. This enumerates > a single label. This isn't dangerous if the main algorithm is > collision resistant. > > No caffeine yet so my brain may not work, but I *think* this means > that both collision resistance AND second-preimage resistance are > necessary. I think you are right that collision resistance implies > second pre-image resistance, but I don't think that's the issue > here, as both are required anyway. > > You are right in another way though: NSEC3 doesn't (well IMHO shouldn't) > require ANY of those properties of its hash function, UNLESS you > care about enumeration. NSEC3 should be able to cope with ANY function > (whatsoever) as the hash function, though the worse hash function it > is (and the smaller its range is compared to its domain), the more > important a functional fall-back to the identity hash becomes. I've been thinking about this some more, and I can't see how it would work. The idea, as I understand it, is that if one finds a pair of names whose hashes cannot (in reasonable time) be disambiguated, then one instead inserts an NSEC3 record with the identity hash at that ownername. However, it seems to me that this would then require the zone to use the identity hash for the whole zone. Why? Because the colliding hash cannot be included in a hashed NSEC3, since that was the problem in the first place, but if it is not included, then there will be an NSEC3 record that denies the existence of the colliding pair. This NSEC3 could be replayed by an attacker, instead of the identity NSEC3 the server would prefer. Hence, there will be a hash range for which there can be no denial records. All names falling into that range will have to be identity hashed (OK, perhaps the problem doesn't spread to the whole zone, but it certainly spreads, and I can't quite get my head around whether the spread is limited at this time - in any case, this strikes me as a significant problem). Mark Andrews suggested a related solution, and that is to include in the hashed NSEC3 record a field which can be set to the unhashed ownername. If there is no collision this field is not set (or is set to ".", or something), but if there is a collision, then the zone includes two versions of the NSEC3, one for each of the colliding names. This, of course, reveals those names, but only the collding names. This prevents an attacker being able to use the collision to deny RTYPES at either of the names (of course, if they have the same RTYPE bitmap, then collision is unimportant in any case). On a related note, I keep wondering I continue to care about collisions, despite there obvious bogosity, and there appear to be two answers. First, just for academic completeness, and second to reduce the impact of a broken hash function. Since the cost of this proposed solution is, almost always, a single byte, it might be as well to include it simply so we can bury this dead horse. In fact, we could even reduce the cost to a single bit by signalling the existence of the field, rather than always including it. Cheers, Ben. -- 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 Mar 11 13:07:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22616 for ; Fri, 11 Mar 2005 13:07:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9oW4-0008I1-U6 for namedroppers-data@psg.com; Fri, 11 Mar 2005 18:05:40 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9oVu-0008FX-GQ for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 18:05:30 +0000 Received: from [IPv6???1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 7767733C45; Fri, 11 Mar 2005 18:05:26 +0000 (GMT) Message-ID: <4231CFBE.5020108@algroup.co.uk> Date: Fri, 11 Mar 2005 17:05:02 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Badami Cc: Roy Arends , namedroppers@ops.ietf.org Subject: Re: NSEC3 References: <16942.55022.2320.731606@giles.gnomon.org.uk> <16942.58524.788818.947885@giles.gnomon.org.uk> <16944.9107.103627.602775@giles.gnomon.org.uk> <42305C51.1060308@algroup.co.uk> <16944.53922.293156.623714@giles.gnomon.org.uk> <4230C672.1040508@algroup.co.uk> <16944.55316.333600.996850@giles.gnomon.org.uk> In-Reply-To: <16944.55316.333600.996850@giles.gnomon.org.uk> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Badami wrote: > Ben> I believe that since NSEC3 also shows the record at the > Ben> closest encloser, the same check works. > > But what about names between the query name and the closest encloser? They don't exist. > Don't you need to not only prove that a wildcard doesn't exist at each > of those names, No, because if a wildcard existed at one of them, then that name would exist, and so the closest encloser would be that name instead. > but also that a delegation doesn't exist at each of > those names? The same NSEC3 record won't generally cover the wildcard > and the NS record. I claim it will. -- 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 Mar 11 13:28:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24087 for ; Fri, 11 Mar 2005 13:28:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9opx-000AK7-0O for namedroppers-data@psg.com; Fri, 11 Mar 2005 18:26:13 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9opt-000AJq-Fe for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 18:26:09 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 5976BC2DA4; Fri, 11 Mar 2005 18:26:08 +0000 (GMT) Date: Fri, 11 Mar 2005 18:26:08 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie Cc: Roy Badami , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Minor editorial NSEC3 comments Message-ID: <0C7837460D3C4BE4980E0763@[192.168.100.25]> In-Reply-To: <4231CB66.6070607@algroup.co.uk> References: <16944.59759.232989.579130@giles.gnomon.org.uk> <624397D2AA7D72A581503267@[192.168.100.25]> <4231CB66.6070607@algroup.co.uk> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben, --On 11 March 2005 16:46 +0000 Ben Laurie wrote: > I've been thinking about this some more, and I can't see how it would > work. > > The idea, as I understand it, is that if one finds a pair of names whose > hashes cannot (in reasonable time) be disambiguated, then one instead > inserts an NSEC3 record with the identity hash at that ownername. No, you misunderstand what I am saying. Probably my fault as I made the mistake of putting both hash collision types in a single message. Here they are, completely separately. HASH COLLISIONS ON NSEC3 CREATION / ZONE SIGNATURE ================================================== I agree that you should never have two names (call them x1, x2) where the hashes collide i.e. H(x1,S) = H(x2,S) where S is the salt and H(x,S) is the hash of x This type of collision can be detected at signature time. It's a problem for the reason you mention and no doubt other reasons too. The solution is to pick another value S' (at signing time - by which I technically mean NSEC3 creation time which comes prior to signing time and doesn't require the signature stuff, but that's another story). I presented what I think is a proof that if the hash function satisfies sensible properties, and the size of the hash range is more than the square of the number of zone entries, then the expected value of the number of iterations to find a suitable salt that produces no collision is less than 2. It can thus be safely coded in a loop like: ASSERT ( numberofrecords ^2 < hashfunctionsize, "wrong hash func") int i=0; do { S = random(...); // with lots of bits MakeHashes (zone, S) ASSERT ( (i++ > 1000) , "Please shoot Alex"); // if you must } while (AreAnyHashesTheSameValue(S)); as the second assert will statistically never trigger (you have more chance of breaking the 2nd pre-image resistance property). HASH COLLISIONS BETWEEN A QNAME AND A NAME AT QUERY TIME ======================================================== This is where a query for name q is made, and H(q,S)=H(x,S) for some existent record X. In layman's term, there is an NSEC3 record with the same hash as existent record x, where q!=x. Now, because we know (see above) we would not have created the zone if there were two existent records with the same hash) we also know (as q!=x by definition), that the record q is non-existent. We would then have the (arguable) problem where for some queries there will be an NSEC3 record which has one end equal to H(x), i.e there will be two records like: NSEC3 H(x) H(x) NSEC3 That may imply to a resolver (querying q) that q exists, because H(q) exists (being H(x)) at an NSEC3, which gives the potential for things being misled. Note that whilst I heard the argument that there is a potential for things being misled here, a) I was never convinced it was an actual threat (or if I was, I've forgotten why), and b) We should detect this and pipe it to a mail program pointing out we'd found a hash collision if the algorithm is meant never to generate one, but some people seem to be worried about this, and it seems to me a useful thing to sort out (i) to put those people's minds at rest and (ii) so we can support weak hash functions and/or we know that if SHA-512 or whatever does turn out to be weak, the worse that has happened NSEC3-wise is that zones become enumerable, not that there is a new threat (the one in (a) I don't understand quite what it is :-) ). So what I am suggesting, is for those people worried about this or wanting to support weak hash algorithms that may collide (no problem with the identity hash), at NSEC3 generation time, NSEC3s are generated with the identity hash too, so we have: NSEC3 H(x), ALG=SHA-512 NSEC3 x, ALG=Identity H(x) NSEC3 x NSEC3 , ALG=Identity There are thus two NSEC3 chains (linking the records in a different order, obviously), one using SHA-512, and one using Identity hash, which is practically identical to existing NSEC treatment. However, the identity hash NSEC3 is never returned, except under one circumstance, which is as follows. When it is desired to deny the existence of a QNAME q, then we see whether H(q) exists within the current zonefile (we already know q doesn't exist, or we wouldn't be attempting to deny its existence). If H(q) does exist, we have found a q and an x, such that q!=x, H(q)=H(x) which is the sort of collision we are talking about. So, first we mail some crypto mailing lists if H was a strong hash. Next we return the alternate NSEC3 record with the identity hash that covers the record q. The resolver has now managed to elucidate two zone entries (the two zone entries at either end of the interval), but in order to do this, he had to do the computationally infeasible, i.e. find a hash collision. > Mark Andrews suggested a related solution, and that is to include in the > hashed NSEC3 record a field which can be set to the unhashed ownername. > If there is no collision this field is not set (or is set to ".", or > something), but if there is a collision, then the zone includes two > versions of the NSEC3, one for each of the colliding names. This, of > course, reveals those names, but only the collding names. This prevents > an attacker being able to use the collision to deny RTYPES at either of > the names (of course, if they have the same RTYPE bitmap, then collision > is unimportant in any case). OK, that might solve the "colliding RRs", but why not just not use the problematic salt value? > Since the cost of this proposed solution is, almost always, a single > byte, it might be as well to include it simply so we can bury this dead > horse. In fact, we could even reduce the cost to a single bit by > signalling the existence of the field, rather than always including it. I think the only problem that needs to be solved (for academic completeness) is the colliding name and QNAME issue. I can't see why colliding RRs are a problem. I banged this point to death on the list before I realized (doh!) people were actually talking about QNAME and existent RR collisions. Perhaps because I was talking at such a tangent to the thread at the time, everyone (understandably) ignored it and/or failed to point out some obvious flaw. 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 Mar 11 14:56:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01960 for ; Fri, 11 Mar 2005 14:56:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9qBL-000J7u-Vz for namedroppers-data@psg.com; Fri, 11 Mar 2005 19:52:23 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9qBE-000J6p-M2 for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 19:52:17 +0000 Received: from [10.31.32.154] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2BJq7gf014134; Fri, 11 Mar 2005 14:52:08 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Fri, 11 Mar 2005 14:52:08 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: closest encloser Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've been getting mail asking to clarify words involving "closest encloser" in the context of negative answers. Since I cannot devote enough time *at this moment* to the issue, here is a short "guide." Assume this is one zone (no cut points), no DNAME anywhere... "Normal" example: . | example / | \ * bar zed / \ alpha omega QNAME=foo.example. The closest encloser is example. The source of synthesis is *.example. If there is a QTYPE match with the types at *.example, synthesize. QNAME=foo.bar.example. The closest encloser is bar.example. There is no source of synthesis, *.bar.example. is not on the tree. "Abnormal query, normal tree" QNAME=foo.*.example. The closest encloser is *.example. There is no source of synthesis, *.*.example. is not on the tree. "Abnormal tree" . | example / | \ * bar zed | / \ * alpha omega QNAME=foo.example. The closest encloser is example. The source of synthesis is *.example. If there is a QTYPE match with the types at *.example, synthesize. QNAME=foo.*.example. The closest encloser is *.example. The source of synthesis is *.*.example. If there is a QTYPE match with the types at *.*.example, synthesize. Notice that in the first example, *.example is a source of synthesis. In the next example it is a closest encloser. The role the name takes on is relative to the QNAME value. For any QNAME, no domain can be both the closest encloser and the source of synthesis. QNAME=*.*.example. This results in an exact name match, you're in part a (1034/4.3.2/Step 3). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 11 18:34:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19236 for ; Fri, 11 Mar 2005 18:34:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9tcU-000HUA-J6 for namedroppers-data@psg.com; Fri, 11 Mar 2005 23:32:38 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1D9tcT-000HTx-KS for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 23:32:37 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j2BNWZsc003061 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Mar 2005 18:32:36 -0500 Date: Fri, 11 Mar 2005 18:32:35 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Frederico A C Neves cc: namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack In-Reply-To: <20050306052155.GG45025@registro.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 6 Mar 2005, Frederico A C Neves wrote: > On Sun, Mar 06, 2005 at 12:03:20AM -0500, Dean Anderson wrote: > > On Sat, 5 Mar 2005, Hallam-Baker, Phillip wrote: > > > This just appeared on the SANS list. Time to stop arguing and get DNSSEC > > > deployed. > > > > I've not been testing DNSSEC, but I understand it requires TCP. > > No it doesn't. That's good to hear. > Please read 2671 and the 3 drafts > draft-ietf-dnsext-dnssec-[intro|protocol|records] on RFC Ed Queue. Will do. Probably should get busy in the lab... Thanks, -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- 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 Mar 11 18:34:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19263 for ; Fri, 11 Mar 2005 18:34:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9taD-000HHv-RR for namedroppers-data@psg.com; Fri, 11 Mar 2005 23:30:17 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1D9taA-000HHR-LZ for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 23:30:14 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j2BNU26C003046 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Mar 2005 18:30:04 -0500 Date: Fri, 11 Mar 2005 18:30:02 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Masataka Ohta cc: "Hallam-Baker, Phillip" , Subject: Re: DNS Blackhole attack In-Reply-To: <422A93A1.9050801@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 6 Mar 2005, Masataka Ohta wrote: > Dean Anderson wrote: > > > On Sat, 5 Mar 2005, Hallam-Baker, Phillip wrote: > > > >>This just appeared on the SANS list. Time to stop arguing and get DNSSEC > >>deployed. > > > > > > I've not been testing DNSSEC, but I understand it requires TCP. So, DNSSEC > > cannot be deployed on root servers, due to large number of root servers > > using anycast, and anycast conflict with the DNSSEC's TCP requirements. > > That is not a valid reason to avoid DNSSEC. Anycast does work with > short-lived TCP. Uhh, no, it doesn't. Not when Per-packet-load-balancing (PPLB) is used anywhere. Cisco has been shipping PPLB for a while now. Its been tested: PPLB works on BGP links, and it works on OSPF links. Its not just external paths you need to worry about. If you have OSPF internal network using PPLB, and the internal paths lead to different external peer interfaces, then packets could hit different anycast root servers on a per-packet basis. So TCP won't work to them. This was discussed at length some little while back. The notion that short-lived tcp can work over anycast is wrong. > However, the security problem, here, is not inherent to DNS but > is caused by poor implementation of it, which is why we MUST > avoid DNSSEC which is a lot more complex than DNS and is > assured to make its implementations poor and insecure. I don't agree the security problem DNS is a due to implementation bugs. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- 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 Mar 11 18:52:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21535 for ; Fri, 11 Mar 2005 18:52:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9tu3-000JLA-5u for namedroppers-data@psg.com; Fri, 11 Mar 2005 23:50:47 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1D9tu1-000JKf-8I for namedroppers@ops.ietf.org; Fri, 11 Mar 2005 23:50:45 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j2BNohCe003422 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Mar 2005 18:50:44 -0500 Date: Fri, 11 Mar 2005 18:50:42 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: bmanning@vacation.karoshi.com cc: "Hallam-Baker, Phillip" , Subject: Re: DNS Blackhole attack In-Reply-To: <20050306143220.GC7735@vacation.karoshi.com.> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 6 Mar 2005 bmanning@vacation.karoshi.com wrote: > On Sun, Mar 06, 2005 at 12:03:20AM -0500, Dean Anderson wrote: > > On Sat, 5 Mar 2005, Hallam-Baker, Phillip wrote: > > > This just appeared on the SANS list. Time to stop arguing and get DNSSEC > > > deployed. > > > > I've not been testing DNSSEC, but I understand it requires TCP. So, DNSSEC > > you might want to try it out to be sure of your understandings. Yep. When I'm not sure of something, I usually say so. > > cannot be deployed on root servers, due to large number of root servers > > using anycast, and anycast conflict with the DNSSEC's TCP requirements. > > (Anycast only works on UDP single packet per transaction protocols. ISC > > mistakenly told root operators that anycast can be deployed with TCP.) So, > > they did? guess not everyone received the msg. I suppose some people ignored the discussion of anycast on DNSOP. And someone complained that anycast DNS root server operations weren't relevant to Nanog. (bmanning) And I haven't quite forgotten the rather vicious personal attack on me made by John Brown on DNSOP, where he claimed to have no association with ISC, even though he started chagres.net with Suzzanne Woolf who was the ISC project manager in charge of promoting root anycast. But I suppose that ISC hasn't made any efforts to get the message out. So I have little doubt that not everyone has gotten the message. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- 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 Mar 12 12:16:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22412 for ; Sat, 12 Mar 2005 12:16:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAA8Y-000Oea-Is for namedroppers-data@psg.com; Sat, 12 Mar 2005 17:10:50 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DAA8X-000Odf-Gp for namedroppers@ops.ietf.org; Sat, 12 Mar 2005 17:10:49 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 9869E2DE62; Sat, 12 Mar 2005 18:10:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 973D92DE5C for ; Sat, 12 Mar 2005 18:10:45 +0100 (CET) Date: Sat, 12 Mar 2005 18:10:45 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: nsec3 with one hash algorithm: SHA-224 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk WG, Rolling hash algorithms (from mandatory to optional) is problematic, as was previously shown on this list. Since there is also no real profit in supporting more then one algorithm, we can obsolete the algorithm field from the RDATA, and settle on a single algorithm for nsec3: SHA-224 (rfc-3874). Any comments ? 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 Sat Mar 12 12:49:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24457 for ; Sat, 12 Mar 2005 12:49:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAAgO-0002Zr-5l for namedroppers-data@psg.com; Sat, 12 Mar 2005 17:45:48 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DAAgL-0002Ze-NO for namedroppers@ops.ietf.org; Sat, 12 Mar 2005 17:45:45 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 5BF32C2DA8; Sat, 12 Mar 2005 17:45:44 +0000 (GMT) Date: Sat, 12 Mar 2005 17:45:43 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Roy Arends , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: nsec3 with one hash algorithm: SHA-224 Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 12 March 2005 18:10 +0100 Roy Arends wrote: > Rolling hash algorithms (from mandatory to optional) is problematic, as > was previously shown on this list. Since there is also no real profit in > supporting more then one algorithm, we can obsolete the algorithm > field from the RDATA, and settle on a single algorithm for nsec3: SHA-224 > (rfc-3874). > > Any comments ? I suggest using a longer algorithm (SHA-512), and then specifying a variable number of bits to truncate to, to enable the signer to achieve their own balance between non-enumerability and minimization on-wire packet size. For small zones, this could be less than traditional NSEC if people don't care about enumerability (if we make sure we treat weak hash algorithms right). I also think that those wanting to support weak algorithms, AND those who are concerned to treat QNAME/label hash collisions right (despite their unlikelihood) AND those who don't give a fig about enumerability and want to use minimum CPU cycles will EACH want to support an identity hash algorithm. That means you need the field anyway (conceivably it could be 0 for identity, or a number of octets to which SHA-512 is truncated). My personal view on the necessity for identity algorithm is that it's only needed if you want to support weak / deliberately over truncated hash algorithms, but I understand others' points of view. 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 Mar 12 13:21:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27097 for ; Sat, 12 Mar 2005 13:21:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DABDs-0006RW-1V for namedroppers-data@psg.com; Sat, 12 Mar 2005 18:20:24 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DABDp-0006QZ-JX for namedroppers@ops.ietf.org; Sat, 12 Mar 2005 18:20:21 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id D8C432DE68; Sat, 12 Mar 2005 19:20:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id D24782DE66; Sat, 12 Mar 2005 19:20:19 +0100 (CET) Date: Sat, 12 Mar 2005 19:20:19 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Alex Bligh cc: namedroppers@ops.ietf.org Subject: Re: nsec3 with one hash algorithm: SHA-224 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 12 Mar 2005, Alex Bligh wrote: > --On 12 March 2005 18:10 +0100 Roy Arends wrote: > > > Rolling hash algorithms (from mandatory to optional) is problematic, as > > was previously shown on this list. Since there is also no real profit in > > supporting more then one algorithm, we can obsolete the algorithm > > field from the RDATA, and settle on a single algorithm for nsec3: SHA-224 > > (rfc-3874). > > > > Any comments ? > > I suggest using a longer algorithm (SHA-512), and then specifying a > variable number of bits to truncate to, to enable the signer to achieve > their own balance between non-enumerability and minimization on-wire > packet size. For small zones, this could be less than traditional NSEC > if people don't care about enumerability (if we make sure we treat > weak hash algorithms right). A label has a maximum length of 63 characters. With base-32, the maximum amount of bits we could squeeze in a label is 315. So, truncation is definitly needed for sha-512. > I also think that those wanting to support weak algorithms, AND those who > are concerned to treat QNAME/label hash collisions right (despite their > unlikelihood) AND those who don't give a fig about enumerability and want > to use minimum CPU cycles will EACH want to support an identity hash > algorithm. Isn't using identity hash effectively similar as using 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 Sat Mar 12 13:22:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27144 for ; Sat, 12 Mar 2005 13:22:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DABCD-0006Jh-Pt for namedroppers-data@psg.com; Sat, 12 Mar 2005 18:18:41 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DABCC-0006JQ-In for namedroppers@ops.ietf.org; Sat, 12 Mar 2005 18:18:40 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j2CIIXD1004313; Sat, 12 Mar 2005 13:18:33 -0500 Received: from gorilla ([129.6.220.16]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id j2CIILEY010517; Sat, 12 Mar 2005 13:18:22 -0500 (EST) From: "Scott Rose" To: "Roy Arends" , Subject: RE: nsec3 with one hash algorithm: SHA-224 Date: Sat, 12 Mar 2005 13:18:29 -0500 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Alex, but if one algorithm is decided on, I would like it to be SHA256 at least. SHA1 was scheduled to be phased out from USG use in '09 (I believe) and replaced with SHA256. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Roy Arends > Sent: Saturday, March 12, 2005 12:11 PM > To: namedroppers@ops.ietf.org > Subject: nsec3 with one hash algorithm: SHA-224 > > > WG, > > Rolling hash algorithms (from mandatory to optional) is problematic, as > was previously shown on this list. Since there is also no real profit in > supporting more then one algorithm, we can obsolete the algorithm > field from the RDATA, and settle on a single algorithm for nsec3: SHA-224 > (rfc-3874). > > Any comments ? > > 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 Sat Mar 12 14:24:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01068 for ; Sat, 12 Mar 2005 14:24:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DACB2-000E5a-Uv for namedroppers-data@psg.com; Sat, 12 Mar 2005 19:21:32 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DACB0-000E4Z-Nf for namedroppers@ops.ietf.org; Sat, 12 Mar 2005 19:21:30 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 89839C2DA8; Sat, 12 Mar 2005 19:21:29 +0000 (GMT) Date: Sat, 12 Mar 2005 19:21:28 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Roy Arends Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: nsec3 with one hash algorithm: SHA-224 Message-ID: <94E06F81335CCC8D80CB23F9@[192.168.100.25]> In-Reply-To: References: X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 12 March 2005 19:20 +0100 Roy Arends wrote: >> I suggest using a longer algorithm (SHA-512), and then specifying a >> variable number of bits to truncate to, to enable the signer to achieve >> their own balance between non-enumerability and minimization on-wire >> packet size. For small zones, this could be less than traditional NSEC >> if people don't care about enumerability (if we make sure we treat >> weak hash algorithms right). > > A label has a maximum length of 63 characters. With base-32, the maximum > amount of bits we could squeeze in a label is 315. So, truncation is > definitly needed for sha-512. Yep. All this talk about every character being valid et al. and I forgot about the caching nameservers that don't stick to the standard and the consequent necessity for base-32 or equivalent, and thus in practice we are limited to 300 or so bits. However, I would still recommend picking a hash algorithm that is too long and truncating, than one that is shorter, given we (now) know how difficult algorithm rolling is. >> I also think that those wanting to support weak algorithms, AND those who >> are concerned to treat QNAME/label hash collisions right (despite their >> unlikelihood) AND those who don't give a fig about enumerability and want >> to use minimum CPU cycles will EACH want to support an identity hash >> algorithm. > > Isn't using identity hash effectively similar as using NSEC ? No - think opt-in. 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 Mar 12 14:30:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01293 for ; Sat, 12 Mar 2005 14:30:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DACHt-000Eux-1W for namedroppers-data@psg.com; Sat, 12 Mar 2005 19:28:37 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DACHq-000EtS-MQ for namedroppers@ops.ietf.org; Sat, 12 Mar 2005 19:28:34 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id EA10A33C6B; Sat, 12 Mar 2005 19:28:32 +0000 (GMT) Message-ID: <42334268.80606@algroup.co.uk> Date: Sat, 12 Mar 2005 19:26:32 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Rose Cc: Roy Arends , namedroppers@ops.ietf.org Subject: Re: nsec3 with one hash algorithm: SHA-224 References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose wrote: > I agree with Alex, but if one algorithm is decided on, I would like it to be > SHA256 at least. SHA1 was scheduled to be phased out from USG use in '09 (I > believe) and replaced with SHA256. SHA-224 is truncated SHA-256. I can certainly live with full length SHA-256. I'd argue against SHA-512, since its been pointed out that its painful for limited (i.e. not 64 bit) processors to implement. -- 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 Mar 13 09:33:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12843 for ; Sun, 13 Mar 2005 09:33:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAU48-000Lm7-Ae for namedroppers-data@psg.com; Sun, 13 Mar 2005 14:27:36 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DAU44-000Llq-FQ for namedroppers@ops.ietf.org; Sun, 13 Mar 2005 14:27:32 +0000 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DAU43-000LLq-79 for namedroppers@ops.ietf.org; Sun, 13 Mar 2005 09:27:31 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j2DERTs02319 for ; Sun, 13 Mar 2005 06:27:30 -0800 Date: Sun, 13 Mar 2005 06:27:29 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to Issue 82: Conflict merging Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 82 is enclosed below. The proposed resolution is as follows: In Section 2.2, change: " The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers receive the query and respond with valid answers. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would." To: " The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR responders receive the query and respond with valid answers. When multiple valid answers are received in response to a query (other than a uniqueness query), they are treated as follows: [1] Responses with the 'T' bit set are silently discarded. [2] If all the remaining responses have the 'C' bit set, the responses are concatenated and then treated in the same manner that multiple RRs received from the same DNS server would. [3] If one or more of the responses have both the 'C' and 'T' bits clear, a conflict has been detected. The responses are concatenated, but are not cached. A query for the same name, type and class is sent, with the 'C' bit set. Conflict detection and resolution is described in more detail in Section 4.2." ----------------------------------------------------------------------- Issue 82: Conflict Merging Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: March 8, 2004 Reference: Document: LLMNR-38 Comment type: T Priority: S Section: 2.2 Rationale/Explanation of issue: Section 2.2 states: " The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers receive the query and respond with valid answers. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would." Is this really what you want in the case where responses conflict? Merging of responses makes sense for RRs which are not expected to be UNIQUE, but What about merging of responses from conflicting responders? Merged conflicting responses will be cached according to the TTL, which could result in persistence of inconsistencies. Example: merging of SRV RRs from conflicting responders will result in inconsistent weighting. -- 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 Mar 13 09:33:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12887 for ; Sun, 13 Mar 2005 09:33:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAU7w-000MBz-05 for namedroppers-data@psg.com; Sun, 13 Mar 2005 14:31:32 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DAU7u-000MBj-1n for namedroppers@ops.ietf.org; Sun, 13 Mar 2005 14:31:30 +0000 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DAU7t-000LsK-3W for namedroppers@ops.ietf.org; Sun, 13 Mar 2005 09:31:29 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j2DEVSp02646 for ; Sun, 13 Mar 2005 06:31:28 -0800 Date: Sun, 13 Mar 2005 06:31:28 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to Issue 83: Conflict definition Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 83 is enclosed below. The proposed resolution is as follows: In Section 1.2, change the definition of UNIQUE to the following: "UNIQUE There are some scenarios when multiple responders may respond to a query. There are other scenarios when only one responder may respond to a query. A responder considers a name to be UNIQUE if multiple responses are not expected in response to a query for a name, regardless of the type and class." Change Section 4 to the following: "4. Conflict Resolution A responder considers a name to be UNIQUE if multiple responses are not expected in response to a query for that name, regardless of the type and class. By default, a responder SHOULD be configured to behave as though its names are UNIQUE on each interface on which LLMNR is enabled. When responding to a query for a UNIQUE name, the 'C' bit is clear in the response. Where the name in the query is not UNIQUE, an LLMNR responder sets the 'C' bit in the response. For example, where multiple responders may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster), the 'C' bit is set in the response, regardless of the type and class of the query. To detect duplicate use of a name, an administrator can use a name resolution utility which employs LLMNR and lists both responses and responders. This would allow an administrator to diagnose behavior and potentially to intervene and reconfigure LLMNR responders who should not be configured to respond to the same name." ---------------------------------------------------------------------- Issue 83: Conflict Definition Submitter: Markku Savela Submitter email address: msa@burp.tkv.asdf.org Date first submitted: March 5, 2005 Reference: Document: LLMNR-38 Comment type: T Priority: S Section: 1.2 Rationale/Explanation of issue: Could we just base the "uniqueness" just for plain , and not to combination? I'm not quite sure what the proposed resolution actually recommends now... ----- 4.1. Uniqueness Verification Prior to including a UNIQUE resource record in a response with the 'T' bit clear, for each UNIQUE resource record in a given interface's configuration, the host MUST verify that there is no other host within the scope of LLMNR query propagation that can return a resource record for the same name, type and class on that interface. ---- Seems to indicate, that uniquenes is feature, but later ---- To verify uniqueness, a responder MUST send an LLMNR query with the 'C' bit clear, over all protocols on which it responds to LLMNR queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify uniqueness of a name by sending a query for the name with type='ANY'. seems to indicate, that uniqueness is name only. (If not, then sending ANY won't work, because ANY does not need to return all RR's...) [Bernard Aboba] I agree that uniqueness is based on the name, not the combination. > 4.1. Uniqueness Verification > > Prior to including a UNIQUE resource record in a response with the > 'T' bit clear, for each UNIQUE resource record in a given interface's > configuration, the host MUST verify that there is no other host > within the scope of LLMNR query propagation that can return a > resource record for the same name, type and class on that interface. > ---- > > Seems to indicate, that uniquenes is feature, but later What this is trying to say is that the uniqueness of each RR must be verified in order to prevent a name conflict. Since sending an ANY query is only a SHOULD, it also might be possible to send individual queries. However, regardless of how it is done, if a conflict is detected, the name is not used in response to any query. Is there a way to make this more clear? [Markku Savela] If uniqueness is for name only, the test becomes very simple: send query using the name for whatever RR you want to use. The actual type of RR used in the query does not matter. Any other node that thinks it owns the name, will answer to the query. If it does not have any matching type of RR, the answer section is just empty. -- 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 Mar 13 09:38:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13071 for ; Sun, 13 Mar 2005 09:38:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAUCS-000Mo1-6E for namedroppers-data@psg.com; Sun, 13 Mar 2005 14:36:12 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DAUCQ-000MnI-6s for namedroppers@ops.ietf.org; Sun, 13 Mar 2005 14:36:10 +0000 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DAUCP-000MUX-CO for namedroppers@ops.ietf.org; Sun, 13 Mar 2005 09:36:09 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j2DEa8R02895 for ; Sun, 13 Mar 2005 06:36:08 -0800 Date: Sun, 13 Mar 2005 06:36:08 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to Issue 80: Multi-protocol conflicts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 80 is enclosed below. The proposed resolution is as follows: In Section 2.6, add clause [d]: " [d] When LLMNR is implemented on a dual stack host, LLMNR SHOULD be supported on both IPv4 and IPv6. An implementation only supporting LLMNR over IPv6 SHOULD NOT return IPv4 addresses; an implementation only supporting LLMNR over IPv4 SHOULD NOT return IPv6 addresses." ------------------------------------------------------------------ Issue 80: Multi-Protocol Conflicts Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 3, 2005 Reference: Document: LLMNR-38 Comment type: T Priority: 1 Section: 4.2 Rationale/Explanation of issue: When LLMNR messages are sent over multiple protocols (IPv4 and IPv6), some interesting conflict scenarios can arise. For example: Host A supports both IPv4 and IPv6 but only sends and responds to LLMNR queries over IPv6. Host B supports IPv4 only and sends and responds to LLMNR queries only over IPv4. What happens if Host A and B configure the same name? A sender (Host C) will send an LLMNR query and will get a single response, whether the query is sent over IPv4 or IPv6. However, when it sends a query over IPv6, Host A could respond with an A RR conflicting with the A RR that Host B would respond with if the query were sent over IPv4. Since the sender only gets a single response, it never sends a query with the 'C' bit set. The responders never detect a conflict via the uniqueness verification mechanism. Yet a conflict does exist. [Bernard Aboba] My suggestion is that a host should only respond with resource records corresponding to protocols that it supports for use with LLMNR. If Host A only supports LLMNR over IPv6, it should not configure an A RR, even if it has an IPv4 address. Similarly, if Host A only supports LLMNR over IPv4, it should not configure a AAAA RR. [Markku Savela] The only icky case is when one host has only IPv6 and another has only IPv4. In such case they don't see each others queries or replies. They are as if they were on different interfaces/links. This is probably ok situation. If one has either IPv4 or IPv6 only, and other has both, then conflict is detected, because the one with both IPv4 and IPv6 will always reply (and will do uniqueness test for both IPv4 and IPv6). There is one caution: currently, there is a special kludge for A and AAAA queries. A query is sent only over IPv4, and AAAA query is sent only over IPv6. Thus, uniqueness test on IPv4+6 host would have to a) avoid using A,AAAA in test query (use ANY, or some other) b) take care to send the test over IPv4 with A, and over IPv6 with AAAA [I'm not sure where this kludge came from, and whether it is still requirement on the current version (I guess I need to reread it :-). As far as real DNS is concerned, A/AAAA and the link type over which queries are sent, are independent.] -- 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 Mar 13 09:42:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13335 for ; Sun, 13 Mar 2005 09:42:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAUFn-000Nap-H5 for namedroppers-data@psg.com; Sun, 13 Mar 2005 14:39:39 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DAUFm-000NaN-F3 for namedroppers@ops.ietf.org; Sun, 13 Mar 2005 14:39:38 +0000 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DAUFl-000N9v-Jb for namedroppers@ops.ietf.org; Sun, 13 Mar 2005 09:39:37 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j2DEdax03095 for ; Sun, 13 Mar 2005 06:39:36 -0800 Date: Sun, 13 Mar 2005 06:39:36 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to Issue 78: Uniqueness Probing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 78 is enclosed below. The proposed resolution is as follows: Change the beginning of Section 2.1.1 to: "2.1.1. LLMNR header format LLMNR queries and responses utilize the DNS header format defined in [RFC1035] with exceptions noted below: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode | Z|TC| T| C| Z| Z| Z| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+" Add the following paragraph: "T Tentative. The 'T'entative bit is set in a response if the responder is authoritative for the name, but has not yet verified the uniqueness of the name. A sender receiving a response with the 'T' bit set MUST silently discard the response unless it is received in response to a uniqueness query. A responder MUST ignore the 'T' bit in a query, if set. When a response with the 'T' bit set is received in response to a uniqueness query, a conflict has been detected and a responder MUST resolve the conflict. Use of the 'T' bit is described in more detail in Sections 4.1 and 4.2." ------------------------------------------------------------------ Issue 78: UNIQUEness Probing Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: October 8, 2004 Reference: Document: LLMNR-36 Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: "To verify uniqueness, a responder MUST send an LLMNR query for each UNIQUE resource record. If no response is received after a suitable number of attempts (see Section 2.7), the responder can use the UNIQUE resource record in response to LLMNR queries. If a response is received, the responder MUST NOT use the UNIQUE resource record in response to LLMNR queries." It sounds like two nodes attempting to use the same name at the same time will end up both deciding that the name is not in use. Ooops. Could we: - use the source address of queries to distinguish between queries sent out for a "tentative" name vs. a query from someone else? - could we (if we see other simultaneous queries) say "danger, conflict may be present", and do some sort of random wait before trying again, so that two nodes doing the same thing will wait different times, with one presumably then able to grab the name? Will this all be too complicated and take too long? I dunno. But the algorithm as specified now seems like it wil fail with high probability (e.g, recovery after powerfail scenario). -- 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 Mar 13 09:45:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13679 for ; Sun, 13 Mar 2005 09:45:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAUJ2-000O1c-Pl for namedroppers-data@psg.com; Sun, 13 Mar 2005 14:43:00 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DAUJ1-000O1L-Oj for namedroppers@ops.ietf.org; Sun, 13 Mar 2005 14:42:59 +0000 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DAUJ0-000Njt-TR for namedroppers@ops.ietf.org; Sun, 13 Mar 2005 09:42:59 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j2DEgvk03273 for ; Sun, 13 Mar 2005 06:42:57 -0800 Date: Sun, 13 Mar 2005 06:42:57 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue 81: Conflicts from Healing of a Partition Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 81 is enclosed below. The proposed resolution is as follows: In Section 2.1.1 add the following paragraph: "C Conflict. When set within a request, the 'C'onflict bit indicates that a sender has received multiple LLMNR responses to this query with the 'T' bit clear. In an LLMNR response, the 'C' bit is clear if the responder considers the name in the query to be UNIQUE; otherwise the 'C' bit is set. LLMNR senders do not retransmit queries with the 'C' bit set. When receiving an LLMNR query with the 'C' bit set, an LLMNR responder MUST NOT respond, but will attempt to verify the conflict, as described in Section 4.2." Change Section 4.1 and 4.2 to the following: "4.1. Uniqueness Verification Before responding with the 'T' bit clear to a query for a UNIQUE name, a responder MUST verify that there is no other host within the scope of LLMNR query propagation using the same name on that interface. Prior to verifying uniqueness of a name, a responder MUST set the 'T' bit in responses to queries for that name. Once a responder has verified the uniqueness of a name, if it receives an LLMNR query for that name with the 'C' bit clear, it MUST respond, with the 'T' and 'C' bits clear. Uniqueness verification is carried out when the host: - starts up or is rebooted - wakes from sleep (if the network interface was inactive during sleep) - is configured to respond to LLMNR queries on an interface enabled for transmission and reception of IP traffic - is configured to respond to LLMNR queries using additional UNIQUE resource records - verifies the acquisition of a new IP address and configuration on an interface To verify uniqueness of a name, a responder MUST send an LLMNR query for the name with the 'C' bit clear over all protocols on which it responds to LLMNR queries (IPv4 and/or IPv6). Any query type will do, including 'ANY'. If no response is received, the sender retransmits the query, as specified in Section 2.7. If a response is received with the 'T' bit clear, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). If a response is received with the 'T' bit set, the responder MUST check if the source IP address in the response, interpreted as an unsigned integer, is less than the source IP address in the query. If so, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). For the purpose of uniqueness verification, the contents of the answer section in a response is irrelevant. Periodically carrying out uniqueness verification in an attempt to detect name conflicts is not necessary, wastes network bandwidth, and may actually be detrimental. For example, if network links are joined only briefly, and are separated again before any new communication is initiated, temporary conflicts are benign and no forced reconfiguration is required. LLMNR responders SHOULD NOT periodically attempt uniqueness verification. 4.2. Conflict Detection and Defense Hosts on disjoint network links may configure the same name for use with LLMNR. If these separate network links are later joined or bridged together, then there may be multiple hosts which are now on the same link, trying to use the same name. In order to enable ongoing detection of name conflicts, when an LLMNR sender receives multiple LLMNR responses to a query, the sender behaves as follows: [1] Responses with the 'T' bit set MUST be silently discarded. [2] If multiple responses remain, the sender MUST check if the 'C' bit is clear in any of the remaining responses. If so, a potential conflict has been detected; the sender SHOULD send another query for the same name, type and class, this time with the 'C' bit set. The potentially conflicting resource records are included in the additional section. Responders receiving a query with the 'C' bit set behave as follows: [3] Queries with the 'C' bit set are considered advisory and responders MUST verify the existence of a conflict before acting on it. A responder receiving a query with the 'C' bit set MUST NOT respond. [4] A responder receiving a query for a non-UNIQUE name with the 'C' bit set silently discards the query. A responder receiving a query for a UNIQUE name with the 'C' bit set MUST send its own query for the same name, type and class, with the 'C' bit clear. If a response is received with the 'T' bit clear, then a conflict has been detected. An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD log them. Upon detecting a conflict, an LLMNR responder MUST immediately stop using the name in response to LLMNR queries received over any supported protocol, if the source IP address in the response, interpreted as an unsigned integer, is less than the source IP address in the uniqueness verification query. After stopping the use of a name, the responder MAY elect to configure a new name. However, since name reconfiguration may be disruptive, this is not required, and a responder may have been configured to respond to multiple names so that alternative names may already be available." Delete DEFEND_INTERVAL from Section 7. ---------------------------------------------------------------------------------- Issue 81: Conflicts from Healing of a Network Partition Submitter: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: October 8, 2004 Reference: Document: LLMNR-38 Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: When a previously partitioned network heals, revealing one or more name conflicts, LLMNR does not detect these conflicts since uniqueness verification is not done periodically and responses are sent via unicast, not multicast. -- 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 Mar 13 12:26:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26443 for ; Sun, 13 Mar 2005 12:26:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAWme-000ILT-Av for namedroppers-data@psg.com; Sun, 13 Mar 2005 17:21:44 +0000 Received: from [216.218.215.99] (helo=virgin.ww.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DAWmd-000ILH-H3 for namedroppers@ops.ietf.org; Sun, 13 Mar 2005 17:21:43 +0000 Received: from virgin.ww.net (localhost [127.0.0.1]) by virgin.ww.net (8.13.1/8.13.1) with ESMTP id j2DHLfVE047943 for ; Sun, 13 Mar 2005 18:21:41 +0100 (CET) (envelope-from alexis@nlnetlabs.nl) Received: (from root@localhost) by virgin.ww.net (8.13.1/8.13.1/Submit) id j2DHLfgQ047942 for namedroppers@ops.ietf.org; Sun, 13 Mar 2005 18:21:41 +0100 (CET) (envelope-from alexis@nlnetlabs.nl) Date: Sat, 12 Mar 2005 15:52:38 +0100 From: Alexis Yushin To: namedroppers@ops.ietf.org Subject: dns vs gnutella Message-ID: <20050312145238.GA34885@virgin.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Status: RO Lines: 14 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_24_48 autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, I was wondering if anybody ever thought of using a gnutella-like technology in lieu of the traditional dns to achieve the same functionality. I don't want to begin a discussion on why and/or how that would or not work. At this point I merely would like to know if anyone on this list is aware of any such project. If you wonder why I am asking this - a working theory is that a hierarchical lookup mechanism might not be suitable for a profoundly non-hierarchical network. Alexis -- 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 Mar 13 18:22:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20635 for ; Sun, 13 Mar 2005 18:22:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAcL4-00096l-EQ for namedroppers-data@psg.com; Sun, 13 Mar 2005 23:17:38 +0000 Received: from [213.248.199.20] (helo=mx2.nominet.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DAcL2-00096V-6w for namedroppers@ops.ietf.org; Sun, 13 Mar 2005 23:17:36 +0000 Received: from notes1.nominet.org.uk (wds1.dhcp.nominet.org.uk [213.248.197.128]) by mx2.nominet.org.uk (Postfix) with ESMTP id 728F554E07; Sun, 13 Mar 2005 23:17:20 +0000 (GMT) In-Reply-To: <20050312145238.GA34885@virgin.nlnetlabs.nl> To: Alexis Yushin Cc: namedroppers@ops.ietf.org Subject: Re: dns vs gnutella MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Jay Daley Date: Sun, 13 Mar 2005 23:17:34 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 03/13/2005 11:17:34 PM, Serialize complete at 03/13/2005 11:17:34 PM Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_20 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alexis > I was wondering if anybody ever thought of using a gnutella-like technology > in lieu of the traditional dns to achieve the same functionality. I'm not sure if this is exactly what you are looking for, but we've been thinking about P2P DNS for several months and have a reasonably well developed plan for how it might work. However we are some way off coding and there are still some big gaps in that plan. This work is partly motivated by the view that DDoS is inherently possible so long as asymmetry exists between the attacker and defender, which P2P reduces. If you combine this with DNSSEC then you maintain the integrity of the zone (and the authority of the registry) because only the key holder can create genuine records. BTW I don't think this is a new idea. A working P2P DNS was built using distributed hash tables: http://www.pdos.lcs.mit.edu/chord/papers/ddns.pdf Jay Daley Nominet 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 Sun Mar 13 19:55:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25803 for ; Sun, 13 Mar 2005 19:55:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAdoI-000Kuz-PP for namedroppers-data@psg.com; Mon, 14 Mar 2005 00:51:54 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DAdoH-000Kug-EA for namedroppers@ops.ietf.org; Mon, 14 Mar 2005 00:51:53 +0000 Received: (qmail 8058 invoked from network); 14 Mar 2005 01:36:26 -0000 Received: from unknown (HELO necom830.hpcl.titech.ac.jp) (61.80.154.102) by necom830.hpcl.titech.ac.jp with SMTP; 14 Mar 2005 01:36:26 -0000 Message-ID: <4234E068.4030401@necom830.hpcl.titech.ac.jp> Date: Mon, 14 Mar 2005 09:52:56 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Dean Anderson CC: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dean Anderson wrote: >>That is not a valid reason to avoid DNSSEC. Anycast does work with >>short-lived TCP. > > > Uhh, no, it doesn't. Not when Per-packet-load-balancing (PPLB) is used > anywhere. That was a point of you instantly denied in last Decemner. If you use PPLB in a way you think appropriate, unicast TCP suffers badly. > This was discussed at length some little while back. I think there was two follow-ups, one of which was mine. 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 Mon Mar 14 03:38:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27276 for ; Mon, 14 Mar 2005 03:38:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAl1n-0002Zo-Lb for namedroppers-data@psg.com; Mon, 14 Mar 2005 08:34:19 +0000 Received: from [194.109.24.28] (helo=smtp-vbr8.xs4all.nl) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DAl1d-0002Ys-69 for namedroppers@ops.ietf.org; Mon, 14 Mar 2005 08:34:09 +0000 Received: from [213.154.224.61] (ferret-e.nlnetlabs.nl [213.154.224.61]) by smtp-vbr8.xs4all.nl (8.12.11/8.12.11) with ESMTP id j2E8Y3Va046825; Mon, 14 Mar 2005 09:34:03 +0100 (CET) (envelope-from erik@nlnetlabs.nl) Message-ID: <42354C80.50301@nlnetlabs.nl> Date: Mon, 14 Mar 2005 09:34:08 +0100 From: Erik Rozendaal User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexis Yushin CC: namedroppers@ops.ietf.org Subject: Re: dns vs gnutella References: <20050312145238.GA34885@virgin.nlnetlabs.nl> In-Reply-To: <20050312145238.GA34885@virgin.nlnetlabs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alexis Yushin wrote: > Hi, > > I was wondering if anybody ever thought of using a gnutella-like technology > in lieu of the traditional dns to achieve the same functionality. Distributed hash tables (DHTs) are getting a lot of attention in the peer-to-peer community and some research has been done on implementing DNS on top of a DHT. For example: . 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 Mon Mar 14 04:32:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03251 for ; Mon, 14 Mar 2005 04:32:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAltT-000BNe-NO for namedroppers-data@psg.com; Mon, 14 Mar 2005 09:29:47 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DAltS-000BNN-Bf for namedroppers@ops.ietf.org; Mon, 14 Mar 2005 09:29:46 +0000 Received: (qmail 11509 invoked from network); 14 Mar 2005 10:14:26 -0000 Received: from unknown (HELO necom830.hpcl.titech.ac.jp) (61.80.155.18) by necom830.hpcl.titech.ac.jp with SMTP; 14 Mar 2005 10:14:26 -0000 Message-ID: <423559C9.3020002@necom830.hpcl.titech.ac.jp> Date: Mon, 14 Mar 2005 18:30:49 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack References: <20050306162837.A1BC0190D4@sa.vix.com> In-Reply-To: <20050306162837.A1BC0190D4@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>DNSSEC can't be helpful, unless parent zones sign glues, which >>causes serious management troubles. > this statement, however, is not. My apologies. DNSSEC can't be helpful, even if parent zones sign glues. Sloppy DNSSEC implementations do not distinguish glue As signed by their parent zones and As signed by authorities, just as sloppy DNS implementations do not distinguish glue As supplied by their parent zones and As signed by authorities. 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 Mon Mar 14 11:31:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20319 for ; Mon, 14 Mar 2005 11:31:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAsPu-000Bdc-WA for namedroppers-data@psg.com; Mon, 14 Mar 2005 16:27:42 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DAsPt-000BdO-OK for namedroppers@ops.ietf.org; Mon, 14 Mar 2005 16:27:42 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2EGRSB6009490 for ; Mon, 14 Mar 2005 11:27:28 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j2EGRSGM009489 for namedroppers@ops.ietf.org; Mon, 14 Mar 2005 11:27:28 -0500 (EST) (envelope-from namedroppers) Received: from [216.218.215.99] (helo=virgin.ww.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DA7yq-000AoE-DE for namedroppers@ops.ietf.org; Sat, 12 Mar 2005 14:52:40 +0000 Received: from virgin.ww.net (localhost [127.0.0.1]) by virgin.ww.net (8.13.1/8.13.1) with ESMTP id j2CEqdpv035107 for ; Sat, 12 Mar 2005 15:52:39 +0100 (CET) (envelope-from alexis@virgin.ww.net) Received: (from alexis@localhost) by virgin.ww.net (8.13.1/8.13.1/Submit) id j2CEqctr035106 for namedroppers@ops.ietf.org; Sat, 12 Mar 2005 15:52:38 +0100 (CET) (envelope-from alexis) Date: Sat, 12 Mar 2005 15:52:38 +0100 From: Alexis Yushin To: namedroppers@ops.ietf.org Subject: dns vs gnutella Message-ID: <20050312145238.GA34885@virgin.ww.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Hi, I was wondering if anybody ever thought of using a gnutella-like technology in lieu of the traditional dns to achieve the same functionality. I don't want to begin a discussion on why and/or how that would or not work. At this point I merely would like to know if anyone on this list is aware of any such project. If you wonder why I am asking this - a working theory is that a hierarchical lookup mechanism might not be suitable for a profoundly non-hierarchical network. Alexis -- 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 Mar 14 12:01:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22928 for ; Mon, 14 Mar 2005 12:01:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAstb-000Fkm-I1 for namedroppers-data@psg.com; Mon, 14 Mar 2005 16:58:23 +0000 Received: from [205.150.200.164] (helo=pike.sandelman.ca) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DAstS-000Fjz-Eh for namedroppers@ops.ietf.org; Mon, 14 Mar 2005 16:58:14 +0000 Received: from sandelman.ottawa.on.ca (cose-a.srv.gc.ca [198.103.103.167]) by pike.sandelman.ca (Postfix) with ESMTP id A962964BF2; Mon, 14 Mar 2005 11:58:13 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 95194BCB6; Sun, 13 Mar 2005 13:35:50 -0500 (EST) To: Alexis Yushin Cc: namedroppers@ops.ietf.org Subject: Re: dns vs gnutella In-Reply-To: Message from Alexis Yushin of "Sat, 12 Mar 2005 15:52:38 +0100." <20050312145238.GA34885@virgin.nlnetlabs.nl> References: <20050312145238.GA34885@virgin.nlnetlabs.nl> X-Mailer: MH-E 7.82; nmh 1.0.4+dev; XEmacs 21.4 (patch 17) Date: Sun, 13 Mar 2005 13:35:50 -0500 Message-ID: <16503.1110738950@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Alexis" == Alexis Yushin writes: Alexis> I was wondering if anybody ever thought of using a Alexis> gnutella-like technology in lieu of the traditional dns to Alexis> achieve the same functionality. Assuming that you have an appropriate trust mechanism, it could work. Take a look at DUNDi. It attempts to replace DNS-born ENUM with a different mechanism. - -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQjSIBYqHRg3pndX9AQFHYgP/Ybmxro1NV7KDzTbOiaom7rihcnAyyVlA LaHzVWh4IXPIfn/ZJDm4KHbN5xmu+Q2kZ3sp3cqcVTeQk+ppaG91dBI4Upa1o2jm AOWVafVsHEF/nIntNczsSa26XYf/ExhHH793ZsiFxDxgCTIcWnaJkYm7UMzn66NX y4XodZ+U7r0= =7RBy -----END PGP SIGNATURE----- -- 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 Mar 14 14:16:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09060 for ; Mon, 14 Mar 2005 14:16:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAuzR-0007Um-1G for namedroppers-data@psg.com; Mon, 14 Mar 2005 19:12:33 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DAuzN-0007UT-0R for namedroppers@ops.ietf.org; Mon, 14 Mar 2005 19:12:29 +0000 Received: from [10.31.32.136] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2EJCCZN010243; Mon, 14 Mar 2005 14:12:13 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Mon, 14 Mar 2005 14:12:30 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: repeating my mic comment on auth denial Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Since the minutes of the meeting won't be out for a while, I thought I would repeat my comments at the mic regarding the authenticated denial issue. (Fresh from a reading of the nsec3 draft, with the prospect of reading the bert proposal ahead of me.) My comment is: Before the WG commits serious resources to choosing one "new" approach to authenticated denial there is a need to hold a number of operations oriented workshops. "Serious resources" means WG last calls, anything put before the IESG, etc. Operations-oriented means software tools in our hands, and some semblance of reality in the test environment and scenario. Why: The NSEC3 document reminds me greatly of RFC 2065, a security-oriented document (salts, hashes, iterations, oh my) with unclear impacts on operations. The first workshops based on RFC 2065 - starting in Knivsta, SE, May, 1999 - represented about 5 years of protocol development. It was still a few more years until the operator "friendly" DS RR was defined. Even with 5 years of security expertise as input RFC 2065 was so operations unfriendly that it took years to fix the problem and years more to generate a new definition. I don't want to repeat that experience. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 cilinca8c@azo.com Thu Mar 17 01:54:32 2005 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 BAA21205; Thu, 17 Mar 2005 01:54:31 -0500 (EST) Received: from [217.72.212.232] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DBoy4-0006ch-Bk; Thu, 17 Mar 2005 01:58:53 -0500 Received: from spaghetti.cilinca8c@azo.com ([132.151.6.1]) by plaid.cilinca8c@azo.com with MailEnable ESMTP; Thu, 17 Mar 2005 00:57:33 -0600 Date: Thu, 17 Mar 2005 00:57:33 -0600 Message-Id: <679431311.87631@taylyr> From: kadienne shaver To: Discuss Subject: soft at incredibly low prices MIME-Version: 1.0 Content-Type: text/html; charset="iso-0721-9" Content-Transfer-Encoding: 7Bit Content-Description: grimace sixth decisive X-Spam-Score: 6.2 (++++++) X-Spam-Flag: YES X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Content-Transfer-Encoding: 7Bit

Reach for innovation...reach for what everyone is using

Microsoft Office XP Pro - only $60.00 at the oem store

From owner-namedroppers@ops.ietf.org Thu Mar 17 06:46:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13910 for ; Thu, 17 Mar 2005 06:46:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBtNp-000LuG-K3 for namedroppers-data@psg.com; Thu, 17 Mar 2005 11:41:45 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DBtNm-000Lsf-CG for namedroppers@ops.ietf.org; Thu, 17 Mar 2005 11:41:42 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 351B233C33; Thu, 17 Mar 2005 11:41:29 +0000 (GMT) Message-ID: <42396CEA.1040604@algroup.co.uk> Date: Thu, 17 Mar 2005 11:41:30 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: repeating my mic comment on auth denial References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > Since the minutes of the meeting won't be out for a while, I thought I > would repeat my comments at the mic regarding the authenticated denial > issue. (Fresh from a reading of the nsec3 draft, with the prospect of > reading the bert proposal ahead of me.) > > My comment is: > > Before the WG commits serious resources to choosing one "new" approach > to authenticated denial there is a need to hold a number of operations > oriented workshops. "Serious resources" means WG last calls, anything > put before the IESG, etc. Operations-oriented means software tools in > our hands, and some semblance of reality in the test environment and > scenario. > > Why: > > The NSEC3 document reminds me greatly of RFC 2065, a security-oriented > document (salts, hashes, iterations, oh my) with unclear impacts on > operations. The first workshops based on RFC 2065 - starting in > Knivsta, SE, May, 1999 - represented about 5 years of protocol > development. It was still a few more years until the operator > "friendly" DS RR was defined. > > Even with 5 years of security expertise as input RFC 2065 was so > operations unfriendly that it took years to fix the problem and years > more to generate a new definition. I don't want to repeat that experience. Don't worry, we are committed to producing the tools required to test NSEC3. 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 Mar 17 07:25:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17506 for ; Thu, 17 Mar 2005 07:25:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBu1z-0002K6-F9 for namedroppers-data@psg.com; Thu, 17 Mar 2005 12:23:15 +0000 Received: from [195.54.233.67] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBu1w-0002Jp-Q8 for namedroppers@ops.ietf.org; Thu, 17 Mar 2005 12:23:13 +0000 Received: from shaun.rfc1035.com (shaun.rfc1035.com [195.54.233.67]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j2HCN3GW007139; Thu, 17 Mar 2005 12:23:03 GMT To: Ben Laurie cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: repeating my mic comment on auth denial In-Reply-To: Message from Ben Laurie of "Thu, 17 Mar 2005 11:41:30 GMT." <42396CEA.1040604@algroup.co.uk> Date: Thu, 17 Mar 2005 12:23:03 +0000 Message-ID: <7138.1111062183@shaun.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Ben" == Ben Laurie writes: >> Even with 5 years of security expertise as input RFC 2065 was >> so operations unfriendly that it took years to fix the problem >> and years more to generate a new definition. I don't want to >> repeat that experience. Ben> Don't worry, we are committed to producing the tools required Ben> to test NSEC3. Who's "we"? Producing tools and what have you to test NSEC3 is all very well. But if they're coming from the people who write the NSEC3 draft, that test suite could be unsatisfactory. Please note I'm not questioning the integrity of those writing the NSEC3 drafts. I am saying that if the test suite comes from the same source as NSEC3, the tests could be relying on knowledge that's in the heads of the authors but not written in the spec; or the tests have too narrow a focus; etc, etc. That said, Ed's point is well-made. Once the NSEC3 draft is done, there should be a period of experimental deployment with workshops and interoperability events so that the draft can be tweaked if operational experience suggests that's needed. -- 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 Mar 17 12:40:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28467 for ; Thu, 17 Mar 2005 12:40:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DByti-000EbI-1x for namedroppers-data@psg.com; Thu, 17 Mar 2005 17:35:02 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DBytd-000EaQ-P4 for namedroppers@ops.ietf.org; Thu, 17 Mar 2005 17:34:58 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2HHYqQM035984 for ; Thu, 17 Mar 2005 12:34:52 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.1.2.2.20050314145125.04286690@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 17 Mar 2005 12:34:32 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: nsec3 with one hash algorithm: SHA-224 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>Rolling hash algorithms (from mandatory to optional) is problematic, as >>was previously shown on this list. Since there is also no real profit in >>supporting more then one algorithm, we can obsolete the algorithm >>field from the RDATA, and settle on a single algorithm for nsec3: SHA-224 >>(rfc-3874). >> >>Any comments ? > >I suggest using a longer algorithm (SHA-512), and then specifying a >variable number of bits to truncate to, to enable the signer to achieve >their own balance between non-enumerability and minimization on-wire >packet size. For small zones, this could be less than traditional NSEC >if people don't care about enumerability (if we make sure we treat >weak hash algorithms right). SHA-512 is much slower than SHA-1, somewhat slower than SHA-1, given that for each negative answer authorative server frequently needs to perform 3 HASH operations to complete the wild card proof, IMHO it is prudent to go for fast over slow. >I also think that those wanting to support weak algorithms, AND those who >are concerned to treat QNAME/label hash collisions right (despite their >unlikelihood) AND those who don't give a fig about enumerability and want >to use minimum CPU cycles will EACH want to support an identity hash >algorithm. That means you need the field anyway (conceivably it >could be 0 for identity, or a number of octets to which SHA-512 is >truncated). > >My personal view on the necessity for identity algorithm is that it's >only needed if you want to support weak / deliberately over truncated >hash algorithms, but I understand others' points of view. Reading this thread is making me have a flashback to pre-RFC2065, people are worrying to much about "crypto" stuff, not if the modified DNS will work!! There is NO NEED to pick algorithm now, before any NSEC++ is standardized we need draft documents, implementations, testing, workshops and if things work, new specs. For now we can use either MD5 or SHA-1 for simplicity. All testing should be done using a type code that is different from the final one, I suggest 47xx where xx is the number followed by number of the NSEC++ proposal in question. Olafur -- 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 Mar 17 13:13:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02200 for ; Thu, 17 Mar 2005 13:13:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBzSi-000Jj7-3X for namedroppers-data@psg.com; Thu, 17 Mar 2005 18:11:12 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBzSd-000Jik-NC for namedroppers@ops.ietf.org; Thu, 17 Mar 2005 18:11:07 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id AC15DC2DFE; Thu, 17 Mar 2005 18:11:06 +0000 (GMT) Date: Thu, 17 Mar 2005 18:11:02 +0000 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?=C3=93lafur_Gu=C3=B0mundsson_=2FDNSEXT_co-chair?= , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: nsec3 with one hash algorithm: SHA-224 Message-ID: <2EA3A5A67BF9D16127BD96DF@[192.168.100.25]> In-Reply-To: <6.2.1.2.2.20050314145125.04286690@localhost> References: <6.2.1.2.2.20050314145125.04286690@localhost> X-Mailer: Mulberry/4.0.0a5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable --On 17 March 2005 12:34 -0500 "=C3=93lafur Gu=C3=B0mundsson /DNSEXT = co-chair"=20 wrote: > There is NO NEED to pick algorithm now, Yes. You are right on this. Apologies. However, I think *is* necessary at a relatively early stage to determine a) Whether support of an identity hash is necessary/desirable and whether fallback to that is necessary (because if it is - and I think it isn't - then we need to ensure it's covered in the spec, and if not, we need to ensure it's not covered). b) Whether support for short wire format weak hashes is desirable. c) Alternatively, whether there is ANY need to support more than one hash algorithm at all. Once we have decided (a) and (b), we (well I) can stop blathering about collisions etc., and we can say "the design decision was to do X" (whatever that is). All the above decisions don't seem to me to be about algorithm choice, they seem to me to be about protocol design. For instance, if we decide NOT to support fallback to identity hash etc., then if (contrary to my own view) collisions are a problem later, there is a substantial amount of protocol redesign to do (I think). YMMV. 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 Mar 17 14:24:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09837 for ; Thu, 17 Mar 2005 14:24:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DC0ZH-0002XR-Ex for namedroppers-data@psg.com; Thu, 17 Mar 2005 19:22:03 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DC0ZF-0002X4-N5 for namedroppers@ops.ietf.org; Thu, 17 Mar 2005 19:22:02 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2HJLpRu036327; Thu, 17 Mar 2005 14:21:52 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Thu, 17 Mar 2005 14:21:36 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Rants on auth denial Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I called a friend and ranted for a few minutes on the topic of authenticated denial. Because of time constraints, it was good to get it out of my system, albeit in a way only one other could hear. In this message I'll sketch out the points I made, if I can recall them...this is more rant than discussion fodder or a set of conclusions. It' all IMHO. 1) On-line signing is a non-starter for performance reasons. DDoS - there are many ways to filter out suspect packets and dump them on the floor. However, it is hard to profile bad DNS packets, whose intent is to incur on-line signing of a negative answer. Once exposed to packets generated by DDos (whether or not on-line signing is done), the only way a server is to survive is to be able to dispatch the packets faster than they arrive. (Think Queuing/Markov theory, distribution of inter-arrival times and service times, probability of there being 0 waiters in the queue.) Routers can work at wire speed plus, and simple lookup has a chance too. But I'm afraid crypto is out of the question. 2) On-line signing is a non-starter for key management issues. Have one key for all servers? The problem is that one compromised server compromises all. One key per server? Then my RRSet will be large. Want a different key for the off-line signing? Can't indicate that in DNSSEC, we did try that once - maybe we could make it work this time, with a protocol change. 3) Making simplifying assumptions about server layout restricts operational flexibility. I should be able to get a slave machine from someone without having to give them secrets that could sign my zone. (TSIG is okay, it can't sign the zone.) I should be able to deploy machines based on demand - both queries per second and latency - without worrying about having to scale or compromise key management practices. 4) I really think that pre-computing the answers, as NSEC does, is a bigger asset than we've realized. It is what allows us to not fear DDoS as much. It also removes the problems of key management. 5) Why is zone walking an issue? I don't buy privacy as the motivation. I don't mean to argue this in this venue, but I see that you can get the gTLD zone files pretty easily. I don't see a lot of outcry over abuses of those zones with this availability. I don't mean to aver that this is a solid rebuttal to those concerned about privacy. But as a naive (certainly in the way of privacy and the law) person, I don't see "it." Perhaps ICANN (for the gTLDs) is a more appropriate venue to argue this. 6) I don't think that zone walking is that great a deal for the registries. Unless the registry just doesn't want the list of registrants known. For a registry's DNS, I am not sold that zone walk traffic will be significantly noticeable buried with all the other DNS nuisance traffic. 7) However I do think there is a zone walking issue in other places. For instance: 7a) I want to put my X509 certificates for my employees on-line. Yet I mark the company phone book "proprietary and confidential." 7b) One of the advantages of IPv6 addresses are that they are sparse. This makes randomly choosing an target address less useful than in IPv4. If I can zone walk the IPv6 reverse tree (if it exists, it might if we want opportunistic encryption, etc.), the sparseness advantage disappears. What about RFID? As you might see, there are future uses for DNS and DNSSEC that may open up the problem space. 8) Choosing one approach that is appropriate for only those who care "now" is myopic. We can't survive with different camps operating a common resource like DNS in different ways - fragmentation is bad. 9) We have to remember that any client-server protocol has to keep in mind that there are two sets of semantics. The server-side and client-side can be different. I say this as background to the issue of whether H(name) is a problem or not. I don't think it's that big a deal. However, H(name) has to somehow avoid flatting a zone's (sub)tree - and we can't assume that only one-label zones will use an alt-NSEC. 10) DNSSEC lacks a really cool feature - the ability to upgrade your security without making you less secure. E.g., I stipulate that my zone are only signed with a super safe crypto algorithm. If super safe isn't super available, then the majority of the world downgrades me to unsigned (with respect to any popular crypto algorithm). I mention this because if a zone elects to use some non-NSEC approach in place of NSEC, they appear improperly (or not at all) secure. My conclusion is that someone (not me, I'm busy now with EPP and DNSSEC, etc.) needs to work out a way to make per-label hashing work. I think that this is more promising than on-line signing approaches. I think that this is also more promising than hashing a whole name. After all, it's not the tree structure we want to hide, but the label identities. Can this be done without a protocol change? Probably not. I'm not calling for a halt to the DNSSECbis documents, etc., but I still haven't seen the light on how we can overcome what's in #10. Even with a transition mechanism in place. It's been a while since I've ranted on this, see this message around the last time I thought much on this (near the IETF in San Diego): http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01406.html My opinion on the option I label 2b2 may be different because of #9 above - we don't need to create a name space for the hashes. The client just needs to know how to hash what it has (the labels in the QNAME) in the same way as the server did to generate the response. The server does need to have a list of the hashes for all the labels/names in the zone, but they don't need to be tied to the tree. So what if H(label).example is the same as label2.example.? I don't see that as a problem. The approach to pre-computed responses approaches is to convince the client that the server executed RFC 1034, 4.3.2 (as amended) correctly. That's what we need to accomplish. NSEC does this now, but allows enumeration. One-way hashes theoretically can stop this. There is one item I'd challenge anyone thinking about all this ... say something about troubleshooting. How can an operator verify that the responses being given are correct and not the result of a bad floating point accelerator or buggy cryptolibrary? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 17 17:01:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25121 for ; Thu, 17 Mar 2005 17:01:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DC2zH-000LFY-Dr for namedroppers-data@psg.com; Thu, 17 Mar 2005 21:57:03 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DC2zC-000LEB-WD for namedroppers@ops.ietf.org; Thu, 17 Mar 2005 21:57:00 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.3/8.13.3/Debian-6) with ESMTP id j2HLuE3G019628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Mar 2005 22:56:21 +0100 From: Simon Josefsson To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: nsec3 with one hash algorithm: SHA-224 References: <6.2.1.2.2.20050314145125.04286690@localhost> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Blog: http://www.livejournal.com/users/jas4711/ X-Hashcash: 1:21:050317:ogud@ogud.com::k7ztlpEfr1IBXlVe:1MsN X-Hashcash: 1:21:050317:namedroppers@ops.ietf.org::RDBhFbHGsD2H3ih7:0y8R Date: Thu, 17 Mar 2005 22:55:52 +0100 In-Reply-To: <6.2.1.2.2.20050314145125.04286690@localhost> (=?iso-8859-1?Q?=D3lafur=09Gu=F0mundsson's?= message of "Thu, 17 Mar 2005 12:34:32 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Ólafur Guðmundsson /DNSEXT co-chair writes: > > >>>Rolling hash algorithms (from mandatory to optional) is problematic, as >>>was previously shown on this list. Since there is also no real profit in >>>supporting more then one algorithm, we can obsolete the algorithm >>>field from the RDATA, and settle on a single algorithm for nsec3: SHA-224 >>>(rfc-3874). >>> >>>Any comments ? >> >>I suggest using a longer algorithm (SHA-512), and then specifying a >>variable number of bits to truncate to, to enable the signer to achieve >>their own balance between non-enumerability and minimization on-wire >>packet size. For small zones, this could be less than traditional NSEC >>if people don't care about enumerability (if we make sure we treat >>weak hash algorithms right). > > SHA-512 is much slower than SHA-1, somewhat slower than SHA-1, given > that for each negative answer authorative server frequently needs to perform > 3 HASH operations to complete the wild card proof, IMHO it is prudent to > go for fast over slow. Keep in mind that a public-key verify operation is still necessary. I believe that the time spent on computing _any_ widely used hash function, including SHA-*, is insignificant compared to the delay for the public-key verify operation. My point is that hash function speed should not be a major argument in deciding which hash function use. 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 Mar 18 06:19:53 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22268 for ; Fri, 18 Mar 2005 06:19:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCFRd-0007PM-GS for namedroppers-data@psg.com; Fri, 18 Mar 2005 11:15:09 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DCFRZ-0007NW-2p for namedroppers@ops.ietf.org; Fri, 18 Mar 2005 11:15:05 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id EDD9133C33; Fri, 18 Mar 2005 11:15:01 +0000 (GMT) Message-ID: <423AB838.2000504@algroup.co.uk> Date: Fri, 18 Mar 2005 11:15:04 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Rants on auth denial References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > 9) We have to remember that any client-server protocol has to keep in > mind that there are two sets of semantics. The server-side and > client-side can be different. I say this as background to the issue of > whether H(name) is a problem or not. I don't think it's that big a > deal. However, H(name) has to somehow avoid flatting a zone's (sub)tree > - and we can't assume that only one-label zones will use an alt-NSEC. You make this statement as if it is somehow obvious that per-label hashes are good, and whole-name hashes are bad. You use the term "flattening the zone" as if NSEC3 records had anything to do with the shape of the zone. The zone is the shape it is, regardless of how you deny existence of non-existent names. Enlighten me - what are you on about? > 10) DNSSEC lacks a really cool feature - the ability to upgrade your > security without making you less secure. E.g., I stipulate that my zone > are only signed with a super safe crypto algorithm. If super safe isn't > super available, then the majority of the world downgrades me to > unsigned (with respect to any popular crypto algorithm). I mention this > because if a zone elects to use some non-NSEC approach in place of NSEC, > they appear improperly (or not at all) secure. You mean they appear insecure to a resolver that does not support the non-NSEC approach. > My conclusion is that someone (not me, I'm busy now with EPP and DNSSEC, > etc.) needs to work out a way to make per-label hashing work. I think > that this is more promising than on-line signing approaches. I think > that this is also more promising than hashing a whole name. After all, > it's not the tree structure we want to hide, but the label identities. I do not understand why this is better. > Can this be done without a protocol change? Probably not. I'm not > calling for a halt to the DNSSECbis documents, etc., but I still haven't > seen the light on how we can overcome what's in #10. Even with a > transition mechanism in place. > > It's been a while since I've ranted on this, see this message around the > last time I thought much on this (near the IETF in San Diego): > > http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01406.html > > My opinion on the option I label 2b2 may be different because of #9 > above - we don't need to create a name space for the hashes. The client > just needs to know how to hash what it has (the labels in the QNAME) in > the same way as the server did to generate the response. The server does > need to have a list of the hashes for all the labels/names in the zone, > but they don't need to be tied to the tree. So what if H(label).example > is the same as label2.example.? I don't see that as a problem. > > The approach to pre-computed responses approaches is to convince the > client that the server executed RFC 1034, 4.3.2 (as amended) correctly. > That's what we need to accomplish. NSEC does this now, but allows > enumeration. One-way hashes theoretically can stop this. > > There is one item I'd challenge anyone thinking about all this ... say > something about troubleshooting. How can an operator verify that the > responses being given are correct and not the result of a bad floating > point accelerator or buggy cryptolibrary? If an operator wants to check the responses, all they need do is perform the hashes with an independent implementation and verify that it matches the hashes in the zones. I'd note that bad crypto implementations tend to not go undetected for long, since they produce nonsense or verification failures. 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 Mar 18 06:30:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22999 for ; Fri, 18 Mar 2005 06:30:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCFdn-0009D4-P1 for namedroppers-data@psg.com; Fri, 18 Mar 2005 11:27:43 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCFdk-0009Ci-Oh for namedroppers@ops.ietf.org; Fri, 18 Mar 2005 11:27:40 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 037BAE7EA2; Fri, 18 Mar 2005 11:27:38 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: Re: Rants on auth denial In-Reply-To: Message-Id: <20050318112738.037BAE7EA2@mx1.nominet.org.uk> Date: Fri, 18 Mar 2005 11:27:38 +0000 (GMT) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > In this message I'll sketch out the points I made, if I can recall > them...this is more rant than discussion fodder or a set of > conclusions. Much of this has been discussed previously; I don't wish to open these debates again but feel that some response is neccessary. To summarise the salient points: 1. Privacy of zone data is an issue for some TLDs. (These include several not-for-profit ccTLDs so greed isn't neccessarily the primary motivation.) 2. Even if privacy isn't an issue, the availabilty of NSEC RRs may result in substantial `nuisance' traffic as they may be used to create frequent snapshots to diff for name availabilty in registry-operated zones. Zone walking may employ parallel techniques so the resultant traffic may not be well-behaved. 3. Online signing is viewed (by us at least) as an interim solution to expidite the deployment of DNSSEC rather than waiting for `DNSSECter'. The performance issue has been noted but it's been suggested that suitably accelerated hardware should be able to do this at wire speed at gigabit rates (though AFAICT the impact of a move to longer keys hasn't been discussed). 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 Fri Mar 18 13:41:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08831 for ; Fri, 18 Mar 2005 13:41:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCMK3-000BIt-PD for namedroppers-data@psg.com; Fri, 18 Mar 2005 18:35:47 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DCMK2-000BI3-32 for namedroppers@ops.ietf.org; Fri, 18 Mar 2005 18:35:46 +0000 Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1DCMJy-0007lz-E5; Fri, 18 Mar 2005 19:35:42 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.50) id 1DCMJw-0003Bw-Sk; Fri, 18 Mar 2005 19:35:40 +0100 From: Florian Weimer To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Rants on auth denial References: Date: Fri, 18 Mar 2005 19:35:40 +0100 In-Reply-To: (Edward Lewis's message of "Thu, 17 Mar 2005 14:21:36 -0500") Message-ID: <87psxwdcoz.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Edward Lewis: > 6) I don't think that zone walking is that great a deal for the > registries. Some registries have expressed their wishes to keep their zone files to themselves. Not everyone is under contractual obligation to publish them, and there seem to be strong business interests not do so if at all possible (e.g. if you are a legacy ccTLD not yet under ICANN control). I don't buy the privacy argument either because such registries happily expose WHOIS information to the general public, without a way to opt out and lacking a clear technical need for that data (domain WHOIS is mostly used by lawyers). -- 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 Mar 20 22:12:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22050 for ; Sun, 20 Mar 2005 22:12:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDDFZ-000DSk-MC for namedroppers-data@psg.com; Mon, 21 Mar 2005 03:06:41 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDDFW-000DRs-6X for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 03:06:38 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2L36PaB057206; Sun, 20 Mar 2005 22:06:25 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050318112738.037BAE7EA2@mx1.nominet.org.uk> <423AB838.2000504@algroup.co.uk> <87psxwdcoz.fsf@deneb.enyo.de> References: <20050318112738.037BAE7EA2@mx1.nominet.org.uk> <423AB838.2000504@algroup.co.uk> <87psxwdcoz.fsf@deneb.enyo.de> Date: Sun, 20 Mar 2005 22:06:17 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Rants on auth denial Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Trying to tie all the responses back to one thread... At 11:15 +0000 3/18/05, Ben Laurie wrote: >Edward Lewis wrote: >> 9) We have to remember that any client-server protocol has to keep in mind >>that there are two sets of semantics. The server-side ... >...snip... >>... H(name) has to somehow avoid flatting a zone's (sub)tree - and we can't >>assume that only one-label zones will use an alt-NSEC. > >You make this statement as if it is somehow obvious that per-label hashes >are good, and whole-name hashes are bad. You use the term "flattening the >zone" as if NSEC3 records had anything to do with the shape of the zone. >The zone is the shape it is, regardless of how you deny existence of >non-existent names. Enlighten me - what are you on about? The problem with demonstrating the closest encloser that is handled by having to either include extra neg-answer records (to show that the encloser identified is indeed closest) or to stuff in records at otherwise empty non-terminals. >> 10) DNSSEC lacks a really cool feature - the ability to upgrade your >>security without making you less secure. E.g., I stipulate ... >...snip... >>... mention this because if a zone elects to use some non-NSEC approach >>in place of NSEC, they appear improperly (or not at all) secure. > >You mean they appear insecure to a resolver that does not support the >non-NSEC approach. Yes, but this isn't just a problem for NSEC, it's a general design problem. >> My conclusion is that someone (not me, I'm busy now with EPP and >>DNSSEC, etc.) needs to work out a way to make per-label hashing ... >...snip... >>... also more promising than hashing a whole name. After all, it's not the >>tree structure we want to hide, but the label identities. > >I do not understand why this is better. Not having to mess with empty non-terminals, better handling of multi-label-depth zones. >> Can this be done without a protocol change? Probably not. I'm not >>calling for a halt to the DNSSECbis documents, etc., but I still haven't >>seen the light on how we can overcome what's in #10. Even with a >>transition mechanism in place. >...snip... >>... verify that the responses being given are correct and not the result >>of a bad floating point accelerator or buggy cryptolibrary? > >If an operator wants to check the responses, all they need do is perform >the hashes with an independent implementation and verify that it matches >the hashes in the zones. > >I'd note that bad crypto implementations tend to not go undetected for >long, since they produce nonsense or verification failures. If operations were so simple. ;) I just see the existing documents as overly concerned with the "science" and not operationally vetted. At 11:27 +0000 3/18/05, Geoffrey Sisson wrote: >Edward Lewis writes: > >> In this message I'll sketch out the points I made, if I can recall >> them...this is more rant than discussion fodder or a set of >> conclusions. > >Much of this has been discussed previously; I don't wish to open these >debates again but feel that some response is neccessary. To summarise >the salient points: > >1. Privacy of zone data is an issue for some TLDs. (These include > several not-for-profit ccTLDs so greed isn't neccessarily the > primary motivation.) It wouldn't be fair to call motivation into question. But, usually when I say a problem has it's roots in situation "Y", I look into other solutions to situation "Y" for inspiration. My point is that I don't see how other solutions to privacy issues can play a role here. >2. Even if privacy isn't an issue, the availabilty of NSEC RRs may > result in substantial `nuisance' traffic as they may be used to > create frequent snapshots to diff for name availabilty in > registry-operated zones. Zone walking may employ parallel > techniques so the resultant traffic may not be well-behaved. "May" is the key word. >3. Online signing is viewed (by us at least) as an interim solution to > expidite the deployment of DNSSEC rather than waiting for `DNSSECter'. > The performance issue has been noted but it's been suggested that > suitably accelerated hardware should be able to do this at wire > speed at gigabit rates (though AFAICT the impact of a move to longer > keys hasn't been discussed). That may be. If so, they why is this a working group issue? An implementation is free to generate negative answers in any matter it chooses. An implementation may decide to "register" the name before and after the "victim" of an name error condition, construct the NSEC record, sign it, return the answer, then unregister the two names. This would make this legal with the NSEC record as defined without exposing "real" names. Anyone choosing to do this would face the operational impacts, nad have to deal with the key management and performance issues. None of what I have mentioned is related to interoperability, so I think it's not an IETF standards issue. At 19:35 +0100 3/18/05, Florian Weimer wrote: >* Edward Lewis: > >> 6) I don't think that zone walking is that great a deal for the >> registries. > >Some registries have expressed their wishes to keep their zone files >to themselves. Not everyone is under contractual obligation to >publish them, and there seem to be strong business interests not do so >if at all possible (e.g. if you are a legacy ccTLD not yet under ICANN >control). This is true. I don't mean to say that all registries should adhere to ICANN policies. I'm using such situations as examples that there is not technological disaster that needs to be solved. >I don't buy the privacy argument either because such registries >happily expose WHOIS information to the general public, without a way >to opt out and lacking a clear technical need for that data (domain >WHOIS is mostly used by lawyers). Ack. But I wanted to close with this: I suspect that non-registries may find they have problems with zone walking. If this *becomes* a reality, then the solution to zone walking had not be optimized for (or assume) registry situations. E.g., in such situations slaves might provided on machines on which the zone admin would not be willing to place a secret key authorized to sign the zone's answers. (Major registries assume they "own" all of their DNS servers.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 21 04:12:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08037 for ; Mon, 21 Mar 2005 04:12:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDIuH-0007vE-Tv for namedroppers-data@psg.com; Mon, 21 Mar 2005 09:09:05 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDIuE-0007uN-Ju for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 09:09:02 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 0D8FDC2DA4; Mon, 21 Mar 2005 09:08:59 +0000 (GMT) Date: Mon, 21 Mar 2005 09:08:51 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: Rants on auth denial Message-ID: In-Reply-To: References: <20050318112738.037BAE7EA2@mx1.nominet.org.uk> <423AB838.2000504@algroup.co.uk> <87psxwdcoz.fsf@deneb.enyo.de> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 20 March 2005 22:06 -0500 Edward Lewis wrote: > But I wanted to close with this: I suspect that non-registries may find > they have problems with zone walking. If this *becomes* a reality, then > the solution to zone walking had not be optimized for (or assume) > registry situations. At risk of reopening a can of worms, I think this is a reasonably point. NSEC was designed with a feature (enumerability) in that proved inimical to a subset of users of one particular type (registries) rather too late in the day. For whatever reason (too little registry involvement, too little w/g outreach, whatever, doesn't matter for this point) those designing the protocol did not know that a subset of this user type would not want enumerability. It would be a shame if we made the same mistake with the fix. It would surely be better to say "let us assume, that any current use-case for DNS might want to use the features of NSEC3 [currently also opt-in]". That probably sets a slightly higher bar in terms of "will this work for operators" but might at least delay the calls for NSEC4 when a different subset of users finds it doesn't work for them on deployment. I think this is the similar to Ed's point 8. It's precisely where NSEC fell down the first time. >> 3. Online signing is viewed (by us at least) as an interim solution to >> expidite the deployment of DNSSEC rather than waiting for `DNSSECter'. >> The performance issue has been noted but it's been suggested that >> suitably accelerated hardware should be able to do this at wire >> speed at gigabit rates (though AFAICT the impact of a move to longer >> keys hasn't been discussed). > > That may be. If so, they why is this a working group issue? The virtue of this group being a personal opinions group is I can (mostly) agree with Ed here. Online signing seems to me at best a sticking plaster, and at worst a recipe for disaster. Internet traffic would seem to grow faster than crypto-processing ability, and DoS traffic grows as a % of internet traffic. Even gigabit wire-speed signing can be done now for $reasonable, can 10gig be done? 100gig? Don't quite a few of the current scaling techniques (e.g. anycast) scale badly with online signing? Aren't the failure cases (e.g. hacked servers) rather worse? Doesn't this fundamentally alter the security model rather more than NSEC (necessity to put private keys on public servers). Whilst I don't object to online signing being a w/g issue, it certainly doesn't fulfil the "let's see if we can address the problem for everyone" criterion I mentioned above. So actually I agreed with most of what Ed wrote, certainly 1-4, 7-8. I'm not sure I understood 9, 10 right. 10 seems to be a desire to support forward upgradability that is absent throughout DNSSEC currently (and sounds to me impractical, if not impossible, to change). 9 on the otherhand sounds like mother's milk and apple pie. Do any ALT-NSEC proposals *not* do this? Even the NSEC-epsilon stuff (see successor/ predecessor draft) seemed to spend a lot of time assuming that not only single labels were supported. 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 Mon Mar 21 06:11:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21919 for ; Mon, 21 Mar 2005 06:11:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDKlp-0006KL-Kj for namedroppers-data@psg.com; Mon, 21 Mar 2005 11:08:29 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDKlm-0006Jl-Cv for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 11:08:27 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D102B23FDD; Mon, 21 Mar 2005 12:08:25 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id CCA9323FC0 for ; Mon, 21 Mar 2005 12:08:25 +0100 (CET) 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 j2LB8Pet005460 for ; Mon, 21 Mar 2005 12:08:25 +0100 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id j2LB8PcH006835 for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 12:08:25 +0100 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDKio-0005Rm-13 for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 11:05:23 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 7691023FE3; Mon, 21 Mar 2005 12:05:21 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id F021223F12 for ; Mon, 21 Mar 2005 12:05:18 +0100 (CET) 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 j2LB5Iet004760 for ; Mon, 21 Mar 2005 12:05:18 +0100 Date: Mon, 21 Mar 2005 12:05:18 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Draft DNSEXT @ IETF62 Minutes Message-Id: <20050321120518.7b0dd87a.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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_50 X-RIPE-Spam-Status: U 0.499987 / -3.3 X-RIPE-Signature: a46e771a73c0655fac2d8c9cb6502b1e X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ Moderators note: This post needed manual approval. Either it was posted by a non-subscribed address, or the posting was too large ( > 20000bytes ) for this list. With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please use your subscribed address to post, or shorten your postings by using links instead of attachments. ] Dear Colleagues, Below are the draft minutes of the DNSEXT Working Group meeting at IET62. Thanks to Kim Davies who did an excelent and timely job! If you have any issues with these draft minutes please let us know in the next couple of days. I will forward these minutes to go into the IETF62 proceedings somewhere next week. --Olaf Minutes of the DNSEXT working group 62nd IETF, Minneapolis, USA 9 March 2005 Chairs: =D3lafur Gu=F0mundsson Olaf Kolkman Scribes: Kim Davies (minutes) Mark Andrews (jabber) Previous Minutes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Previous minutes were posted, no comments were received. Agenda Bashing =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Agenda is the same as posted to the mailing list with some minor=20 reorganisation. Ed Lewis will discuss wildcards for alittle longer than=20 20 minutes, following from a "design team" meeting held on Monday which=20 examined the wildcard document and denial-of-existance work. Wildcard Document =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Lewis reported on the progress of the wildcard document, with version=20 -05 current in the draft respository: The title has changed, no longer a "clarifications" documents as the=20 document now changes things in the spec. Reorganised text based upon=20 feedback. The document also considers DNSSEC implementation on wildcards - this is=20 why the document is no longer only for clarifications as it considers=20 new tings. There will be further changes following the meeting earlier in the week,=20 so this document should not be considered ready for WGLC. The document clarifies the definition of wildcards as far as RFC 1034 is=20 concerned. It defines four concepts: "asterisk label"; "wildcard domain=20 name"; "closest encloser" - which defines where in the tree wildcards=20 come into play, impacting DNSSEC and negative proofs; and "source of=20 synthesis" - when a wildcard does wildcarding. In -06 there will be changes to the signing rules: * If a wildcard domain name owns EITHER an NS RRSet or a DNAME RRSet * It is NEVER a source of synthesis * Queries return NXDOMAIN * The RRSIG label count treats the records as non-wildcards One of the debates was whether to outlaw it. One comment was that=20 www.*.example couldn't be a reasonable domain name. However the name is=20 legal and don't want to throw it out because we found some weirdness.=20 Decided not to synthesise anything for that example, just return a name=20 error - NXDOMAIN. In the context of DNSSEC, if one looked for a.example,=20 could obtain the NS record through synthesis - but could not sign it=20 with DNSSEC. (Discussion) Rob Austein: In what way couldn't DNSSEC sign it? Ed Lewis: Lets say I am going through the algorithm for answering=20 =93a.example=94 and the qtype is =93NS=94. What is would do in that situati= on=20 is go through the zone and fine no a, then I=92d go to star and then I=92d= =20 match the * NS. According to wildcard normal rules, a.example NS will=20 expand into the answer section. I am required to have a signature there,=20 I cant put the signature in there. To make this legal I have to change=20 the protocols document so that signers would have to sign this=20 particular case.. if there was a signature there, the problem is the sig=20 would be signed by the wrong authority. Rob Austein: My problem is this seems to be a special case to deal with=20 garbage input. I'd rather not have special case rules to handle zones=20 like these. Lars Liman: What you=92re looking at is an NS record in the parent zone,=20 and you are worrying about the signature of that, but it is not going to=20 be signed in the parent zone. If you ask the parent server for a deleg=20 NS, are you supposed to get an answer, or a referral? Ed Lewis: If you look at the algorithm, there are three parts: (a) a=20 direct match, (b) a delegation point, and (c) a closest encloser. Then I=20 answer with a wildcard, no wildcard etc. When I come down I don=92t see=20 the cut point, it is not on my search point, so B doesn=92t work. This is written in the draft when we enter step (a), (b) or (c), we=20 don't jump across. Rob Austein: You are going to have to have a case in the ordinary=20 processing for the authorittive nameserver =93I know what is supposed to=20 be in the zone but it wasn=92t there=94. As far as I can tell this covers=20 this mess. It is general purpose error processing. I don=92t see why we=20 need a special case. Ed Lewis: I see what you mean =96 in Washington we talked of the same=20 thing. I made a mistake then thinking there would be a signature there.=20 With no sig there we would have to let the validator know it is a weird=20 case. We have to do some editing somewhere and the group on Monday felt=20 this is the best place to do the edits. Text will be coming to describe it. If the type is not NS, there is no problem. Only when it is an NS or a=20 DS do we get anything back and there is where there is a concern. This is how the rule would be changed in 1034. If some label has an=20 impossible match, look for existence of the star label, and does not own=20 an NS RRSet nor a DNAME RRSet. Treat a * NS or * DNAME as =93not there=94. Why NXDOMAIN? NXDOMAIN lets the caches stop asking, as it will get=20 negatively cached. DS is not considered by this discussion. Another example as * DNAME - was going to treat it as CNAME synthesis=20 but it has its own special properties. Only a few people genuinely=20 understand it, and hope Mark Andrews can provide text. David Conrad: Agree with Rob, it is garbage input, should be indicated=20 as so. It is easier to document it as something you shouldn't do than to=20 screw with the signer and force other issues. Olafur: Should take the three alternatives to the mailing list. Would=20 like those who advocate no change to advocate how to handle certain * types. Mark Andrews: One option is to make nameservers refuse to load the content. Steve Crocker: Is there any specification that defines what is a=20 well-formed zone? Ed Lewis: There doesn't seem to be a clear idea. Rob Austein: It has never been defined as it is an implementation=20 specific issue. Ed Lewis: On this issue, I tried to load such a zone in two different=20 name servers. One implementation had a bug, and the other refused to=20 load the zone. One problem with DNS is we have never been clear how to=20 treat errors that are not on the wire - there is no concise way of=20 saying what is a legal zone to load. Peter Koch: There is another precedent for refusing to load a zone. BIND=20 introduced a "check names" feature. You could have a situation where the=20 master loads a zone that contains underscores, but the slaves refuse to=20 accept it, resulting in inconsistency. Would rather have a defined=20 behaviour. Dont see * as a special case, but a canonical description on=20 how the * label becomes a source of synthesis is needed. Wes Hardaker: In my experience, if you let people use something without=20 it generating an error, it will be used. Even if 1 in 100000 DNS=20 operators use it, given the number of zones out there, it will be an=20 issue. Only elite operators will know its a bad case if it is not=20 documented. Either make it a protocol error, make the tool generate an=20 error, or it will occur in the wild. Bill Manning: Would like to see a decision by the group on whether it is legal or illegal with documents describing how to treat it, but=20 preference is that it stays legal. Steve Crocker: Looking at it from the other end of the wire - being=20 conservative in what you send: zone creators shouldbe able to see if=20 they are safely within reasonable margins. You can make those margins=20 tight, and if people want to cross them they cros a religious boundary=20 of not being strictly illegal. Mark Andrews: I hope everyone realises that if you add * NS, you lose=20 the ability to wildcard apart from * NS. We haven't defined how you can=20 have a wildcard for NS and other records at the same level - this is an=20 inconsistency. Conversation will continue on the mailing list. DNS SHA-1 =3D=3D=3D=3D=3D=3D=3D=3D=3D =D3lafur Gu=F0mundsson reported that two weeks ago an attack was announced= =20 on the SHA-1 algorithm. SHA-1 is designed to have a work factor of=20 2**80, and the attack claims to shrink it to 2**69 - which is still a=20 big effort to calculate. Currently it is unknown if the attack works on=20 structured or unstructured data - i.e. structured data like a DNS=20 record. However, attacks only get better with time. The good news is=20 HMAC is resistant to the attack. SHA-1 is used in two places - RRSIG and DS, with TSIG usage in last call. When signing data, the data is converted to a canonical form, and a=20 SHA-1 digest is calculated over it. There are a number of things in that=20 a hacker may not be able to control, and data has a limited lifespan, so=20 it is not clear if an attack can be based on this. The risk is=20 considered low. For TSIG the issue is similar. It has a HMAC on top of it, is valid for a short time (300 seconds), and there is a fair amount of random data=20 that goes into it. There is one use of TSIG that potentially could be=20 under complete control of an attacker and that is dynamic updates. The=20 risk is considered extremely low. DS represents where the real problem may exist - the long lived simple=20 SHA-1 digest. There are some mitigating factors, such as that it covers=20 the name. For it to be really useful the attack needs to generate keys.=20 The reason to attack DS is to create a denial-of-service attack. The=20 risk is low to medium, but the risk will likely increase over time. The proposal to treat this is to ignore RRSIG and TSIG; go ahead with=20 the TSIG extension to support other SHAs - getting SHA-256 into=20 codebases is useful. For RRSIG the working group can wait for advice on=20 what digest algorithm will replace SHA-1. For DS a new algorithm is probably needed faster than anywhere else, but=20 there is no security advise on what to choose. When developing DNSSEC=20 there was a view the DS record would change infrequently - but this=20 issue may be the first thing that needs to be rolled in DNSSEC so=20 consideration of the transition issues is required. Sam Weiler posted a draft to the list earlier in the week and would like people to read it and comment. DNSSEC Key Rollover IPR =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The chairs were notified on February 6 that Diversinet Corp. that they=20 hold intellectual property rights relevant to key rollover. The claimant=20 has been responsive to queries and the discussion has been cordial. The=20 patent has been awarded in one country, and a patent application has=20 been filed in another. RFC3979 describes the IPR process. The working group needs to discuss whether to continue with these proposals given the existence of an IPR claim or work around it. It becomes an issue for implementors and users whether they want to risk lawsuits if they decide to ignore the IPR claim. Terms of license: Diversinet's position at this time is that it is worthwhile, from a public relations perspective, for it to license its technology on terms that are reciprocal, reasonable and royalty free, if such technology is incorporated into a specification. Our general license would contain terms that are typical in a commercial intellectual property license, and would include a requirement that any organization using the technology covered by our patent would have to disclose prescribed language indicating that the licensee's service or product incorporates intellectual property owned by Diversinet, and that such organization would agree to be referenceable by Diversinet in any publicity regarding Diversinet's patent portfolio. Mike St Johns, one of the authors of the affected documents, noted that=20 the terms differed from other IP licences, in that it has the last=20 sentence. He believed it would be unacceptable to many implementers. Bill Manning, another affected author, believed the chairs should=20 continue the dialogue with the IP holders until there was complete=20 disclosure. David Conrad noted that the last sentence refered to those "using"=20 rather than "implementing" the technology, and end-users would have=20 issue being referenced by this requirement. The chair said that if the working group didn't believe that running=20 code could be created with this IP restriction, then we are missing one=20 half of "rough consensus and running code". If the licensing prohibits=20 getting code then there is an issue for the working group. Mike St Johns suggested they be asked to accept the same terms as others=20 without the advertising clause. Others get patents just for self=20 defense, and allow others to use their patents without using them=20 against anyone. Sam Weiler suggested the group participants engage in a search for prior=20 art for the claims in the IPR disclosure. DNSSEC Denial of Existance =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Olaf reported a number of drafts are in circulation. draft-ietf-dnsext-signed-noneixstance-requirements-01 was reported to=20 the previous meeting in a presentation. The comments made in that=20 presentation did not get integrated in the new version due to some time=20 constraints. The document will be revised after the meeting and updated=20 with inputs from the Washington meeting. Essentially two methods have been devised, one with an online key, and=20 another is sought that does not require an online key. For online signing, the epsilon signing approach=20 (draft-weiler-dnsext-dnssec-online-signing-01) is being fast-tracked.=20 For offline signing, work on NSEC3 is ongoing. Sam Weiler asked for the requirements documents to be resorted to show=20 which requirements coexist. Ben Laurie responded that this was already=20 done in slides and would be introduced into the document in the next draft. Geoff Sisson reported he has done a draft that detailed the specifics of=20 finding the nearest successor and predecessor of a given name. It was=20 realised this "absolute" method was not trivial to accomplish, so it was=20 published as an informational overview. Work on a more simplified=20 version which assumes a single zone, with single owner names and no=20 empty non terminals was devised. This approach reduces alot of size and=20 computational complexity. The document will soon be in the I-D=20 repository, and a proof of concept has been created operating with the=20 technique. Sam Weiler explained the epsilon draft's approach. The concept is to=20 make NSEC records cover less of the zone, resulting in attacks that are=20 almost as difficult as dictionary attacks. The benefit is there are no=20 resolver changes and almost no protocol changes. Some wordings need to=20 be relaxed but they are on things not known to be checked by resolvers. In principle, you generate an NSEC which is the owner name plus a small=20 increment. This is interesting when you want a negative answer proof.=20 You generate this on the fly using the query name minus a small=20 increment, for example: ).com NSEC +.com covers *.com You don't need to have a perfect epsilon function, just one that does=20 not cover existing records. Any function will work, including those=20 considered by Geoff's draft. Sam would like the working group to adopt this as a working group item. Olaf noted that there were no objections to this at the last meeting,=20 and believed the document was ready for working group last call. Peter Koch said he didn't see why the perfect epsilon function detailed=20 by Geoff and Ben was not covered in Sam's document. If it is going to be=20 a standards track document, what are the implications if Geoff's draft=20 only became informational? Olaf responded that Sam's document just=20 documented a concept, whereas Geoff's draft was one of potentially=20 numerous implementations of that concept. Roy Arends explained work on draft-ietf-dnsext-nsec3-01. At the previous meeting there were two drafts - NSEC2 and DNSNR. The two=20 drafts have now been combined into a single draft that do roughly the=20 same thing. In NSEC2 there was an EXIST record, needed to make empty non=20 terminals visible. In the new draft this was replaced with additional=20 NSEC3 RRSets. The draft also switched from hashed labels to hashed owner=20 names, and the salt can be variable in length. There had been a large discussion on changing the salt. If you change=20 the salt, you need to change every NSEC3 record in the zone. However, to=20 a validator, if it is doing a single query it doesn't see all the other=20 salts. There was also a large discussion on namedroppers that you can't roll=20 the hash value without a protocol roll. However, you cant in the future=20 roll a hash value to an undefined one - as implementors may not have=20 implemented the new hash function. So the question is, do we mandate a=20 single hash algorithm (SHA-xyz?) and drop the algorithm field? An outstanding issue is what to do if there are hash collisions. If this=20 occurs between existing names in the zone, you can increment the salt or=20 iterations before publishing the zone and resign. The other type of=20 collision may occur between a qname and a hash of an owner name. If that=20 happens, you can no longer prove non existence of the qname. Steve Crocker asked what the probabilities of hash collisions were. Roy=20 responded he saw then as astronomically infeasible, and if they occured=20 it was far morelikely to be a broken hashing algorithmm. Steve noted in that case he felt that discussions about deficient hash=20 algorithms were out of scope, and that the group just had to trust that=20 they would do their job. Roy agreed, but said he was responding to=20 requests to address this issue. Mark Andrews added collisions will occur because the qname space is=20 bigger than the hash space. Steve Crocker responded that the whole point=20 of hashes was that probability was so small that in practicality you=20 don't worry about it. If it is an issue, you use chaining algorithms, etc. Roy posed another question on hashing - whether or not hash truncation=20 would be allowed. If it is not allowed, then the protocol can't be=20 designed for the most extreme name. If a name is, for example, 250=20 characters long, there is no space to add a hash. It may be an idea to=20 have truncation, but if so, the likelihood of collisions increases. Another issue is that with NSEC you need 2 records for authenticated=20 denial, NSEC3 you need 3: two to prove the closest encloser and a third=20 to prove absence of wildcards. Ed Lewis suggested reword to "showing the encloser you are giving is the=20 closest" to prevent the term being misused. Mark Andrews noted for the discussion on hash collisions, another=20 solution opposed to changing salt and recomputing, is the server holding=20 different NSEC3 records with different bitmaps and returning the correct=20 one based on the query. Mark Andrews then gave an overview of a solution he had thought of to=20 the issue, dubbed NSEC4. This solution tries to solve the issue of appending hashes, and the=20 consequential inability to sign all possible zones, by moving the zone=20 into the RDATA format. This adds one extra byte to what an NSEC3 would=20 otherwise have. The side-effect is NSEC4 would no longer be directly=20 retrievable with a query, instead, you would only get them as the side=20 effect of another query or AXFR. Their existence could be detected using=20 the precondition tests in UPDATE. This effectively results in precomputed metadata on the zone that is=20 kept in a different namespace for all zones except ".". Extra words=20 could be added to explain this, so "." is treated the same way, hanging=20 off the side in a separate database. The RDATA format is NSEC4 A comment was received that the proposal had "serious layer 9 issues",=20 and the chairs suggested the proposal be written up as a draft. Jaap Akkerhuis reported on a draft on "Basic Error Response Type (BERT)"=20 developed by Miek Gieben. The draft is a protocol change designed to make signing easier by=20 introducing simplified negative wildcard responses. It allows for a=20 fairly simple signing model, and satisfies the universal signing=20 requirement. The downside is the use of online keys, which means=20 additonal operational requirements for key management. It also=20 represents a protocol change not backward compatible with DNSSECbis. The=20 concept is very sketchy and would like to see whether the working group=20 is interested in the author taking this any further. Mark Andrews noted he believed it should be written up so the group can consider all the choices available. Ed Lewis noted there were many different proposals floating around but=20 few concrete implementations. He believed it would be more useful to be=20 workshopping prototypes to get real experience on concrete usage before=20 having discussions on their merits. DNSSEC Experiments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Blacka explained draft-ietf-dnsext-dnssec-experiments-00 was a=20 simple technique that the working group had discussed regarding=20 transition mechanisms needed for NSEC3. It tries to discuss how to=20 conduct experiments without protocol changes, i.e. conducting=20 experiments in public that are not backward compatible with DNSSEC. The draft uses the "unknown algorithm" technique to avoid IANA getting=20 involved in every experiment, recommending a private algorithm naming=20 scheme. The document discusses how you might transition from the experiment to a=20 standard, but like other transitons it is not very pretty. Sam Weiler noted the DNSSEC implementation notes discussed how private=20 algorithms might be used, and if anything is unclear in that document=20 then he wants to be informed. Olaf enquired whether the draft was targeting an experimental,=20 informational or standard designaton. David said he thought it needed to=20 be standard so it gets used, but that the experiments themselves would=20 be experimental. Opt-in Status Update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Olaf noted it has been with the chairs for some time to publish Opt-in=20 as an informational document with a boiler-plate. It has had some minor=20 revisions and would like the group to review the document - not the=20 technique itself, but the minor edits it has had. It has a normative=20 reference so it will remain the queue for the time being. LLMNR Changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bernard Aboba reported on draft-ietf-dnsext-mdns-38. It was reviewed by=20 AD Thomas Narten, and they are in the process of resolving the comments=20 received back. Those issues are being tracked at=20 www.drizzle.com/~aboba/DNSEXT/llmnrissues.html 25% of the issues are still outstanding, relating to conflict resolution. Issue 78 related to uniqueness probing, originally considered to be a=20 corner case when multiple nodes seek the uniqueness of a name. However=20 it was conceived a vendor could ship products with default names, so you could have a room full of devices called "PRINTER" etc. Therefore a=20 mechanism is needed to resolve these conflicts quickly. Proposed=20 solution is a "tentative" bit, which returns a response which is not=20 verified for uniqueness. Issue 80 on multiple-protocol conflicts forsees weird conflicts when a=20 responder responds to a query for an A record, even though it only=20 supports LLMNR over IPv6. This conflict is unresolvable as the don't=20 speak the same protocol. Responders need to only respond with addresses=20 reachable using the protocol LLMNR runs over. Issue 81 on the healing of a network partition. This refers to a corner=20 case that didn't try to solve previously. This occurs when uniqueness=20 has been verified in a partition of a network, but then conflicts occur,=20 how are they resolved? A conflict bit was added if the responses are not believed to be unique. A sender receiving multiple responses, and the=20 conflict bit is clear in one or more, it knows there is a conflict.=20 Conflict resolution is decided by "lowest address wins". Issue 82 on response merging, given that it makes sense to merge=20 responses where the RRs are not expected to be unique, how do you merge=20 responses for hosts that are in conflict? For example, merging SRV RRs=20 from conflicting responders will result in inconsistent weighting, which=20 can stay in the cache until the TTL runs out. The conflict could exist=20 for a small period, but a polluted cache could persist longer. The=20 proposed solution is if multiple responses are received, only those with=20 the conflict-bit set are merged. Bernard reported that once it was believed the document was settled it=20 would be run by the group again for WGLC. TSIG SHA etc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Donald Eastlake reported that the current standard only defined how to=20 do things with HMAC, and whilst people were worried about MD5, MD5=20 vulnerabilities should not affect HMAC. Others want to use government=20 approved algorithms, other algorithms, and truncate hashes. The -00 draft specified the names, syntax, and how to specify=20 truncation. The -01 draft made SHA-1 and SHA-256 mandatory in additon to=20 HMAC-MD5. The -02 draft is based on comments from Mark Andrews,=20 specifying an error code for "signature too weak" to be the same as a=20 missing signature. It specifies that a truncated signature value in a=20 request should be used for calculating the signature for a reply; and=20 that policies should accept longer signatures than they require and=20 should reply with a signature at least as long as the corresponding=20 query. A little more information was added about recent hash breaks, and=20 policies are constrained a little so that if you accept some truncation,=20 you should also accept longer hashes. Based on comments from Steve=20 Bellovin, the draft repeats some advice in the HMAC-MD5 RFC. The ECC Key Draft, after some discussion at the last meeting, has had=20 ECC signatures re-inserted into it, as well as some background. A=20 general format format is given for expressing a vast variety of ECC keys=20 and signatures, but the only real feedback is whether the format was too=20 general. Donald would appreciate feedback on this draft. There are also two drafts on DSA and Diffie-Hellman keys and signatures,=20 expected to be WGLC'd. 2538bis CERT RR =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =D3lafur reported this document is in last call, and has received no=20 comments so far. Would like some affirmation that the document is=20 acceptable. Needs to consider whether an interop report is needed to=20 advance it to draft standard. A meeting will be held in the afternoon to=20 discuss interop requirements to advance the 20+ RFCs that are at=20 proposed standard status today. Those who wish to actively participate=20 in advancing the drafts are welcome. Cross fertilisation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sam Weiler reported that the IPSEC work that began in Atlanta has been=20 completed. No other input was received. Close of Meeting. --=20 ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org -- 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 Mar 21 06:24:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22712 for ; Mon, 21 Mar 2005 06:24:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDKzV-0009FK-BZ for namedroppers-data@psg.com; Mon, 21 Mar 2005 11:22:37 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDKzU-0009Er-8J for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 11:22:36 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j2LBMRKN027455; Mon, 21 Mar 2005 11:22:27 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j2LBMRlZ027452; Mon, 21 Mar 2005 11:22:27 GMT Date: Mon, 21 Mar 2005 11:22:27 +0000 From: bmanning@vacation.karoshi.com To: Ben Laurie Cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Rants on auth denial Message-ID: <20050321112227.GB27358@vacation.karoshi.com.> References: <423AB838.2000504@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423AB838.2000504@algroup.co.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >There is one item I'd challenge anyone thinking about all this ... say > >something about troubleshooting. How can an operator verify that the > >responses being given are correct and not the result of a bad floating > >point accelerator or buggy cryptolibrary? > > If an operator wants to check the responses, all they need do is perform > the hashes with an independent implementation and verify that it matches > the hashes in the zones. ah... the rose coloured lenses... independent implementations are -VERY- hard to come by. esp. that have independent crypto libraries. I've been told that building a "correct" crypto implementation is hard - and it is generally recommended to use an existing, tested implementation. > Ben. --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 Mon Mar 21 07:03:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25490 for ; Mon, 21 Mar 2005 07:03:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDLay-000H53-TS for namedroppers-data@psg.com; Mon, 21 Mar 2005 12:01:20 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDLav-000H4B-Kj for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 12:01:17 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 0674F33C5F; Mon, 21 Mar 2005 12:01:16 +0000 (GMT) Message-ID: <423EB790.1010205@algroup.co.uk> Date: Mon, 21 Mar 2005 12:01:20 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com Cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Rants on auth denial References: <423AB838.2000504@algroup.co.uk> <20050321112227.GB27358@vacation.karoshi.com.> In-Reply-To: <20050321112227.GB27358@vacation.karoshi.com.> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit bmanning@vacation.karoshi.com wrote: >>>There is one item I'd challenge anyone thinking about all this ... say >>>something about troubleshooting. How can an operator verify that the >>>responses being given are correct and not the result of a bad floating >>>point accelerator or buggy cryptolibrary? >> >>If an operator wants to check the responses, all they need do is perform >>the hashes with an independent implementation and verify that it matches >>the hashes in the zones. > > > ah... the rose coloured lenses... > independent implementations are -VERY- hard to come by. > esp. that have independent crypto libraries. I've > been told that building a "correct" crypto implementation > is hard - and it is generally recommended to use an > existing, tested implementation. Speaking as one of the implementers of one of the more widely used implementations, I couldn't agree more. By "independent" I meant "different existing tested implementation" :-) As I noted elsewhere, I don't really believe faulty libaries is a problem in practice. -- 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 Mar 21 07:12:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26645 for ; Mon, 21 Mar 2005 07:12:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDLiz-000IpJ-TO for namedroppers-data@psg.com; Mon, 21 Mar 2005 12:09:37 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDLis-000Ike-NV for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 12:09:30 +0000 Received: from stjohns-lap2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id BA8B3568ED for ; Mon, 21 Mar 2005 04:09:28 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.2.0.14.2.20050321064232.04988eb0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 21 Mar 2005 07:09:31 -0500 To: namedroppers@ops.ietf.org From: Mike StJohns Subject: Comment on IPR Statements from Diversinet Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_23546788==.ALT" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=====================_23546788==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Olafur asked me to post a brief summary of my comments related to the IPR filings by Diversinet - #s 548 and 549 that I made at the DNSEXT WG session at the last IETF. Without any comment on the merits of the IPR claims, I noted that I believed the language of the IPR disclosure with respect to terms would be unlikely to be widely acceptable. Specifically, the IPR disclosure terms include the following language: would include a requirement that any organization using the technology covered by our patent would have to disclose prescribed language indicating that the licensee's service or product incorporates intellectual property owned by Diversinet, and that such organization would agree to be referenceable by Diversinet in any publicity regarding Diversinet's patent portfolio." The "any organization using" is overly broad and could be read to include anyone running a DNS product which includes the technology. This is just worded badly. The "referencable by Diversinet..." also seems over-reaching, and unlikely to be agreed to by many if any organization wanting to incorporate this. I did a *brief* review of other IPR disclosures and this requirement appears unique among the disclosures I reviewed. My personal preference would be something on the order of the Nokia terms in their disclosure #545: >Regarding this internet draft "IMAP Extension for CHECKPOINT Synchronization", >draft-wener-lemonade-checkpoint-01.txt, to the extent this draft is included >into final IETF standard specification, Nokia agrees not to assert those >claims >in Nokia patents that apply to this submission and are technically >necessary to >implement the IETF standard spesification against any other party in >respect of >its implementation of the specification, provided that the party relying >on thiscommitment does not assert its patents against Nokia. In interests of full disclosure (pun intended) - I'm an author of one of the drafts on which Diversinet filed the IPR notice. Mike --=====================_23546788==.ALT Content-Type: text/html; charset="us-ascii" Olafur asked me to post a brief summary of my comments related to the IPR filings by Diversinet - #s 548 and 549 that I made at the DNSEXT WG session at the last IETF.

Without any comment on the merits of the IPR claims, I noted that I believed the language of the IPR disclosure with respect to terms would be unlikely to be widely acceptable.  Specifically, the IPR disclosure terms include the following language:

would include a requirement that


any organization using  the technology covered by our patent
would have to


disclose prescribed language indicating that the licensee's service
or product


incorporates intellectual property owned by Diversinet, and that
such


organization would agree to be referenceable  by Diversinet in any
publicity


regarding Diversinet's patent portfolio."
The "any organization using" is overly broad and could be read to include anyone running a DNS product which includes the technology.  This is just worded badly.

The "referencable by Diversinet..." also seems over-reaching, and unlikely to be agreed to by many if any organization wanting to incorporate this.  I did a *brief* review of other IPR disclosures and this requirement appears unique among the disclosures I reviewed.

My personal preference would be something on the order of the Nokia terms in their disclosure #545:


Regarding this
internet draft "IMAP Extension for CHECKPOINT
Synchronization",
draft-wener-lemonade-checkpoint-01.txt, to the extent this draft is
included
into final IETF standard specification, Nokia agrees not to assert those
claims
in Nokia patents that apply to this submission and are technically
necessary to
implement the IETF standard spesification against any other party in
respect of
its implementation of the specification, provided that the party relying
on thiscommitment does not assert its patents against
Nokia.


In interests of full disclosure (pun intended) - I'm an author of one of the drafts on which Diversinet filed the IPR notice.

Mike
--=====================_23546788==.ALT-- -- 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 Mar 21 07:31:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28127 for ; Mon, 21 Mar 2005 07:31:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDM2M-000Mdj-PE for namedroppers-data@psg.com; Mon, 21 Mar 2005 12:29:38 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDM2L-000MdB-BP for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 12:29:37 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) id <0IDP00I01BX50100@cali.ucd.ie> (original mail from niall.oreilly@ucd.ie) for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 12:29:33 +0000 (GMT) Received: from [137.43.2.214] by cali.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) with ESMTPSA id <0IDP00EGWC193ZB0@cali.ucd.ie>; Mon, 21 Mar 2005 12:29:33 +0000 (GMT) Date: Mon, 21 Mar 2005 12:29:41 +0000 From: "Niall O'Reilly" Subject: Re: Rants on auth denial In-reply-to: To: Alex Bligh Cc: "Niall O'Reilly" , Edward Lewis , namedroppers@ops.ietf.org Message-id: <7976e8bf97cb42fc02abad8983a950c3@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20050318112738.037BAE7EA2@mx1.nominet.org.uk> <423AB838.2000504@algroup.co.uk> <87psxwdcoz.fsf@deneb.enyo.de> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On 21 Mar 2005, at 09:08, Alex Bligh wrote: > 10 seems to be a desire to > support forward upgradability that is absent throughout DNSSEC > currently > (and sounds to me impractical, if not impossible, to change). My comment below may well be totally daft, as I haven't done the reading. If so, apologies all round. OTOH, it may be "something we should have thought of" or even "an option which is already available, and thus a strictly operational matter". Is there any reason a zone owner wanting to introduce a "super-safe" algorithm can't add a second set of signatures (per RR-set, I assume) to the zone, so maintaining availability of the "commonly-considered- good-enough" algorithm while "super-safe" acquires critical mass? EUR 0.02 /Niall -- 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 Mar 21 08:08:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01794 for ; Mon, 21 Mar 2005 08:08:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDMby-0005jg-V5 for namedroppers-data@psg.com; Mon, 21 Mar 2005 13:06:26 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDMbu-0005iV-6D for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 13:06:22 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j2LD6GKN027811; Mon, 21 Mar 2005 13:06:16 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j2LD6GNP027808; Mon, 21 Mar 2005 13:06:16 GMT Date: Mon, 21 Mar 2005 13:06:16 +0000 From: bmanning@vacation.karoshi.com To: Ben Laurie Cc: bmanning@vacation.karoshi.com, Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Rants on auth denial Message-ID: <20050321130616.GD27358@vacation.karoshi.com.> References: <423AB838.2000504@algroup.co.uk> <20050321112227.GB27358@vacation.karoshi.com.> <423EB790.1010205@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423EB790.1010205@algroup.co.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Mar 21, 2005 at 12:01:20PM +0000, Ben Laurie wrote: > bmanning@vacation.karoshi.com wrote: > >>>There is one item I'd challenge anyone thinking about all this ... say > >>>something about troubleshooting. How can an operator verify that the > >>>responses being given are correct and not the result of a bad floating > >>>point accelerator or buggy cryptolibrary? > >> > >>If an operator wants to check the responses, all they need do is perform > >>the hashes with an independent implementation and verify that it matches > >>the hashes in the zones. > > > > > > ah... the rose coloured lenses... > > independent implementations are -VERY- hard to come by. > > esp. that have independent crypto libraries. I've > > been told that building a "correct" crypto implementation > > is hard - and it is generally recommended to use an > > existing, tested implementation. > > Speaking as one of the implementers of one of the more widely used > implementations, I couldn't agree more. > > By "independent" I meant "different existing tested implementation" :-) > > As I noted elsewhere, I don't really believe faulty libaries is a > problem in practice. er... recent posting from SMB in other fora indicates that design assumptions w/ one such library are posing interesting and unanswered questions about augmenting said libraries w/ something other than SHA-1... which begs the question of what is a "faulty" library. as usual, YMMV. In any case, we have wandered afield from the DNS issues. back to your regularly scheduled namedroppers threads. -- 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 Mon Mar 21 08:15:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02289 for ; Mon, 21 Mar 2005 08:15:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDMhj-000742-Nk for namedroppers-data@psg.com; Mon, 21 Mar 2005 13:12:23 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDMhU-0006zl-5N for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 13:12:08 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 77BE333C33; Mon, 21 Mar 2005 13:12:06 +0000 (GMT) Message-ID: <423EC82A.1050409@algroup.co.uk> Date: Mon, 21 Mar 2005 13:12:10 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Rants on auth denial References: <20050318112738.037BAE7EA2@mx1.nominet.org.uk> <423AB838.2000504@algroup.co.uk> <87psxwdcoz.fsf@deneb.enyo.de> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > Trying to tie all the responses back to one thread... > > At 11:15 +0000 3/18/05, Ben Laurie wrote: > >> Edward Lewis wrote: >> >>> 9) We have to remember that any client-server protocol has to keep >>> in mind >>> that there are two sets of semantics. The server-side ... >> >> ...snip... >> >>> ... H(name) has to somehow avoid flatting a zone's (sub)tree - and we >>> can't >>> assume that only one-label zones will use an alt-NSEC. >> >> >> You make this statement as if it is somehow obvious that per-label hashes >> are good, and whole-name hashes are bad. You use the term "flattening the >> zone" as if NSEC3 records had anything to do with the shape of the zone. >> The zone is the shape it is, regardless of how you deny existence of >> non-existent names. Enlighten me - what are you on about? > > > The problem with demonstrating the closest encloser that is handled by > having to either include extra neg-answer records (to show that the > encloser identified is indeed closest) or to stuff in records at > otherwise empty non-terminals. No records appear at empty non-terminals in NSEC3. Even if they did, we have already agreed that NSEC3 is effectively in a different namespace. >>> My conclusion is that someone (not me, I'm busy now with EPP and >>> DNSSEC, etc.) needs to work out a way to make per-label hashing ... >> >> ...snip... >> >>> ... also more promising than hashing a whole name. After all, it's >>> not the >>> tree structure we want to hide, but the label identities. >> >> >> I do not understand why this is better. > > Not having to mess with empty non-terminals, You always have to mess with empty non-terminals in some sense. > better handling of multi-label-depth zones. Worse if you consider packet size to be a factor. >>> Can this be done without a protocol change? Probably not. I'm not >>> calling for a halt to the DNSSECbis documents, etc., but I still haven't >>> seen the light on how we can overcome what's in #10. Even with a >>> transition mechanism in place. >> >> ...snip... >> >>> ... verify that the responses being given are correct and not the result >>> of a bad floating point accelerator or buggy cryptolibrary? >> >> >> If an operator wants to check the responses, all they need do is perform >> the hashes with an independent implementation and verify that it matches >> the hashes in the zones. >> >> I'd note that bad crypto implementations tend to not go undetected for >> long, since they produce nonsense or verification failures. > > If operations were so simple. ;) I just see the existing documents as > overly concerned with the "science" and not operationally vetted. That is certainly part of the point of getting operational experience, isn't it? In any case, my long experience of crypto operations tells me that faulty libraries or hardware are almost _never_ the problem when crypto goes wrong. Mismatching public and private keys is a popular cockup, as is failure to correctly implement the application. > At 11:27 +0000 3/18/05, Geoffrey Sisson wrote: > >> Edward Lewis writes: >> 3. Online signing is viewed (by us at least) as an interim solution to >> expidite the deployment of DNSSEC rather than waiting for `DNSSECter'. >> The performance issue has been noted but it's been suggested that >> suitably accelerated hardware should be able to do this at wire >> speed at gigabit rates (though AFAICT the impact of a move to longer >> keys hasn't been discussed). > > > That may be. If so, they why is this a working group issue? An > implementation is free to generate negative answers in any matter it > chooses. Because we see it as an interim solution, useful for testing and gaining deployment experience only, not one that we could actually deploy. Because of that, we don't currently intend to use it even in test, since that will be a pointless distraction from NSEC3, which solves the problem without all the issues that epsilon introduces. 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 Mar 21 09:04:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06341 for ; Mon, 21 Mar 2005 09:04:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDNTx-000JON-5T for namedroppers-data@psg.com; Mon, 21 Mar 2005 14:02:13 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDNTv-000JMR-Mu for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 14:02:12 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2LE22nd059347; Mon, 21 Mar 2005 09:02:03 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <7976e8bf97cb42fc02abad8983a950c3@ucd.ie> References: <20050318112738.037BAE7EA2@mx1.nominet.org.uk> <423AB838.2000504@algroup.co.uk> <87psxwdcoz.fsf@deneb.enyo.de> <7976e8bf97cb42fc02abad8983a950c3@ucd.ie> Date: Mon, 21 Mar 2005 08:53:28 -0500 To: "Niall O'Reilly" From: Edward Lewis Subject: super safe, was Re: Rants on auth denial Cc: Alex Bligh , "Niall O'Reilly" , Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:29 +0000 3/21/05, Niall O'Reilly wrote: >Is there any reason a zone owner wanting to introduce a "super-safe" >algorithm can't add a second set of signatures (per RR-set, I assume) >to the zone, so maintaining availability of the "commonly-considered- >good-enough" algorithm while "super-safe" acquires critical mass? I changed the subject because this is a tangent to authenticated denial. There are two parts in answering this. It is possible for a zone owner to supplement basic security by adding something stronger. But supplementing means maintaining the older, "less safe" functionality. For signing, I can sign with DSA and with some super-safe, super-secret private algorithm. Most folks will use the former. The problem is that I can't guarantee that the folks who should use the latter will do so - the server can't tell the client to "try this signature first." For auth denial, if I want to employ NSEC42 because it hides names correctly and I have to simultaneously do NSEC, the gain is lost. Without a means for the server to tell the client what to use first, operational maintenance of updating all the concerned clients will undermine the organization that wants the protection. Few enough people today understand the DNS protocol, fewer will be able to manage the detail of properly updating something as "insignificant" as resolvers. The other point is that DNSSEC is not about the zone administrator, it's about the resolver. It's the local policy at the resolver that matters most. I think that this gets lost on us from time to time. The resolver first has to understand new features, whether a new cryptographic library or a new algorithm for authenticated denial. Second, the resolver has to choose which of the approaches it knows that is to be followed first, then second, etc., until it drops into approaches not trusted to do the job (anymore). What DNSSEC lacks in this regard is any means for the server to tell the client how to proceed - meaning it's really up to the resolvers to do the job "right." So - when I see a phrase (and this isn't meant to poke at the poster, this happens commonly) like "a zone owner wanting to introduce," alarm bells go off in my head. (Okay, with age I have the ringing in the ears, so this isn't a surprise.) The alarms tell me that there's a desire to solve an impossible (IMHO) problem. A well meaning desire, but one that will be fruitless (based on my experiences of trying something similar). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 21 09:17:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07608 for ; Mon, 21 Mar 2005 09:17:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDNfc-000MQm-U7 for namedroppers-data@psg.com; Mon, 21 Mar 2005 14:14:16 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDNfT-000MP9-GZ for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 14:14:07 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2LEDxxQ059398; Mon, 21 Mar 2005 09:14:00 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20050318112738.037BAE7EA2@mx1.nominet.org.uk> <423AB838.2000504@algroup.co.uk> <87psxwdcoz.fsf@deneb.enyo.de> Date: Mon, 21 Mar 2005 09:14:06 -0500 To: Alex Bligh From: Edward Lewis Subject: Re: Rants on auth denial Cc: Edward Lewis , namedroppers@ops.ietf.org, Alex Bligh Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:08 +0000 3/21/05, Alex Bligh wrote: >So actually I agreed with most of what Ed wrote, certainly 1-4, 7-8. >I'm not sure I understood 9, 10 right. 10 seems to be a desire to >support forward upgradability that is absent throughout DNSSEC currently >(and sounds to me impractical, if not impossible, to change). 9 on the >otherhand sounds like mother's milk and apple pie. Do any ALT-NSEC >proposals *not* do this? Even the NSEC-epsilon stuff (see successor/ >predecessor draft) seemed to spend a lot of time assuming that not >only single labels were supported. 9 refers to the comments that "white lies", the tag applied to answering with "false" names and signing responses on-line, breaks the security model of the DNS. There was concern over the requirement (in dnssec-bis) that no name own just a auth-denail record. The reason for the requirement in question dates back to the efforts to build the first signers and servers. The requirement does not come from anything related to the resolver/verifier. My faulty, beer-soaked memory recalls that I first thought of this requirement and sold it to others and it made it's way into text. My recollection is that I was thinking only of server-side issues at the time. My fear is that over time, repeated chanting of it has given this requirement more importance that it deserves and it has been taken to apply to the client too. So Rant #9 refers to "white lies" isn't a problem. It's not an aberration of the security model. It's okay to cache the records just like any pre-calculated NSEC record. That's where #9 going. 10 is just an overall "lack of feature" in DNSSEC. Not a defect, just that DNSSEC doesn't have a mechanism for improvement on the base. Barring negotiation of security parameters (and believe me, we DNSSEC-gray-beards did consider this) there isn't a good way to accomplish this. Negotiated parameters were tossed as something that would kill the lightness of DNS. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 21 09:22:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07987 for ; Mon, 21 Mar 2005 09:22:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDNlg-000Nk9-Rx for namedroppers-data@psg.com; Mon, 21 Mar 2005 14:20:32 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDNlU-000Nhy-9E for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 14:20:20 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 12A60C2DA4; Mon, 21 Mar 2005 14:20:19 +0000 (GMT) Date: Mon, 21 Mar 2005 14:20:11 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Rants on auth denial Message-ID: In-Reply-To: References: <20050318112738.037BAE7EA2@mx1.nominet.org.uk> <423AB838.2000504@algroup.co.uk> <87psxwdcoz.fsf@deneb.enyo.de> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 21 March 2005 09:14 -0500 Edward Lewis wrote: > 9 refers to the comments that "white lies" Gotcha. Thanks. 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 Mon Mar 21 09:28:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08462 for ; Mon, 21 Mar 2005 09:28:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDNrz-000PJB-Qe for namedroppers-data@psg.com; Mon, 21 Mar 2005 14:27:03 +0000 Received: from [193.0.2.21] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDNrq-000PHg-KD for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 14:26:54 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 1E87517A319; Mon, 21 Mar 2005 15:26:52 +0100 (CET) Message-ID: <423ED9AB.5020005@ripe.net> Date: Mon, 21 Mar 2005 15:26:51 +0100 From: "Olaf M. Kolkman" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie Cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Rants on auth denial References: <20050318112738.037BAE7EA2@mx1.nominet.org.uk> <423AB838.2000504@algroup.co.uk> <87psxwdcoz.fsf@deneb.enyo.de> <423EC82A.1050409@algroup.co.uk> In-Reply-To: <423EC82A.1050409@algroup.co.uk> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> >> That may be. If so, they why is this a working group issue? An >> implementation is free to generate negative answers in any matter it >> chooses. > > > Because we see it as an interim solution, useful for testing and > gaining deployment experience only, not one that we could actually > deploy. Because of that, we don't currently intend to use it even in > test, since that will be a pointless distraction from NSEC3, which > solves the problem without all the issues that epsilon introduces. > This statement worries me. I was under the impression that "you and yours" were to deploy epsilon based techniques. Was I wrong, or did your ideas about deployment change? I am also confused by the first and last sentence in the quoted paragraph. If you will not deploy it, not even in testing how would you gain deployment experience. Paraphrasing Ed, in order to publish we'll need running code and deployment tests. I fully agree with that. Therefore I wonder if there is sufficient momentum to go forward with the epsilon based methodology if nobody will deploy anyway? In other words. Anybody on this list: would you deploy an epsilon based solution, with on-line keys, and no protocol change needed on the Internet or do y'all see this as an academic exercise? I think it would be good to sort out what people are willing to deploy. If there is nobody even considering do deploy dynamic signing methods than I think we should just stop considering them as a viable alternative and waisting valueable working group resources. --Olaf (hat in hand) -- 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 Mar 21 10:41:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17698 for ; Mon, 21 Mar 2005 10:41:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDOxB-000Ghj-Pf for namedroppers-data@psg.com; Mon, 21 Mar 2005 15:36:29 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDOx7-000GgC-Up for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 15:36:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 62DBB13971; Mon, 21 Mar 2005 15:36:25 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Mike StJohns Cc: namedroppers@ops.ietf.org Subject: Re: Comment on IPR Statements from Diversinet In-Reply-To: Message from Mike StJohns of "Mon, 21 Mar 2005 07:09:31 EST." <6.2.0.14.2.20050321064232.04988eb0@localhost> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 21 Mar 2005 15:36:25 +0000 Message-Id: <20050321153625.62DBB13971@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk diversinet's requirements are untenable for an internet standard. nokia's requirements are untenable for open source software, which makes them untenable for an internet standard. back to the drawing board, i guess. -- 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 Mar 21 10:45:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18017 for ; Mon, 21 Mar 2005 10:45:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDP4F-000IeW-J0 for namedroppers-data@psg.com; Mon, 21 Mar 2005 15:43:47 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDP4B-000Ids-UL for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 15:43:43 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8F41113E3F for ; Mon, 21 Mar 2005 15:43:43 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Rants on auth denial In-Reply-To: Message from "Olaf M. Kolkman" of "Mon, 21 Mar 2005 15:26:51 +0100." <423ED9AB.5020005@ripe.net> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 21 Mar 2005 15:43:43 +0000 Message-Id: <20050321154343.8F41113E3F@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ...In other words. Anybody on this list: would you deploy an epsilon > based solution, with on-line keys, and no protocol change needed on > the Internet or do y'all see this as an academic exercise? i don't think we can assume that the people who might deploy epsilon are currently self-aware of that fact, nor currently on this list, nor both. -- 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 Mar 21 11:12:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21048 for ; Mon, 21 Mar 2005 11:12:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDPTu-0001lw-Tu for namedroppers-data@psg.com; Mon, 21 Mar 2005 16:10:18 +0000 Received: from [193.0.2.21] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDPTn-0001k5-Ic for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 16:10:11 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 120FA17A374; Mon, 21 Mar 2005 17:10:09 +0100 (CET) Message-ID: <423EF1E0.3000408@ripe.net> Date: Mon, 21 Mar 2005 17:10:08 +0100 From: "Olaf M. Kolkman" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Rants on auth denial References: <20050321154343.8F41113E3F@sa.vix.com> In-Reply-To: <20050321154343.8F41113E3F@sa.vix.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>...In other words. Anybody on this list: would you deploy an epsilon >>based solution, with on-line keys, and no protocol change needed on >>the Internet or do y'all see this as an academic exercise? >> >> > >i don't think we can assume that the people who might deploy epsilon are >currently self-aware of that fact, nor currently on this list, nor both. > > Let me ask if you, and others on this list, are willing to put resources for making epsilon work for those that are not currently self-aware that they will be using the mechanism, nor aware of this work being done, nor both. Even if we fail to find the people who are self-aware that they will deploy epsilon and are on this list. :-) I think that we are close to something useful that works and its not my suggestion to drop this work. It is just that my working assumption was that epsilon would be put to use by an identified party and that I would like to do a reality check on that assumption. Personally I'm willing to burn resources on updating the proof of concept to a new version of the drafts. --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 Mon Mar 21 11:13:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21085 for ; Mon, 21 Mar 2005 11:13:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDPTy-0001mp-9V for namedroppers-data@psg.com; Mon, 21 Mar 2005 16:10:22 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDPTp-0001k6-5p for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 16:10:13 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2LGA6Qv060121 for ; Mon, 21 Mar 2005 11:10:06 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050321154343.8F41113E3F@sa.vix.com> References: <20050321154343.8F41113E3F@sa.vix.com> Date: Mon, 21 Mar 2005 11:10:07 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Rants on auth denial Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >i don't think we can assume that the people who might deploy epsilon are >currently self-aware of that fact, nor currently on this list, nor both. I ask rhetorically, who's fault is that? If the folks on *this list* aren't the ones deploying this, why bother discussing it on *this list*? Perceived problems are to engineers as imaginary gnats flying about a insane person's head. All that flailing about and snatching at thin air. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 21 11:24:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23492 for ; Mon, 21 Mar 2005 11:24:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDPfC-0005JU-En for namedroppers-data@psg.com; Mon, 21 Mar 2005 16:21:58 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDPf7-0005IF-8X for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 16:21:53 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id AE67933C5F; Mon, 21 Mar 2005 16:21:51 +0000 (GMT) Message-ID: <423EF4A4.7070807@algroup.co.uk> Date: Mon, 21 Mar 2005 16:21:56 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" Cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Rants on auth denial References: <20050318112738.037BAE7EA2@mx1.nominet.org.uk> <423AB838.2000504@algroup.co.uk> <87psxwdcoz.fsf@deneb.enyo.de> <423EC82A.1050409@algroup.co.uk> <423ED9AB.5020005@ripe.net> In-Reply-To: <423ED9AB.5020005@ripe.net> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: > >>> >>> That may be. If so, they why is this a working group issue? An >>> implementation is free to generate negative answers in any matter it >>> chooses. >> >> >> >> Because we see it as an interim solution, useful for testing and >> gaining deployment experience only, not one that we could actually >> deploy. Because of that, we don't currently intend to use it even in >> test, since that will be a pointless distraction from NSEC3, which >> solves the problem without all the issues that epsilon introduces. >> > > This statement worries me. > > I was under the impression that "you and yours" were to deploy epsilon > based techniques. Was I wrong, or did your ideas about deployment change? On reflection, we decided that since it was not going to answer our ultimate requirements, deploying it even for test seemed a pointless distraction. We had never intended to deploy it in production. Our thought was that it might be useful in order to gain experience with the rest of the issues surrounding DNSSEC, but it doesn't seem likely to be any more useful any sooner than NSEC3 is for that purpose. So, we feel we should focus on NSEC3 at this stage. Apologies for confusion, this was a conclusion we came to quite recently. > I am also confused by the first and last sentence in the quoted > paragraph. If you will not deploy it, not even in testing how would you > gain deployment experience. Deployment of DNSSEC, I mean. Which we will gain by deploying DNSSEC with NSEC3. > Paraphrasing Ed, in order to publish we'll need running code and > deployment tests. I fully agree with that. I also agree. > Therefore I wonder if there > is sufficient momentum to go forward with the epsilon based methodology > if nobody will deploy anyway? In other words. Anybody on this list: > would you deploy an epsilon based solution, with on-line keys, and no > protocol change needed on the Internet or do y'all see this as an > academic exercise? See above. > I think it would be good to sort out what people are willing to deploy. > If there is nobody even considering do deploy dynamic signing methods > than I think we should just stop considering them as a viable > alternative and waisting valueable working group resources. Agreed. 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 Mar 21 11:54:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26159 for ; Mon, 21 Mar 2005 11:54:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDQ8i-000Cd3-SQ for namedroppers-data@psg.com; Mon, 21 Mar 2005 16:52:28 +0000 Received: from [216.168.239.70] (helo=eagle.verisign.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDQ8g-000CcF-PN for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 16:52:26 +0000 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by eagle.verisign.com (8.12.10/8.12.10) with ESMTP id j2LGhsYo020912; Mon, 21 Mar 2005 11:43:54 -0500 (EST) Received: from chinook ([10.131.31.52]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Mar 2005 11:52:22 -0500 Received: by chinook (Postfix, from userid 500) id 672DC21309B; Mon, 21 Mar 2005 11:52:22 -0500 (EST) Date: Mon, 21 Mar 2005 11:52:22 -0500 From: Matt Larson To: "Olaf M. Kolkman" Cc: Ben Laurie , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Rants on auth denial Message-ID: <20050321165222.GM19585@chinook.corpit.vrsn.com> References: <423EC82A.1050409@algroup.co.uk> <423ED9AB.5020005@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423ED9AB.5020005@ripe.net> User-Agent: Mutt/1.5.6i X-OriginalArrivalTime: 21 Mar 2005 16:52:22.0528 (UTC) FILETIME=[5A22F800:01C52E36] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 21 Mar 2005, Olaf M. Kolkman wrote: > Anybody on this list: > would you deploy an epsilon based solution, with on-line keys, and no > protocol change needed on the Internet or do y'all see this as an > academic exercise? "I encourage my competitors to deploy this solution." Any form of signing on the fly is a non-starter for any VeriSign DNSSEC implementation in com/net. Matt -- Matt Larson VeriSign Naming and Directory Services -- 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 Mar 21 14:58:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11313 for ; Mon, 21 Mar 2005 14:58:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDSzh-0004Fo-5G for namedroppers-data@psg.com; Mon, 21 Mar 2005 19:55:21 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDSzd-0004Cj-8j for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 19:55:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A8D6E13971 for ; Mon, 21 Mar 2005 19:55:16 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Rants on auth denial In-Reply-To: Message from "Olaf M. Kolkman" of "Mon, 21 Mar 2005 17:10:08 +0100." <423EF1E0.3000408@ripe.net> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 21 Mar 2005 19:55:16 +0000 Message-Id: <20050321195516.A8D6E13971@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >i don't think we can assume that the people who might deploy epsilon are > >currently self-aware of that fact, nor currently on this list, nor both. > > Let me ask if you, and others on this list, are willing to put > resources for making epsilon work for those that are not currently > self-aware that they will be using the mechanism, nor aware of this > work being done, nor both. Even if we fail to find the people who are > self-aware that they will deploy epsilon and are on this list. :-) noone who helps ISC pay its bills has told me that epsilon would be useful. > I think that we are close to something useful that works and its not > my suggestion to drop this work. It is just that my working assumption > was that epsilon would be put to use by an identified party and that I > would like to do a reality check on that assumption. > > Personally I'm willing to burn resources on updating the proof of > concept to a new version of the drafts. personally, i'd like to see epsilon developed further, and implemented, and made into a viable option for NSEC-haters to use while waiting for NSEC3 to settle out. otherwise we'll see NSEC-haters sitting out DNSSEC-bis, which is a problem since we're already facing serious nondeployment inertia. -- 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 Mar 21 15:01:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11465 for ; Mon, 21 Mar 2005 15:01:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDT45-0005ZS-Nv for namedroppers-data@psg.com; Mon, 21 Mar 2005 19:59:53 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDT44-0005XO-PE for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 19:59:52 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 47C4913E3F for ; Mon, 21 Mar 2005 19:59:52 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Rants on auth denial In-Reply-To: Message from Edward Lewis of "Mon, 21 Mar 2005 11:10:07 EST." X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 21 Mar 2005 19:59:52 +0000 Message-Id: <20050321195952.47C4913E3F@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >i don't think we can assume that the people who might deploy epsilon are > >currently self-aware of that fact, nor currently on this list, nor both. > > I ask rhetorically, who's fault is that? If the folks on *this list* > aren't the ones deploying this, why bother discussing it on *this list*? i thought this list was about the protocol, and that as stewards of the dns protocol it was our job to make it useful for the entire community including those who come after us. let's not just "cash in" and try to turn dns into something that's just-for-those-in-the-know. > Perceived problems are to engineers as imaginary gnats flying about a > insane person's head. All that flailing about and snatching at thin air. and yet, had we involved nominet et al earlier on, then we would've known that zone walking wasn't an acceptable tradeoff to get authenticated denial. was it nominet's fault for not paying attention to us, or our fault for not paying attention to them? trick question! it doesn't matter whose fault it was, all that matters is we have a nondeployable protocol. ouch! "when in a hole, the first thing you should do is stop digging." -- 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 Mar 21 16:26:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28353 for ; Mon, 21 Mar 2005 16:26:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDUNY-0001Lk-Hl for namedroppers-data@psg.com; Mon, 21 Mar 2005 21:24:04 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDUNX-0001Km-FL for namedroppers@ops.ietf.org; Mon, 21 Mar 2005 21:24:03 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2LLNqN0061269; Mon, 21 Mar 2005 16:23:53 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050321195952.47C4913E3F@sa.vix.com> References: <20050321195952.47C4913E3F@sa.vix.com> Date: Mon, 21 Mar 2005 16:23:58 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Rants on auth denial Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >i thought this list was about the protocol, and that as stewards of the dns >protocol it was our job to make it useful for the entire community including >those who come after us. let's not just "cash in" and try to turn dns into >something that's just-for-those-in-the-know. I fear my words were misunderstood. Having seen protocols gain momentum over time, the eternal question is "how do we get the non-believers in the tent faster?" Until they are in, we are just wasting time preaching to the converted. This is a rhetorical question, because if we knew how to lure in the unsuspecting stake holders, we'd be luring now. >and yet, had we involved nominet et al earlier on, then we would've known >that zone walking wasn't an acceptable tradeoff to get authenticated denial. >was it nominet's fault for not paying attention to us, or our fault for not >paying attention to them? trick question! it doesn't matter whose fault it >was, all that matters is we have a nondeployable protocol. ouch! "when in >a hole, the first thing you should do is stop digging." Exactly what I've been saying, or trying to. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 22 15:10:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26013 for ; Tue, 22 Mar 2005 15:10:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDpdB-0004G0-CU for namedroppers-data@psg.com; Tue, 22 Mar 2005 20:05:37 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDpcq-0004Cm-Rn for namedroppers@ops.ietf.org; Tue, 22 Mar 2005 20:05:17 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2MK57Fd065604; Tue, 22 Mar 2005 15:05:08 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.1.2.2.20050322145515.0403e008@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 22 Mar 2005 15:05:09 -0500 To: gson@araneus.fi (Andreas Gustafsson), =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: DNSEXT WGLC Summary: TSIG SHA1 document Cc: namedroppers@ops.ietf.org In-Reply-To: <16945.30342.344183.997781@guava.araneus.fi> References: <6.2.1.2.2.20050309172309.02d4c7c8@localhost> <16945.30342.344183.997781@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 05:44 11/03/2005, Andreas Gustafsson wrote: >=D3lafur Gu=F0mundsson /DNSEXT co-chair writes: > > Following changes/clarifications are needed in the document > > before it is advanced. > > > > #1 Add text saying implementations can reject messages signed by a > > particular algorithm even if that algorithm is mandatory to implement. > > (important in TKEY environments) > >I agree that implementations must be allowed to reject messages signed >with a mandatory to implement algorithm (that's part of what I meant >by "the distinction between implementing an algorithm and having a >policy of accepting it"), but what does TKEY have to do with it? If we have two entities that are trying to set up TSIG using TKEY but one has policy of preferring ALG X and the other has policy that ALGX is not allowed, in this case we need to point out that the responder is within it's right to refuse exchange. > > #2 Set lower bound on truncation (for each algorithm), > > default lower bound is half of original digest. > >Does this "default lower bound" mean that in the absence of explicit >configuration to the contrary, a receiving implementation should >accept digests truncated to half the original length? If a slave >server has an existing agreement with its master to accept zone >transfers signed with HMAC-MD5 and is upgraded to conform to the new >specification without changing its configuration, will it start >accepting transfers signed with HMAC-MD5-truncated-to-64-bits because >that's the "default lower bound", thereby becoming 2^64 times easier >to attack by brute force and disregarding the administrator's original >intent to require 128-bit HMAC-MD5 signatures? I don't think that's a >good idea. No what this was trying to say is that LOWEST bound ALLOWED by protocol is half the length of the digest. It is up to implementations and/or operators to pick the lowest bound they are willing to live with in the range allowed by protocol. I agree with you that no one should Truncate MD5. >I find this whole discussion about complicated policies to accept >multiple algorithms and ranges of truncation lengths worrisome. >Since TSIG is based on mutual agreement, what's wrong with a policy of >accepting only messages signed with the exact key, algorithm, and >truncation length that were mutually agreed on? This is what existing >TSIG implementations do with respect to the key and algorithm, and I >would like this to continue to be the norm and the default behavior. >If there has been no explicit agreement regarding truncation, as in >the case of agreements predating the draft, the full digest should be >sent by the sender and nothing less than the full digest should be >accepted by the receiver. Excellent point > > #4 add text if responder can use different truncation than sender > > and rules for that. > >This seems like an unnecessary complication. RFC2845 doesn't allow a >response to use an algorithm or key different from the request; why >should truncation be treated any differently? I will change the direction to say, responder MUST use same truncation as sender. Olafur -- 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 Mar 22 15:15:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27003 for ; Tue, 22 Mar 2005 15:15:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDpkw-0005jp-Rt for namedroppers-data@psg.com; Tue, 22 Mar 2005 20:13:38 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDpkv-0005jb-P8 for namedroppers@ops.ietf.org; Tue, 22 Mar 2005 20:13:38 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2MKDVN6065652 for ; Tue, 22 Mar 2005 15:13:32 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.1.2.2.20050322150536.04037a50@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 22 Mar 2005 15:13:34 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT WGLC Summary: TSIG SHA1 document (version #2) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The working group last call has concluded. The document was reviewed by working group members and security area directorate member. The working group supports the document advancement. Following changes/clarifications are needed in the document before it is advanced. #1 Add text saying implementations can reject messages signed by a particular algorithm even if that algorithm is mandatory to implement. (important in TKEY environments where there is no human involved in negotiating the algorithm type). #2 Set lower bound on truncation (for each algorithm), default lower bound is half of original digest. i.e. text should read "MUST NOT accept signatures truncated to half or less of digest". #3 add new TSIG error code that sender is using excessive truncation #4 add text saying responder MUST use same truncation as sender. #5 Remove unused reference to 2434 #6 Add text that defines what is included in subsequent digest when truncation is used (full or truncated digest) After the document is updated there will be a 2 week review period before the chairs will advance the document to the IESG. Olafur -- 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 Mar 22 17:04:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12514 for ; Tue, 22 Mar 2005 17:04:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDrRQ-000NMv-Jy for namedroppers-data@psg.com; Tue, 22 Mar 2005 22:01:36 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDrRP-000NMY-9k for namedroppers@ops.ietf.org; Tue, 22 Mar 2005 22:01:35 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2MLvtpr006589 for ; Tue, 22 Mar 2005 16:57:55 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAE6aq3m; Tue, 22 Mar 05 16:57:52 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j2MLxaOb024535; Tue, 22 Mar 2005 16:59:40 -0500 (EST) Date: Tue, 22 Mar 2005 16:59:36 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Simon Josefsson cc: namedroppers@ops.ietf.org Subject: Re: rfc2538bis IANA considerations In-Reply-To: Message-ID: References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think there are two remaining open questions related to the CERT RR and the DNSSEC algorithm number registry. Any input? Do we want to allow CERT RRs to contain ALL algorithm types specified in this registry, or do we want to add another applicability list? > > -- Can CERTs use private algorithms (type 253/254)? If so, do you > > still want to use the same encoding as for KEY/DNSKEY, with the > > algorithm in the RDATA? Some explicit mention of the private > > algorithms might be a good idea, in any case. Also note David > > Blacka's DNSSEC experiment draft, which encourages use of > > the private algorithms. > > I have no idea how to address this, nor can I answer the question. I > hope that others will give input on this. > > > -- Given that 3755 added applicablility columns to the algorithm > > registry (see the registry itself and 3755 for details), do you > > want another column for CERT, along with a requirement that new > > algorithm definitions say whether they can be used for CERTs or > > not? > > It seem to require some work for new algorithm definers. My > experience is that the key tag and algorithm fields of CERT RRs are > rarely useful, nor consistently populated. So the additional work > will lead to little practical advantage, in my opinion. That would > suggest we shouldn't worry about this. > > However, this seem to be more of a process issue, than a technical > concern, so I'd be interested to hear what others feel. And then there's the straight-forward IANA text: > > -- Ask IANA to add a citation to 2538bis for algorithm 0 -- it's > > already marked reserved, but 2538 explains why it needs to > > remain reserved. You might even rename it to 'CERT RR private' > > or somesuch. > > > > -- Ask IANA to add the CERT RR to the list of type codes that use this > > registry. That may encourage the next fool who comes along and > > wants to change or reuse the registry to remember CERT, as we > > forgot to do in 2004. > > Do you think anything should go into 2538bis to achieve this? Yes, how about adding to the IANA section of 2538bis: "The CERT RR reuses the DNS Security Algorithm Numbers registry. In particular, the CERT RR requires that algorithm number 0 remain reserved, as described in Section 2. The IANA is directed to reference the CERT RR as a user of this registry and value 0, in particular." It's a shame we have to do this explicitly, but emails to IANA about it just haven't been answered. Perhaps the below could be sent to IANA out-of-band, too: > > If you want to reuse all algorithms registers, the doc should > > say that (and the registry probably should, too). Suggested > > registry text for the 'reuse all' option might be: > > > > OLD: The KEY, SIG, DNSKEY, RRSIG, and DS RRs use an 8-bit number used > > to identify the security algorithm being used. > > > > Some algorithms are usable only for zone signing (DNSSEC), some > > only for transaction security mechanisms (SIG(0) and TSIG), and > > some for both. Those usable for zone signing may appear in > > DNSKEY, RRSIG, and DS RRs. Those usable for SIG(0) and TSIG may > > appear in SIG and KEY RRs. > > > > NEW: The KEY, SIG, DNSKEY, RRSIG, DS, and CERT RRs use an 8-bit > > number used to identify the security algorithm being used. > > > > All algorithm numbers in this registry may be used in CERT RRs. > > Some algorithms are not usable for zone signing (DNSSEC) and > > some are not usable for transaction security mechanisms (SIG(0) > > and TSIG). Only those usable for zone signing may appear in > > DNSKEY, RRSIG, and DS RRs. Only those usable for SIG(0) and > > TSIG may appear in SIG and KEY RRs. -- 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 Fri Mar 25 07:57:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22811 for ; Fri, 25 Mar 2005 07:57:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEoI8-00031O-7e for namedroppers-data@psg.com; Fri, 25 Mar 2005 12:51:56 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DEoI5-00030D-0S for namedroppers@ops.ietf.org; Fri, 25 Mar 2005 12:51:53 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id B855E33C45; Fri, 25 Mar 2005 12:51:50 +0000 (GMT) Message-ID: <42440969.6040309@algroup.co.uk> Date: Fri, 25 Mar 2005 12:51:53 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_co-chair?= Cc: namedroppers@ops.ietf.org Subject: Re: Key-rollover IPR disclosure References: <6.2.0.14.2.20050215104624.03d3d278@localhost> <6.2.1.2.2.20050308114811.02c94960@localhost> In-Reply-To: <6.2.1.2.2.20050308114811.02c94960@localhost> X-Enigmail-Version: 0.89.6.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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Ólafur Guðmundsson /DNSEXT co-chair wrote: > We have received a response from Diversinet.com about more detailed > licence terms and the status of their patent applications in other > countries and here is their response: > > > "Diversinet's position at this time is that it is worthwhile, from a > public relations perspective, for it to license its technology on terms > that are reciprocal, reasonable and royalty free, if such technology is > incorporated into a specification. Our general license would contain > terms that are typical in a commercial intellectual property license, > and would include a requirement that any organization using the > technology covered by our patent would have to disclose prescribed > language indicating that the licensee's service or product incorporates > intellectual property owned by Diversinet, and that such organization > would agree to be referenceable by Diversinet in any publicity regarding > Diversinet's patent portfolio." > > We also have a patent application #2306505 that was filed in Canada on > Aug 13, 1998. The application is identical to the patent that was > obtained from Israel. > > I am planning to update our 2 IPR filed for IETF to include the above > paragraph and the Canadian patent application. > > > Chairs are not sure what exactly what the next step is, but we will > keep you posted when we find out. This statement does not seem to lead to anything usable in several ways. Firstly, it only states their position _at this time_, and so could change at the drop of a hat. Secondly, it is still unclear whether they intend _end users_ to be referencable (certainly that's what they say if read literally). Thirdly, reciprocity may be ok for implementers, but again, it is not clear whether this applies to end users - if it does, I can't imagine end users being interested, in general. 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 Mar 25 11:14:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13015 for ; Fri, 25 Mar 2005 11:14:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DErPV-0008qI-8K for namedroppers-data@psg.com; Fri, 25 Mar 2005 16:11:45 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DErPS-0008nq-0O for namedroppers@ops.ietf.org; Fri, 25 Mar 2005 16:11:42 +0000 Received: from [10.31.33.65] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2PGBXL6084514; Fri, 25 Mar 2005 11:11:34 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Fri, 25 Mar 2005 11:09:03 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Type Code 31 Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This isn't really about type code 31, but about the type codes allocated by IANA that are not defined in persistent documents. Recently I was asked to look at http://www.iana.org/assignments/dns-parameters, to find better references for things like: # EID 31 Endpoint Identifier [Patton] # NIMLOC 32 Nimrod Locator [Patton] ... # [Patton] Michael Patton, , June 1995. Now, Mike's a good guy and all and he doesn't deserve to be a walking encylopedia of stuff no one uses. I was able to find a document covering these types here: http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt. This is not in a place that IANA can count on to hold this forever, nor the IETF. Another example along these lines is: # SINK 40 SINK [Eastlake] ... # [Eastlake] Donald E. Eastlake, III , January 1995, # November 1997. It's last known address is this, another non-IETF/IANA provided site: http://bgp.potaroo.net/ietf/all-ids/draft-eastlake-kitchen-sink-02.txt You search the mail archives you can find that it was killed about the time of WG last call. The problem is - we need to have persistent definitions of types *actively* allocated by IANA available to implementers. (Relying on looking at the BIND code notwithstanding.) For types that are not in use, we should document that. At the time SINK was killed, there ought to have been an action to un-register the type, or at least mark it as obsolete. We don't need to revive a definition of the SINK to kill it, just a note to IANA to mark it as obsolete (like type 3) or return the code to the available pool. RFC 2929 does not cover "garbage collection," maybe it should. Maybe we just need a document to cut out all the obsoleted types from IANA. Comments on this? PS - I'd do more, but I should be working on wcard. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 25 11:33:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15543 for ; Fri, 25 Mar 2005 11:33:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DErjC-000CK3-NO for namedroppers-data@psg.com; Fri, 25 Mar 2005 16:32:06 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DErjB-000CJo-Ix for namedroppers@ops.ietf.org; Fri, 25 Mar 2005 16:32:06 +0000 Received: from [10.31.33.65] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2PGVwCI084607; Fri, 25 Mar 2005 11:31:58 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Fri, 25 Mar 2005 11:32:05 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: wcard discussions in Minneapolis Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a summary of wcards at Minneapolis. On Monday of IETF week an informally gathered subset of the WG discussed issues in detail, here is the outcome of that discussion (note - this is not a WG decision, but a set of recommendations that were then discussed in the face-to-face meeting): 1) Considering '* NS' and '* DNAME' 1A) Change the text in RFC 1034, 4.3.2, step 3, part c to this: c. If at some label, a match is impossible (i.e., the corresponding label does not exist), look to see if a the "*" label exists AND DOES NOT OWN AN NS RRSET NOR A DNAME RRSET. 1B) Any query that would have otherwise resulted in a wildcard match received a "return code=name error" (NXDOMAIN) so that caches can retain the negative answer. 1C) The label count in the RRSIG is not decremented for the presence of an asterisk label if there is a NS or DNAME owned there, as this name is now not capable of being a source of synthesis. 2) No other issues were raised, recognizing the document had changed once since the last meeting. In particular I was curious about the SRV text. During the scehduled IETF meeting on Wednesday morning, this proposal met with a something between a "less than enthusiastic" response and "tomato throwing" response. One person did indeed brandish a piece of fruit, although it was not a tomato and it was not rotten. (I.e., it would have left a welt.) The cry was "don't change the signer." Instead, the prevailing suggesting became to "outlaw" '* NS' and '* DNAME'. "Outlawing" would entail: 1) Defining the semantics of '* NS/DNAME' on zone loading. 2) Defining the semantics of '* NS/DNAME' in a [AI]XFR zone transfer. 3) Defining the semantics of '* NS/DNAME' in a dynamic update request. 4) Convincing anyone who make use of a '*' zone to give it up. The discussion ranged as far as whether rejecting a zone was an interoperability concern. More or less yes, as it would be good to have masters and slaves behave consistently even if they are different implementations. What I've listed here are just the recommendations, not the rationale. E.g., I still need to figure out why this applies to DNAME, but I'm willing to suspend disbelief for the moment while gathering these comments. PS - I would like to personally thank Mr. Ihren for showing restraint when it came to the use of fruit in the meeting. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 25 15:18:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07725 for ; Fri, 25 Mar 2005 15:18:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEvCo-000C65-Tk for namedroppers-data@psg.com; Fri, 25 Mar 2005 20:14:54 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DEvCn-000C5d-Mo for namedroppers@ops.ietf.org; Fri, 25 Mar 2005 20:14:54 +0000 Received: from [10.31.33.65] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2PKEhvH085374; Fri, 25 Mar 2005 15:14:44 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050321120518.7b0dd87a.olaf@ripe.net> References: <20050321120518.7b0dd87a.olaf@ripe.net> Date: Fri, 25 Mar 2005 15:14:56 -0500 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: Draft DNSEXT @ IETF62 Minutes Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Mostly to clean up characters in the WCard=20 discussion, just one rewrite for clarity. (Put=20 my suggested replacement paragraph after the=20 original for cut and paste ease.) At 12:05 +0100 3/21/05, Olaf M. Kolkman wrote: >Minutes of the DNSEXT working group >62nd IETF, Minneapolis, USA >9 March 2005 >Wildcard Document >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2E.. >(Discussion) > >Rob Austein: In what way couldn't DNSSEC sign it? > >Ed Lewis: Lets say I am going through the algorithm for answering >=93a.example=94 and the qtype is =93NS=94. What is would do in that situati= on >is go through the zone and fine no a, then I=92d go to star and then I=92d >match the * NS. According to wildcard normal rules, a.example NS will >expand into the answer section. I am required to have a signature there, >I cant put the signature in there. To make this legal I have to change >the protocols document so that signers would have to sign this >particular case.. if there was a signature there, the problem is the sig >would be signed by the wrong authority. Ed Lewis: Lets say I am going through the algorithm for QNAME "a.example." and the QTYPE is NS. What would be done in that situation is go through the zone and fine no "a" label so I'd go to star("*") and match the * NS. According to wildcard normal rules, "a.example NS" will expand into the answer section. I am required to have a signature there, but there is no signature to put there. To make this legal I have to change the DNSSECbis protocols document so that signers would have to sign this particular case. If there was a signature there, the problem is the sig would be signed by the wrong authority. >Rob Austein: My problem is this seems to be a special case to deal with >garbage input. I'd rather not have special case rules to handle zones >like these. > >Lars Liman: What you=92re looking at is an NS record in the parent zone, >and you are worrying about the signature of that, but it is not going to >be signed in the parent zone. If you ask the parent server for a deleg >NS, are you supposed to get an answer, or a referral? > >Ed Lewis: If you look at the algorithm, there are three parts: (a) a >direct match, (b) a delegation point, and (c) a closest encloser. Then I >answer with a wildcard, no wildcard etc. When I come down I don=92t see >the cut point, it is not on my search point, so B doesn=92t work. Ed Lewis: If you look at the algorithm, there are three parts: (a) a direct match, (b) a delegation point, and (c) a closest encloser., where I answer with a wildcard or no wildcard. When I come down I don't see the cut point, it is not on my search point, so B doesn't work. (To rewrite this more...The reason that the "*=20 NS" does not result in a referral message when=20 seeking "a.example. NS" is this. Following the=20 4.3.2 algorithm, I would fall into part C, which=20 is the part in which my last matching label is at=20 the closest encloser, so I am in a "wildcard or=20 not situation." Referrals are in part B, but I=20 didn't enter there.) >This is written in the draft when we enter step (a), (b) or (c), we >don't jump across. > >Rob Austein: You are going to have to have a case in the ordinary >processing for the authorittive nameserver =93I know what is supposed to >be in the zone but it wasn=92t there=94. As far as I can tell this covers >this mess. It is general purpose error processing. I don=92t see why we >need a special case. Rob Austein: You are going to have to have a case in the ordinary processing for the authoritative nameserver "I know what is supposed to be in the zone but it wasn't there". As far as I can tell this covers this mess. It is general purpose error processing. I don't see why we need a special case. >Ed Lewis: I see what you mean =96 in Washington we talked of the same >thing. I made a mistake then thinking there would be a signature there. >With no sig there we would have to let the validator know it is a weird >case. We have to do some editing somewhere and the group on Monday felt >this is the best place to do the edits. Text will be coming to describe it. Ed Lewis: I see what you mean, in Washington we talked of the same thing. I made a mistake then thinking there would be a signature there. With no sig there we would have to let the validator know it is a weird case. We have to do some editing somewhere and the group on Monday felt this is the best place to do the edits. Text will be coming to describe it. >If the type is not NS, there is no problem. Only when it is an NS or a >DS do we get anything back and there is where there is a concern. > >This is how the rule would be changed in 1034. If some label has an >impossible match, look for existence of the star label, and does not own >an NS RRSet nor a DNAME RRSet. Treat a * NS or * DNAME as =93not there=94. This is how the rule would be changed in 1034. If some label has an impossible match, look for existence of the star label, and does not own an NS RRSet nor a DNAME RRSet. Treat a * NS or * DNAME as name "not there". -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 25 23:12:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23971 for ; Fri, 25 Mar 2005 23:12:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DF2ae-000OMa-Br for namedroppers-data@psg.com; Sat, 26 Mar 2005 04:08:00 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DF2ad-000OMG-1h for namedroppers@ops.ietf.org; Sat, 26 Mar 2005 04:07:59 +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 50BCA75E for ; Fri, 25 Mar 2005 23:07:57 -0500 (EST) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 85D7241E3 for ; Fri, 25 Mar 2005 23:07:56 -0500 (EST) Date: Fri, 25 Mar 2005 23:07:56 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis In-Reply-To: References: MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050326040756.85D7241E3@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 25 Mar 2005 11:32:05 -0500, Edward Lewis wrote: > ... > The cry was "don't change the signer." Instead, the prevailing > suggesting became to "outlaw" '* NS' and '* DNAME'. The WG meeting suggested two possible approaches. Outlawing the pathological cases was one. The other was to leave behavior in the pathological cases undefined ("garbage in, garbage out"). If there was any consensus on which of these approaches to take, it was not immediately obvious to me, but judging that's the chairs' job. -- 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 Mar 26 20:17:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20236 for ; Sat, 26 Mar 2005 20:17:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DFMJz-0007QI-8K for namedroppers-data@psg.com; Sun, 27 Mar 2005 01:12:07 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DFMJw-0007Pl-TL for namedroppers@ops.ietf.org; Sun, 27 Mar 2005 01:12:05 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j2R1C1KN022096; Sun, 27 Mar 2005 01:12:01 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j2R1Bu93022093; Sun, 27 Mar 2005 01:11:56 GMT Date: Sun, 27 Mar 2005 01:11:56 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Type Code 31 Message-ID: <20050327011156.GA21947@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk for me - i'd prefer to have a persistant record of all defined types - including the dead, obscure, and goofball. including some that were in early code bases and were excised in the reference implementation simply for lack of an RFC... even tho the IANA listed them. i guess my list w/ docs attached will have to go online. :) --bill On Fri, Mar 25, 2005 at 11:09:03AM -0500, Edward Lewis wrote: > This isn't really about type code 31, but about the type codes > allocated by IANA that are not defined in persistent documents. > > Recently I was asked to look at > http://www.iana.org/assignments/dns-parameters, to find better > references for things like: > > # EID 31 Endpoint Identifier [Patton] > # NIMLOC 32 Nimrod Locator [Patton] > ... > # [Patton] Michael Patton, , June 1995. > > Now, Mike's a good guy and all and he doesn't deserve to be a walking > encylopedia of stuff no one uses. I was able to find a document > covering these types here: > http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt. This is not in a place > that IANA can count on to hold this forever, nor the IETF. > > Another example along these lines is: > # SINK 40 SINK [Eastlake] > ... > # [Eastlake] Donald E. Eastlake, III , January > 1995, > # November 1997. > > It's last known address is this, another non-IETF/IANA provided site: > > http://bgp.potaroo.net/ietf/all-ids/draft-eastlake-kitchen-sink-02.txt > > You search the mail archives you can find that it was killed about > the time of WG last call. > > The problem is - we need to have persistent definitions of types > *actively* allocated by IANA available to implementers. (Relying on > looking at the BIND code notwithstanding.) > > For types that are not in use, we should document that. At the time > SINK was killed, there ought to have been an action to un-register > the type, or at least mark it as obsolete. We don't need to revive a > definition of the SINK to kill it, just a note to IANA to mark it as > obsolete (like type 3) or return the code to the available pool. > > RFC 2929 does not cover "garbage collection," maybe it should. > > Maybe we just need a document to cut out all the obsoleted types from IANA. > > Comments on this? > > PS - I'd do more, but I should be working on wcard. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Achieving total enlightenment has taught me that ignorance is bliss. > > -- > 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 Mar 26 23:55:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04968 for ; Sat, 26 Mar 2005 23:55:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DFPlV-0007AV-EK for namedroppers-data@psg.com; Sun, 27 Mar 2005 04:52:45 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DFPlS-00079s-NA for namedroppers@ops.ietf.org; Sun, 27 Mar 2005 04:52:43 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2R4qN2f090458; Sat, 26 Mar 2005 23:52:23 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050327011156.GA21947@vacation.karoshi.com.> References: <20050327011156.GA21947@vacation.karoshi.com.> Date: Sat, 26 Mar 2005 23:51:41 -0500 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: Type Code 31 Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On the one hand, having a historical record is good - what killed a record is worth remembering. On the other hand, let's not clutter up implementations with unnecessary code paths. I think the latter is necessary, the other is nice to have. At 1:11 +0000 3/27/05, bmanning@vacation.karoshi.com wrote: >for me - i'd prefer to have a persistant record of all defined >types - including the dead, obscure, and goofball. including >some that were in early code bases and were excised in the reference >implementation simply for lack of an RFC... even tho the IANA >listed them. > >i guess my list w/ docs attached will have to go online. :) > >--bill > > >On Fri, Mar 25, 2005 at 11:09:03AM -0500, Edward Lewis wrote: >> This isn't really about type code 31, but about the type codes >> allocated by IANA that are not defined in persistent documents. >> >> Recently I was asked to look at >> http://www.iana.org/assignments/dns-parameters, to find better >> references for things like: >> >> # EID 31 Endpoint Identifier [Patton] >> # NIMLOC 32 Nimrod Locator [Patton] >> ... >> # [Patton] Michael Patton, , June 1995. >> >> Now, Mike's a good guy and all and he doesn't deserve to be a walking >> encylopedia of stuff no one uses. I was able to find a document >> covering these types here: >> http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt. This is not in a place >> that IANA can count on to hold this forever, nor the IETF. >> >> Another example along these lines is: >> # SINK 40 SINK [Eastlake] >> ... >> # [Eastlake] Donald E. Eastlake, III , January >> 1995, >> # November 1997. >> >> It's last known address is this, another non-IETF/IANA provided site: >> >> http://bgp.potaroo.net/ietf/all-ids/draft-eastlake-kitchen-sink-02.txt >> >> You search the mail archives you can find that it was killed about >> the time of WG last call. >> >> The problem is - we need to have persistent definitions of types >> *actively* allocated by IANA available to implementers. (Relying on >> looking at the BIND code notwithstanding.) >> >> For types that are not in use, we should document that. At the time >> SINK was killed, there ought to have been an action to un-register >> the type, or at least mark it as obsolete. We don't need to revive a >> definition of the SINK to kill it, just a note to IANA to mark it as >> obsolete (like type 3) or return the code to the available pool. >> >> RFC 2929 does not cover "garbage collection," maybe it should. >> >> Maybe we just need a document to cut out all the obsoleted types from IANA. >> >> Comments on this? >> >> PS - I'd do more, but I should be working on wcard. >> -- >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Edward Lewis +1-571-434-5468 >> NeuStar >> >> Achieving total enlightenment has taught me that ignorance is bliss. >> >> -- >> 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: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 stefanie8fia@uta.com Mon Mar 28 05:11:58 2005 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 FAA28660; Mon, 28 Mar 2005 05:11:57 -0500 (EST) Received: from d60-65-239-240.col.wideopenwest.com ([65.60.240.239]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DFrKR-0005zU-T5; Mon, 28 Mar 2005 05:18:42 -0500 Received: from academia.stefanie8fia@uta.com ([132.151.6.1]) by dockyard.stefanie8fia@uta.com with MailEnable ESMTP; Mon, 28 Mar 2005 04:11:30 -0600 Date: Mon, 28 Mar 2005 04:11:30 -0600 Message-Id: <5480694987759.46016@laurie-allyson> From: marlyssa justice To: Disman-web-archive Subject: Microsoft Windows Xp For 89 $ MIME-Version: 1.0 Content-Type: text/html; charset="iso-4764-9" Content-Transfer-Encoding: 7Bit Content-Description: besetting increment merchant X-Spam-Score: 8.9 (++++++++) X-Spam-Flag: YES X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7Bit Did you know you could purchase the most popular and needed software with % 80-90 discount ?
Do NOT pay a fortune for your usual software needs.Check our site and compare the prices.
You will see that you save a lot if you purchase the software from us and this is completely legal.
Below there is a very little list that shows our oem software's prices comparison with original manufacturer.

Oem Software Name Our Price Manufacturer Price Your Save
Microsoft Windows XP Professional with SP2 Full Version + Office 2003 Professional 99 $ 430 $ 331 $
Microsoft Windows 2000 Professional 59 $ 430 $ 371 $
MS Windows XP Pro + MS Office XP Pro 89 $ 760 $ 671 $
Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 129 $ 720 $ 591 $
Adobe Acrobat 6 Professional 80 $ 569 $ 489 $
Corel Draw 11 Graphic Suite 59 $ 437 $ 378 $
Corel WordPerfect Office 10 69 $ 200 $ 131 $
Macromedia Dreamweaver Mx 2004 69 $ 390 $ 321 $

The list you see above is just % 1 of our software list.You can find loads of cool software at
incredibly low prices.There are also Macintosh editions of our softwares.We guarantee that
we are the cheapest oem software seller site on the net.Just click our link and check our prices.

The Cheapest Oem Software Store Here From owner-namedroppers@ops.ietf.org Mon Mar 28 17:03:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16788 for ; Mon, 28 Mar 2005 17:03:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DG2FU-0000yT-GR for namedroppers-data@psg.com; Mon, 28 Mar 2005 21:58:16 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DG2FT-0000yE-Bd for namedroppers@ops.ietf.org; Mon, 28 Mar 2005 21:58:15 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2SLsXvK005266 for ; Mon, 28 Mar 2005 16:54:33 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAJ7ayrk; Mon, 28 Mar 05 16:54:30 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j2SLuKsR013153 for ; Mon, 28 Mar 2005 16:56:20 -0500 (EST) Date: Mon, 28 Mar 2005 16:56:20 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: DNSSECbis published! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Although they haven't been announced yet, RFC4033, RFC4034, and RFC4035 are available at most of the RFC mirrors. Congratulations to Roy Arends, Scott Rose, Matt Larson, Rob Austein, and Dan Massey. Thank you for all of your hard work. If I recall correctly, Scott and Dan were conscripted as the two DNSSECbis editors on 21 March 2001, at IETF-50. WG last call was anticipated to happen in July 2001. The first WGLC on the triology concluded on 26 January 2004. The second WGLC concluded on 2 June 2004. For at least two of these editors, that's over four years as stuckee. Good job, gentlemen! -- 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 Mon Mar 28 19:59:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02516 for ; Mon, 28 Mar 2005 19:59:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DG52L-000P2W-Q8 for namedroppers-data@psg.com; Tue, 29 Mar 2005 00:56:53 +0000 Received: from [200.23.30.77] (helo=mail.nic.mx) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DG52K-000P2I-GA for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 00:56:52 +0000 Received: from localhost (localhost.nic.mx [127.0.0.1]) by mail.nic.mx (Postfix) with ESMTP id AED821815DA for ; Mon, 28 Mar 2005 18:56:51 -0600 (CST) Received: from mail.nic.mx ([127.0.0.1]) by localhost (mail.nic.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21712-10 for ; Mon, 28 Mar 2005 18:56:51 -0600 (CST) Received: from glozano.mail.nic.mx (unknown [200.33.1.76]) by mail.nic.mx (Postfix) with ESMTP id 686041815CD for ; Mon, 28 Mar 2005 18:56:51 -0600 (CST) Message-Id: <6.2.1.2.2.20050328185501.0b730538@mail.nic.mx> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 28 Mar 2005 18:56:50 -0600 To: namedroppers@ops.ietf.org From: Gustavo Lozano Ibarra Subject: zone walking and random generated names Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new at nic.mx X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 12/14/2004, I sent a draft about using random generated names to do authenticated denial of existence in DNSSEC. I received some replies about a possible MTM attack. I still believe that using random generated names can solve the problem of non zone walking offline generated authenticated denial of existence. I updated the idea of random generated names to stop the MTM attack mentioned on the list and I want to know the list opinion about it in order to not waste resources on bad ideas. Maybe I am missing something said in the last 10 years about random generated names. The zone example.com. has the following data: b.example.com. A 10.10.10.10 e.example.com. A 10.10.10.11 In DNSSECbis a NSEC RR will be created to proof non existence of c.example.com. and non existence of RR AAAA for b.example.com. b.example.com. NSEC e.example.com. (A RRSIG) Using random NSEC you will create random names between each existing domain: a.example.com. and d.example.com. for example. Two new RRs are introduced in random NSEC: rnxd (random non exising domain proof) and rnxrr (random non existing resource record proof): rnxd is used to proof the non existence of a name between two following random generated names. A hash of the FQDN of the non random generated name between the two following random generated names is sent in the response to prevent MTM attacks. rnxrr is used to proof the non existence of a RR for a non random generated name. The following record is sent to the client to proof the non existence of c.example.com. The resolver do a verification procedure as in DNSSECbis and also verifies that b.example.com. is not the hash value in the rnxd RR to prevent MTM attacks. a.example.com. rnxd d.example.com. f96a6ec2fb6efbe43002f4cbf124f90879424d79 The following record is sent to the client to proof the non existence of RR AAAA for b.example.com. b.example.com. rnxrr (A RRSIG) The following records will be also generated. d.example.com. rnxd a.example.com. eb391a1462ef3dda8fdba242cf55cdab843422bb e.example.com. rnxrr (A RRSIG) The idea is to use the same utility that generated the signed zones to also generate the random names, rnxd and rnxrr records. Using this idea, an attacker will then enumerate the random-generated names and will obtain the hash values of the non-random generated names. Thanks. -- 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 Mar 28 23:03:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16570 for ; Mon, 28 Mar 2005 23:03:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DG7sg-000Kos-35 for namedroppers-data@psg.com; Tue, 29 Mar 2005 03:59:06 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DG7sf-000KoX-3L for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 03:59:05 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2T3tM5E004813 for ; Mon, 28 Mar 2005 22:55:22 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA1Mayzj; Mon, 28 Mar 05 22:55:20 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j2T3v6SU022315; Mon, 28 Mar 2005 22:57:07 -0500 (EST) Date: Mon, 28 Mar 2005 22:57:06 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Gustavo Lozano Ibarra cc: namedroppers@ops.ietf.org Subject: Re: zone walking and random generated names In-Reply-To: <6.2.1.2.2.20050328185501.0b730538@mail.nic.mx> Message-ID: References: <6.2.1.2.2.20050328185501.0b730538@mail.nic.mx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm having an extraordinarily hard time following these examples[1]. You might try reformatting the examples to clearly show the bounds of RRs (for example, it was not immediately obvious to me that the quoted text below was one RR wrapped across two lines). Feel free to truncate hashes in these examples. > The following record is sent to the client to proof the non existence of > c.example.com. The resolver do a verification procedure as in DNSSECbis and > also verifies that b.example.com. is not the hash value in the rnxd RR to > prevent MTM attacks. > > a.example.com. rnxd > d.example.com. f96a6ec2fb6efbe43002f4cbf124f90879424d79 I'm going to take at guess about waht you mean and try to respond anyway. How does the resolver know it needs to check that b.example.com does not hash to this value? Why would it know the name "b" at all? And wouldn't telling the resolver that "b" exists enable enumeration? -- Sam [1] Actually, I think I understand the RNXRR (it's like NSEC, only without the 'next name' field -- it just lists what RR types are at a name). -- 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 Mar 29 01:02:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26817 for ; Tue, 29 Mar 2005 01:02:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DG9kq-000BtT-Ub for namedroppers-data@psg.com; Tue, 29 Mar 2005 05:59:08 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DG9kZ-000Bro-O5 for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 05:58:51 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2T5t8Q4016002 for ; Tue, 29 Mar 2005 00:55:08 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAWJaOpF; Tue, 29 Mar 05 00:55:04 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j2T5uq04025638; Tue, 29 Mar 2005 00:56:52 -0500 (EST) Date: Tue, 29 Mar 2005 00:56:52 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Gustavo Lozano Ibarra cc: namedroppers@ops.ietf.org Subject: Re: zone walking and random generated names In-Reply-To: <6.2.1.2.2.20050328185501.0b730538@mail.nic.mx> Message-ID: References: <6.2.1.2.2.20050328185501.0b730538@mail.nic.mx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk After spending some more time on this, it's starting to sink in (or, at least, something is sinking in -- I hope it's what Gustavo intended). This is a very interesting idea. Thank you very much for sharing it with us. I'm going to try to explain this in different words. Please tell me if I get it wrong. For the moment, I'm only going to look at how to prove that a name doesn't exist at all, and I'm going to ignore how to prove what RR types exist at a given name. I'm also going to ignore what happens at the beginning and end of zones. I think the propsoal is: Insert a new name between all existing names in the zone, thereby breaking the zone up into spans that each contain EXACTLY one name, no more, no less. At these new names, build an NSEC (or RNXD) chain containing JUST the random names. (Original names don't get NSECs.) These new NSECs (RNXDs) prove that there is exactly one name between the endpoints of the NSEC. Add to the NSEC (RNXD) RR the hash of the ONE original name contained in that span. Looking at an example used earlier in this thread (and stealing some text from the draft): > The zone example.com. has the following data: > > b.example.com. A 10.10.10.10 > e.example.com. A 10.10.10.11 ... > Using random NSEC you will create random names between each existing > domain: a.example.com. and d.example.com. for example. This leaves a zone of: a.example (random generated) b.example (original) c.example (random generated) e.example (original) f.example (random generated) Or, more specifically: a.example NSEC c.example hashof(b.example) b.example A 10.10.10.10 c.example NSEC f.example hashof(e.example) e.example A 10.10.10.11 f.example NSEC something hashof(something) Along with appropriate RRSIGs and zone apex RRs and such. When faced with a query for (the non-existant) d.example.com, the server returns the c.example NSEC (or RNXD). What does the resolver do? The resolver sees that the returned NSEC proves that only one name exists between c and f. It then hashes the QNAME and compares the hash to the hash in the NSEC. They don't match, so this QNAME must not be the one name in this span. Thus, the QNAME does not exist. If hash(QNAME) had matched the hash in the NSEC, then this NSEC would prove that the QNAME does exist. And if the plaintext QNAME had, perchance, matched either of the endpoints of the NSEC RR, then the name would (ironically) have been proven to not exist, since NSEC RRs are only inserted where there are not already existing names. The proposal suggests a second RR type at each existing name to list the RR types at that name. I think that the NSEC/RNXD RR could still do that -- it just lists the types present at the hashed name. Presumably the NSEC/RNXD would also need to list the hash parameters used (just like the NSEC2/3/++ proposals). This would lead to really long NSEC RR's, but no extra RRs. For example: a.example NSEC c.example hashof(b.example) ( A RRSIG ) hash-param b.example A 10.10.10.10 c.example NSEC f.example hashof(e.example) ( A RRSIG ) hash-param e.example A 10.10.10.11 f.example NSEC something hashof(something) ( types ) This proposal, if I've understood it correctly, seems to have some interesting potential. It trivially allows for different hash parameters at each span, facilitating hash algorithm and parameter changes. We'd need to work out the beginning- and end-of-zone details, but that seems easy. It's not clear how it would work with wildcard proofs (empty non-terminals, anyone?) -- that could be harder. It avoids the potential "recursion" problem in the NSEC++ proposals, where one NSEC++ proves that another one doesn't exist. This proposal exposes more about the zone than the NSEC++ proposals: they only allow counting of the zone and relative numbers of RR types present, whereas this exposes some information about the lexical distribution of names. One could limit the exposure of information by inserting extra random names in the NSEC/RNXD chain -- in the newly created spans where no real name exists, use the hash of some name outside of that span and a synthesized type bitmap. I'm assuming that, other than for some wildcard proofs, a resolver always knows or can easily infer which names it needs to prove the non-existence of, so it knows what value to look for in the hash, but I'm not sure if that's actually true or not. In any case, thanks again to Gustavo for sharing this idea. -- 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 Mar 29 03:47:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03125 for ; Tue, 29 Mar 2005 03:47:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGCJZ-0005Aq-RH for namedroppers-data@psg.com; Tue, 29 Mar 2005 08:43:09 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGCJX-0005A7-Nm for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 08:43:07 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 3120024E31; Tue, 29 Mar 2005 10:43:07 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 4677924BC4; Tue, 29 Mar 2005 10:43:05 +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 j2T8h5et028204; Tue, 29 Mar 2005 10:43:05 +0200 Date: Tue, 29 Mar 2005 10:43:05 +0200 From: "Olaf M. Kolkman" To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis Message-Id: <20050329104305.296a5a8c.olaf@ripe.net> In-Reply-To: <20050326040756.85D7241E3@thrintun.hactrn.net> References: <20050326040756.85D7241E3@thrintun.hactrn.net> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (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-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -5.9 X-RIPE-Signature: 34f3a3a1d731cbe4637b5e881b2aa82c X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 25 Mar 2005 23:07:56 -0500 Rob Austein wrote: > The WG meeting suggested two possible approaches. Outlawing the > pathological cases was one. The other was to leave behavior in the > pathological cases undefined ("garbage in, garbage out"). > > If there was any consensus on which of these approaches to take, it > was not immediately obvious to me, but judging that's the chairs' job. There was no consensus during the WG meeting. We'll have to see if we can reach consensus on the list. Just to make sure we do not stall on this question I propose that if there is no further discussion on the item we follow the recomendation of the design meeting i.e. outlawing the behavior. -- Olaf ---------------------------------| 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 Mar 29 04:19:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05631 for ; Tue, 29 Mar 2005 04:19:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGCpo-000A9N-Nl for namedroppers-data@psg.com; Tue, 29 Mar 2005 09:16:28 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DGCpn-000A9A-JA for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 09:16:27 +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 5080548F for ; Tue, 29 Mar 2005 04:16:26 -0500 (EST) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id A43FF41EA for ; Tue, 29 Mar 2005 04:16:25 -0500 (EST) Date: Tue, 29 Mar 2005 04:16:25 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis In-Reply-To: <20050329104305.296a5a8c.olaf@ripe.net> References: <20050326040756.85D7241E3@thrintun.hactrn.net> <20050329104305.296a5a8c.olaf@ripe.net> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050329091625.A43FF41EA@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 29 Mar 2005 10:43:05 +0200, Olaf Kolkman wrote: > > Just to make sure we do not stall on this question I propose that if > there is no further discussion on the item we follow the recomendation > of the design meeting i.e. outlawing the behavior. Sorry, but I have to stand in the way on this one. We are talking about pathologically broken data that never could have meant anything useful under the rules we have now. The design team proposed protocol changes (in particular, to DNSSEC) in order to nail down the uselessness of these pathological cases. This does not seem helpful. Don't we have enough whacky special cases yet? Do we really need to add still more special cases, change existing protocol and implmentation, spend years debugging this nonsense, all for the sake of having this form of pathologically broken data produce exactly the same useless and incomprehensible behavior in all implementations? Last time I checked, dividing by zero didn't work either. I propose that we just leave this broken stuff broken. The result of putting an NS or DNAME RR at a wildcard name is undefined. It might just sit there and drool. It might do something entertaining. It might cause the penguin on top of your telly to explode. It might spell the end of civilization as we know it. You know, "undefined". Garbage in, garbage out. -- 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 Mar 29 06:36:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17235 for ; Tue, 29 Mar 2005 06:36:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGExt-0000aU-W0 for namedroppers-data@psg.com; Tue, 29 Mar 2005 11:32:57 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGExU-0000Wa-05 for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 11:32:32 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id A9056E7EA5; Tue, 29 Mar 2005 12:32:30 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis In-Reply-To: <20050329091625.A43FF41EA@thrintun.hactrn.net> References: <20050326040756.85D7241E3@thrintun.hactrn.net> <20050329104305.296a5a8c.olaf@ripe.net> Message-Id: <20050329113230.A9056E7EA5@mx1.nominet.org.uk> Date: Tue, 29 Mar 2005 12:32:30 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austein writes: > I propose that we just leave this broken stuff broken. If so, would it be desirable to change -wcard-clarify (I'm guessing it would stay "-clarify") to explicitly state that the behaviour for "* DNAME" and "* NS" is undefined? I'm trying to see this from the viewpoint of an implementor, who may have difficulty reading between the lines of the current language. 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 Tue Mar 29 06:44:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17749 for ; Tue, 29 Mar 2005 06:44:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGF7V-0002Oo-W5 for namedroppers-data@psg.com; Tue, 29 Mar 2005 11:42:53 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGF7Q-0002O5-Hl for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 11:42:48 +0000 Received: from [192.168.2.4] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id A9B9FC2E00; Tue, 29 Mar 2005 12:42:47 +0100 (BST) Date: Tue, 29 Mar 2005 12:42:44 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Gustavo Lozano Ibarra , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: zone walking and random generated names Message-ID: In-Reply-To: <6.2.1.2.2.20050328185501.0b730538@mail.nic.mx> References: <6.2.1.2.2.20050328185501.0b730538@mail.nic.mx> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Maybe > I am missing something said in the last 10 years about random generated > names. I *think* what you are trying to say, is at signature time generate a number of RR's with random labels within the zone, and use these as boundary points for non-existence proofs. I may have misunderstood. I am taking it that the rnxd needs to have the next (random) domain in the record, so it is signed (and you cannot have a man in the middle attack). In this case, there is a walkable chain of random names which would seem to give nothing away. Each says merely "there is nothing between R1 and R2 except the label with the hash which comes along with the record". That's all fine and dandy until you realize that you need to put at least one "random" name between each existent name, as only one name can be carried in the hash. (Of course you can put more than one, and the intervals that contain no existing normal names can have a hash of something outside the interval itself). But I think this is not going to hide much of the zone. For instance, let's assume the zone has secret-sausage.co.uk secret-squirrel.co.uk secret-squirrel-incorporated.co.uk secret-squirrel-industries.co.uk secret-swizzle.co.uk then we'd have to generate something like: secret-sausage.co.uk secret-smsadg24g34gdsaf.co.uk rnxd secret-squirrel.co.uk secret-squirrel-a1423252fb.co.uk rnxd secret-squirrel-incorporated.co.uk secret-squirrel-incu41jhgah.co.uk rnxd secret-squirrel-industries.co.uk secret-srweadfaskdhjasd.co.uk rnxd secret-swizzle.co.uk All the records with rnxd are visible. So the attacker gets: secret-smsadg24g34gdsaf.co.uk rnxd secret-squirrel-a1423252fb.co.uk rnxd secret-squirrel-incu41jhgah.co.uk rnxd secret-srweadfaskdhjasd.co.uk rnxd Now I grant you we haven't got an exact enumeration there. However a little bit of analysis based on the distance between records will tell you how many letters you've got right. So if I've understood this correctly, I think it would work, but I don't see it as less disruption than NSEC3, but gives less "hiding". 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 Tue Mar 29 11:00:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12619 for ; Tue, 29 Mar 2005 11:00:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGJ5J-000FFE-4S for namedroppers-data@psg.com; Tue, 29 Mar 2005 15:56:53 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGJ5H-000FEj-Tv for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 15:56:52 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11471; Tue, 29 Mar 2005 10:56:49 -0500 (EST) Message-Id: <200503291556.KAA11471@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-tsig-sha-02.txt Date: Tue, 29 Mar 2005 10:56:49 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 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 : HMAC SHA TSIG Algorithm Identifiers Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-tsig-sha-02.txt Pages : 9 Date : 2005-3-28 Use of the TSIG DNS resource record requires specification of a cryptographic message authentication code. Currently identifiers have been specified only for the HMAC-MD5 and GSS TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-02.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-tsig-sha-02.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-tsig-sha-02.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: <2005-3-29112857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tsig-sha-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tsig-sha-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-29112857.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 Mar 29 11:00:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12707 for ; Tue, 29 Mar 2005 11:00:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGJ5x-000FLE-00 for namedroppers-data@psg.com; Tue, 29 Mar 2005 15:57:33 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGJ5v-000FKv-TT for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 15:57:32 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11697; Tue, 29 Mar 2005 10:57:28 -0500 (EST) Message-Id: <200503291557.KAA11697@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-rfc2539bis-dhk-05.txt Date: Tue, 29 Mar 2005 10:57:28 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 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 : Storage of Diffie-Hellman Keying Information in the DNS Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2539bis-dhk-05.txt Pages : 10 Date : 2005-3-28 The standard method for encoding Diffie-Hellman keys in the Domain Name System is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-05.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-rfc2539bis-dhk-05.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-rfc2539bis-dhk-05.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: <2005-3-29112910.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2539bis-dhk-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-29112910.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 Mar 29 11:00:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12740 for ; Tue, 29 Mar 2005 11:00:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGJ5A-000FE9-SJ for namedroppers-data@psg.com; Tue, 29 Mar 2005 15:56:44 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGJ58-000FDZ-24 for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 15:56:43 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11424; Tue, 29 Mar 2005 10:56:39 -0500 (EST) Message-Id: <200503291556.KAA11424@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-rfc2536bis-dsa-05.txt Date: Tue, 29 Mar 2005 10:56:39 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 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 : DSA Keying and Signature Information in the DNS Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2536bis-dsa-05.txt Pages : 8 Date : 2005-3-28 The standard method of encoding US Government Digital Signature Algorithm keying and signature information for use in the Domain Name System is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-05.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-rfc2536bis-dsa-05.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-rfc2536bis-dsa-05.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: <2005-3-29112851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2536bis-dsa-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-29112851.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 Mar 29 11:50:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12618 for ; Tue, 29 Mar 2005 11:00:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGJ5l-000FJf-1n for namedroppers-data@psg.com; Tue, 29 Mar 2005 15:57:21 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGJ5j-000FJM-MB for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 15:57:20 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11642; Tue, 29 Mar 2005 10:57:17 -0500 (EST) Message-Id: <200503291557.KAA11642@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-39.txt Date: Tue, 29 Mar 2005 10:57:17 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 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-39.txt Pages : 28 Date : 2005-3-28 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-39.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-39.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-39.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: <2005-3-29112903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-39.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-39.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-29112903.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 Mar 29 12:21:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03774 for ; Tue, 29 Mar 2005 12:21:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGKM3-00024l-Ck for namedroppers-data@psg.com; Tue, 29 Mar 2005 17:18:15 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DGKM1-00024L-H0 for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 17:18:13 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j2THI4KN008865; Tue, 29 Mar 2005 17:18:04 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j2THI3KY008862; Tue, 29 Mar 2005 17:18:03 GMT Date: Tue, 29 Mar 2005 17:18:03 +0000 From: bmanning@vacation.karoshi.com To: Geoffrey Sisson Cc: namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis Message-ID: <20050329171803.GB8425@vacation.karoshi.com.> References: <20050326040756.85D7241E3@thrintun.hactrn.net> <20050329104305.296a5a8c.olaf@ripe.net> <20050329113230.A9056E7EA5@mx1.nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329113230.A9056E7EA5@mx1.nominet.org.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Mar 29, 2005 at 12:32:30PM +0100, Geoffrey Sisson wrote: > Rob Austein writes: > > > I propose that we just leave this broken stuff broken. > > If so, would it be desirable to change -wcard-clarify (I'm guessing it > would stay "-clarify") to explicitly state that the behaviour for > "* DNAME" and "* NS" is undefined? I'm trying to see this from the > viewpoint of an implementor, who may have difficulty reading between > the lines of the current language. > > Geoff and unlike Rob, i'd like to see these things defined. defined as -undefined- (explicitly) at this time, or taking a crack at what should happen when these are seen in a zone. Leaving things underspecified is distasteful. --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 Tue Mar 29 12:39:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05450 for ; Tue, 29 Mar 2005 12:39:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGKea-0004YH-EQ for namedroppers-data@psg.com; Tue, 29 Mar 2005 17:37:24 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGKeX-0004Xq-EG for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 17:37:21 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 73768C2DA6; Tue, 29 Mar 2005 18:37:20 +0100 (BST) Date: Tue, 29 Mar 2005 18:37:17 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Rob Austein , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: wcard discussions in Minneapolis Message-ID: In-Reply-To: <20050329091625.A43FF41EA@thrintun.hactrn.net> References: <20050326040756.85D7241E3@thrintun.hactrn.net> <20050329104305.296a5a8c.olaf@ripe.net> <20050329091625.A43FF41EA@thrintun.hactrn.net> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 29 March 2005 04:16 -0500 Rob Austein wrote: > Garbage in, garbage out. But even so, at the very minimum isn't it necessary to define what is (and what isn't) garbage? Currently "* NS" is not so defined. And people have tried to use it. Assuming it is defined, is the choice between a) Use of {set of garbage things} is outlawed (which is what Olaf said) and b) Use of {set of garbage things} gives undefined behaviour Presumably the difference is that case (a) yields a predictable error, case (b) might do anything at all (including 'work' for some value of 'work'). If so, I think I prefer the former. 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 Tue Mar 29 12:58:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06950 for ; Tue, 29 Mar 2005 12:58:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGKx3-0007uS-FP for namedroppers-data@psg.com; Tue, 29 Mar 2005 17:56:29 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DGKx0-0007tR-Vu for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 17:56:27 +0000 Received: from [10.0.1.2] (c-24-6-153-109.client.comcast.net [24.6.153.109]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id C51695684B; Tue, 29 Mar 2005 09:56:25 -0800 (PST) (envelope-from david.conrad@nominum.com) In-Reply-To: References: <20050326040756.85D7241E3@thrintun.hactrn.net> <20050329104305.296a5a8c.olaf@ripe.net> <20050329091625.A43FF41EA@thrintun.hactrn.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Rob Austein , namedroppers@ops.ietf.org From: David Conrad Subject: Re: wcard discussions in Minneapolis Date: Tue, 29 Mar 2005 09:56:23 -0800 To: Alex Bligh X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Doing (a) in such a way that there is predictable behavior would likely imply redeployment of many DNS servers. Given full redeployment has proven essentially impossible for any significant deployment of any server (I still see fingerprints of BIND 4.8.3 on occasion and WinNT 4.0 DNS), I suspect the only viable option is (b). Rgds, -drc On Mar 29, 2005, at 9:37 AM, Alex Bligh wrote: > > > --On 29 March 2005 04:16 -0500 Rob Austein wrote: > >> Garbage in, garbage out. > > But even so, at the very minimum isn't it necessary to define what is > (and > what isn't) garbage? Currently "* NS" is not so defined. And people > have > tried to use it. > > Assuming it is defined, is the choice between > a) Use of {set of garbage things} is outlawed (which is what Olaf said) > and > b) Use of {set of garbage things} gives undefined behaviour > > Presumably the difference is that case (a) yields a predictable error, > case (b) might do anything at all (including 'work' for some value > of 'work'). If so, I think I prefer the former. > > 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 Tue Mar 29 13:07:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07869 for ; Tue, 29 Mar 2005 13:07:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGL5k-0009vH-I7 for namedroppers-data@psg.com; Tue, 29 Mar 2005 18:05:28 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DGL5g-0009ud-QA for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 18:05:25 +0000 Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1DGL5d-0007Jx-6A; Tue, 29 Mar 2005 20:05:21 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.50) id 1DGL5b-0003I0-OS; Tue, 29 Mar 2005 20:05:19 +0200 From: Florian Weimer To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-nsec3-01 References: Date: Tue, 29 Mar 2005 20:05:19 +0200 In-Reply-To: (Roy Arends's message of "Mon, 21 Feb 2005 11:19:36 +0100 (CET)") Message-ID: <87zmwmba5c.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Roy Arends: > I've just submitted draft-ietf-dnsext-nsec3-01 and am hereby solliciting > comments. In the Performance Considerations, you could mention that the hashed labels decrease performance of some access methods (e.g. B-trees) due to poor locality. I'm not sure if there are any relevant applications which are affected by this (mine doesn't qualify as relevant, and I don't plan to store NSEC3 records, either). -- 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 Mar 29 13:07:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07887 for ; Tue, 29 Mar 2005 13:07:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGL5u-0009wd-7y for namedroppers-data@psg.com; Tue, 29 Mar 2005 18:05:38 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGL5s-0009vq-7k for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 18:05:36 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 39AD1C2DA6; Tue, 29 Mar 2005 19:05:35 +0100 (BST) Date: Tue, 29 Mar 2005 19:05:31 +0100 From: Alex Bligh Reply-To: Alex Bligh To: David Conrad Cc: Rob Austein , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: wcard discussions in Minneapolis Message-ID: In-Reply-To: References: <20050326040756.85D7241E3@thrintun.hactrn.net> <20050329104305.296a5a8c.olaf@ripe.net> <20050329091625.A43FF41EA@thrintun.hactrn.net> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 29 March 2005 09:56 -0800 David Conrad wrote: > Doing (a) in such a way that there is predictable behavior would likely > imply redeployment of many DNS servers. Given full redeployment has > proven essentially impossible for any significant deployment of any > server (I still see fingerprints of BIND 4.8.3 on occasion and WinNT 4.0 > DNS), I suspect the only viable option is (b). OK so how about: {set of garbage things} is reserved, behaviour is undefined, but implementations SHOULD produce $error. 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 Tue Mar 29 13:20:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08828 for ; Tue, 29 Mar 2005 13:20:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGLI4-000COm-Bm for namedroppers-data@psg.com; Tue, 29 Mar 2005 18:18:12 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DGLI1-000CMy-9S for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 18:18:09 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j2TII6KN009118; Tue, 29 Mar 2005 18:18:06 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j2TII6Es009115; Tue, 29 Mar 2005 18:18:06 GMT Date: Tue, 29 Mar 2005 18:18:06 +0000 From: bmanning@vacation.karoshi.com To: Alex Bligh Cc: David Conrad , Rob Austein , namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis Message-ID: <20050329181806.GF8425@vacation.karoshi.com.> References: <20050326040756.85D7241E3@thrintun.hactrn.net> <20050329104305.296a5a8c.olaf@ripe.net> <20050329091625.A43FF41EA@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Mar 29, 2005 at 07:05:31PM +0100, Alex Bligh wrote: > --On 29 March 2005 09:56 -0800 David Conrad > wrote: > > >Doing (a) in such a way that there is predictable behavior would likely > >imply redeployment of many DNS servers. Given full redeployment has > >proven essentially impossible for any significant deployment of any > >server (I still see fingerprints of BIND 4.8.3 on occasion and WinNT 4.0 > >DNS), I suspect the only viable option is (b). > > OK so how about: {set of garbage things} is reserved, behaviour is > undefined, but implementations SHOULD produce $error. such a tactic will preclude doing anything useful with this in the future. would prefer something like: {set of things} is reserved, the behaviour of DNS components is undefined at this time. Implementations should produce $warning if {set of things} is encountered. --bill > > 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 Tue Mar 29 13:24:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09188 for ; Tue, 29 Mar 2005 13:24:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGLLm-000DfZ-O4 for namedroppers-data@psg.com; Tue, 29 Mar 2005 18:22:02 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DGLLk-000Dea-Ja for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 18:22:00 +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 81C92188 for ; Tue, 29 Mar 2005 13:21:59 -0500 (EST) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id DCBFF41EA for ; Tue, 29 Mar 2005 13:21:58 -0500 (EST) Date: Tue, 29 Mar 2005 13:21:58 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis In-Reply-To: <20050329113230.A9056E7EA5@mx1.nominet.org.uk> References: <20050326040756.85D7241E3@thrintun.hactrn.net> <20050329104305.296a5a8c.olaf@ripe.net> <20050329091625.A43FF41EA@thrintun.hactrn.net> <20050329113230.A9056E7EA5@mx1.nominet.org.uk> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050329182158.DCBFF41EA@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 29 Mar 2005 12:32:30 +0100 (BST), Geoffrey Sisson wrote: > > Rob Austein writes: > > > I propose that we just leave this broken stuff broken. > > If so, would it be desirable to change -wcard-clarify (I'm guessing it > would stay "-clarify") to explicitly state that the behaviour for > "* DNAME" and "* NS" is undefined? I'm trying to see this from the > viewpoint of an implementor, who may have difficulty reading between > the lines of the current language. Yes. To be clear (since apparently my previous message was not): - I have no problem with explictly documenting the behavior of these cases as undefined, and agree that it would be useful to do so. - What I object to is changing the specifications in ways that require implementation of new special handling rules. In particular, I object to the proposed changes to the DNSSEC signing algorithm. -- 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 Mar 29 13:28:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09626 for ; Tue, 29 Mar 2005 13:28:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGLPi-000ERw-H7 for namedroppers-data@psg.com; Tue, 29 Mar 2005 18:26:06 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DGLPe-000ERI-GH for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 18:26:02 +0000 Received: from zeder.TechFak.Uni-Bielefeld.DE (zeder.TechFak.Uni-Bielefeld.DE [129.70.128.80]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/03/01/sjaenick) with ESMTP id j2TIQ039010722 for ; Tue, 29 Mar 2005 20:26:00 +0200 (MEST) Received: from localhost (pk@localhost) by zeder.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j2TIQ0o03847 for ; Tue, 29 Mar 2005 20:26:00 +0200 (MEST) Message-Id: <200503291826.j2TIQ0o03847@zeder.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis In-reply-to: Your message of "Tue, 29 Mar 2005 19:05:31 BST." 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: <3842.1112120759.1@zeder.TechFak.Uni-Bielefeld.DE> Date: Tue, 29 Mar 2005 20:26:00 +0200 From: Peter Koch X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh wrote: > OK so how about: {set of garbage things} is reserved, behaviour is > undefined, but implementations SHOULD produce $error. as already mentioned during the meeting, this will lead to interoperability hassles, where the primary accepts but one of the slaves rejects. I'd prefer a solution which is consistent within the DNS. That's the one allowing * NS, but per corollary taking away the synthesis property per that very delegation (which was the result of the morning meeting). -Peter PS: Strange enough, in the hostcount data I've found quite a few '* NS', although I doubt they were the results of discussions anywhere near this. -- 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 Mar 29 14:00:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12618 for ; Tue, 29 Mar 2005 14:00:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGLuS-000JXa-TF for namedroppers-data@psg.com; Tue, 29 Mar 2005 18:57:52 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DGLuR-000JX1-Et for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 18:57:51 +0000 Received: from [10.31.32.83] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2TIvgm7003555; Tue, 29 Mar 2005 13:57:43 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200503291826.j2TIQ0o03847@zeder.TechFak.Uni-Bielefeld.DE> References: <200503291826.j2TIQ0o03847@zeder.TechFak.Uni-Bielefeld.DE> Date: Tue, 29 Mar 2005 13:57:25 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: wcard discussions in Minneapolis Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Speaking as the person who has to edit a response from all this... How about we document that there are inconsistencies in the definition of DNS which lead to unclear semantics when asterisk labels are delegation points or DNAME rewrite points. In the spirit of their being inconsistencies, i.e., no right and wrong, no best current practice, we declare that we are not going to delineate rules at this time. One reason for this is that there is a fear that if we outlaw behavior now, it will be unavailable to us in the future. While I have deep sympathy for this, I think the future for DNS as we know it has already been crimped by many forces. I think that we're past the point where we ought to be anticipating the unanticipatable. (No, it's not a word.) E.g., CNAME rewriting of queries in the authoritative server in RFC 1034 was the first ill advised crimp. (Did they forget CNAMEs in the infamous step 3 part c or was the omission intentional?) In a perfect world, we should be able to define a base behavior that accommodates future innovation via extension. We've already been in a phase where surgery is needed to the base (e.g. EDNS0) to accommodate new features (DNSSEC). I don't think we have a critical mass of understanding of just how wild cards and delegation points/rewrite points work profit anyone. We have heard of some use cases that are operationally abnormal (like a zone whose name is *.anydomain.) but fit within protocol guidelines. IMHO, it's arguments over such situations that endanger the IETF's relevance to operations. Think of how much time we've devoted to an example that no would do except to prove a point. It's like paying for lunch with US$2 bills. (You know who you are!) Yeah, they're legal tender in the US and, yes, the cash register makers don't give them a bay. I would say that now we just recognize and document the inconsistencies. I would say that when there is a clear way to iron out the wrinkles we do so, and no sooner. I would say that if we lose something by not defining this now, well, I don't think we will be losing much. There are bigger problems in DNS. Maybe the latter is my motivation of this answer: I'm getting to the point where I would like to wrap this document up and move on to cleaning up the IANA references or to some of the Proposed Standard documents that haven't made it to Draft Standard yet. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 29 15:35:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22487 for ; Tue, 29 Mar 2005 15:35:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGNLj-0008Cf-53 for namedroppers-data@psg.com; Tue, 29 Mar 2005 20:30:07 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGNLY-0008AZ-1x for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 20:29:56 +0000 Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 36052414ED; Tue, 29 Mar 2005 12:29:55 -0800 (PST) Subject: Re: wcard discussions in Minneapolis From: Douglas Otis To: Edward Lewis Cc: namedroppers@ops.ietf.org In-Reply-To: References: <200503291826.j2TIQ0o03847@zeder.TechFak.Uni-Bielefeld.DE> Content-Type: text/plain Date: Tue, 29 Mar 2005 12:29:25 -0800 Message-Id: <1112128165.6432.111.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2005-03-29 at 13:57 -0500, Edward Lewis wrote: > Speaking as the person who has to edit a response from all this... > > How about we document that there are inconsistencies in the > definition of DNS which lead to unclear semantics when asterisk > labels are delegation points or DNAME rewrite points. In the spirit > of their being inconsistencies, i.e., no right and wrong, no best > current practice, we declare that we are not going to delineate rules > at this time. Declaring such a cause for a warning or error, when there is no behavioral definition, reduces risks. -Doug -- 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 Mar 29 15:42:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23121 for ; Tue, 29 Mar 2005 15:42:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGNV3-0009jd-2p for namedroppers-data@psg.com; Tue, 29 Mar 2005 20:39:45 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGNV1-0009jK-DK for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 20:39:43 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) id <0IE400801RZF5500@cali.ucd.ie> (original mail from niall.oreilly@ucd.ie) for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 21:39:42 +0100 (IST) Received: from [10.0.1.189] ([83.141.81.52]) by cali.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) with ESMTPSA id <0IE400F6GS244KB0@cali.ucd.ie>; Tue, 29 Mar 2005 21:39:41 +0100 (IST) Date: Tue, 29 Mar 2005 21:39:45 +0100 From: "Niall O'Reilly" Subject: Re: Type Code 31 In-reply-to: To: Edward Lewis Cc: "Niall O'Reilly" , bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Message-id: <26e976e1a5d8ff84449cd2e8b5c90681@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20050327011156.GA21947@vacation.karoshi.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On 27 Mar 2005, at 05:51, Edward Lewis wrote: > On the one hand, having a historical record is good - what killed a > record is worth remembering. The historical record also protects against collision with instances which may be 'undead' and lurking in the wild. > On the other hand, let's not clutter up implementations with > unnecessary code paths. Indeed. /Niall -- 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 Mar 29 16:15:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25940 for ; Tue, 29 Mar 2005 16:15:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGO1S-000FX8-6Y for namedroppers-data@psg.com; Tue, 29 Mar 2005 21:13:14 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DGO1R-000FUf-92 for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 21:13:13 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EE33A13971 for ; Tue, 29 Mar 2005 21:13:12 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis In-Reply-To: Message from bmanning@vacation.karoshi.com of "Tue, 29 Mar 2005 17:18:03 GMT." <20050329171803.GB8425@vacation.karoshi.com.> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 29 Mar 2005 21:13:12 +0000 Message-Id: <20050329211312.EE33A13971@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bill wrote: > ..., i'd like to see these things defined. > defined as -undefined- (explicitly) at this time, or > taking a crack at what should happen when these are seen > in a zone. Leaving things underspecified is distasteful. ...and i agree. -- 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 Mar 29 16:37:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27974 for ; Tue, 29 Mar 2005 16:37:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGOM7-000IVP-Pa for namedroppers-data@psg.com; Tue, 29 Mar 2005 21:34:35 +0000 Received: from [200.23.30.77] (helo=mail.nic.mx) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGOM6-000IVB-CJ for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 21:34:34 +0000 Received: from localhost (localhost.nic.mx [127.0.0.1]) by mail.nic.mx (Postfix) with ESMTP id A3DD41816D1; Tue, 29 Mar 2005 15:34:33 -0600 (CST) Received: from mail.nic.mx ([127.0.0.1]) by localhost (mail.nic.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59063-07; Tue, 29 Mar 2005 15:34:33 -0600 (CST) Received: from glozano.mail.nic.mx (unknown [200.33.1.76]) by mail.nic.mx (Postfix) with ESMTP id 5CB46181681; Tue, 29 Mar 2005 15:34:33 -0600 (CST) Message-Id: <6.2.1.2.2.20050329152023.05a89ab0@mail.nic.mx> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 29 Mar 2005 15:34:32 -0600 To: Samuel Weiler From: Gustavo Lozano Ibarra Subject: Re: zone walking and random generated names Cc: namedroppers@ops.ietf.org In-Reply-To: References: <6.2.1.2.2.20050328185501.0b730538@mail.nic.mx> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new at nic.mx X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:56 AM 3/29/2005 -0500, Samuel Weiler wrote: >After spending some more time on this, it's starting to sink in (or, >at least, something is sinking in -- I hope it's what Gustavo >intended). This is a very interesting idea. Thank you very much for >sharing it with us. > >I'm going to try to explain this in different words. Please tell me >if I get it wrong. For the moment, I'm only going to look at how to >prove that a name doesn't exist at all, and I'm going to ignore how to >prove what RR types exist at a given name. I'm also going to ignore >what happens at the beginning and end of zones. I think the propsoal >is: > > Insert a new name between all existing names in the zone, thereby > breaking the zone up into spans that each contain EXACTLY one name, > no more, no less. Yes. An updated a draft will need to work the case when you have a name or more with immediate successors in a zone. > At these new names, build an NSEC (or RNXD) chain containing JUST > the random names. (Original names don't get NSECs.) These new > NSECs (RNXDs) prove that there is exactly one name between the > endpoints of the NSEC. Add to the NSEC (RNXD) RR the hash of the > ONE original name contained in that span. > >Looking at an example used earlier in this thread (and stealing some >text from the draft): > > > The zone example.com. has the following data: > > > > b.example.com. A 10.10.10.10 > > e.example.com. A 10.10.10.11 >... > > Using random NSEC you will create random names between each existing > > domain: a.example.com. and d.example.com. for example. > >This leaves a zone of: > > a.example (random generated) > b.example (original) > c.example (random generated) > e.example (original) > f.example (random generated) > >Or, more specifically: > > a.example NSEC c.example hashof(b.example) > b.example A 10.10.10.10 > c.example NSEC f.example hashof(e.example) > e.example A 10.10.10.11 > f.example NSEC something hashof(something) > >Along with appropriate RRSIGs and zone apex RRs and such. > >When faced with a query for (the non-existant) d.example.com, the >server returns the c.example NSEC (or RNXD). What does the resolver >do? > > The resolver sees that the returned NSEC proves that only one name > exists between c and f. It then hashes the QNAME and compares the > hash to the hash in the NSEC. They don't match, so this QNAME must > not be the one name in this span. Thus, the QNAME does not exist. > > If hash(QNAME) had matched the hash in the NSEC, then this NSEC > would prove that the QNAME does exist. If hash(QNAME) had matched the hash in the NSEC and the server sent this NSEC as response, this will indicate a problem with the DNS implementation or a MTM. > And if the plaintext QNAME had, perchance, matched either of the > endpoints of the NSEC RR, then the name would (ironically) have > been proven to not exist, since NSEC RRs are only inserted where > there are not already existing names. > >The proposal suggests a second RR type at each existing name to list >the RR types at that name. I think that the NSEC/RNXD RR could still >do that -- it just lists the types present at the hashed name. >Presumably the NSEC/RNXD would also need to list the hash parameters >used (just like the NSEC2/3/++ proposals). This would lead to really >long NSEC RR's, but no extra RRs. For example: > > a.example NSEC c.example hashof(b.example) ( A RRSIG ) hash-param > b.example A 10.10.10.10 > c.example NSEC f.example hashof(e.example) ( A RRSIG ) hash-param > e.example A 10.10.10.11 > f.example NSEC something hashof(something) ( types ) The problem with using only one RR for denial of names and RR is when you think about the case when you have a name or more with immediate successors in a zone. I was thinking of having one or more RNXDs per span for this case. >This proposal, if I've understood it correctly, seems to have some >interesting potential. It trivially allows for different hash >parameters at each span, facilitating hash algorithm and parameter >changes. We'd need to work out the beginning- and end-of-zone >details, but that seems easy. It's not clear how it would work with >wildcard proofs (empty non-terminals, anyone?) -- that could be >harder. It avoids the potential "recursion" problem in the NSEC++ >proposals, where one NSEC++ proves that another one doesn't exist. > >This proposal exposes more about the zone than the NSEC++ proposals: >they only allow counting of the zone and relative numbers of RR types >present, whereas this exposes some information about the lexical >distribution of names. One could limit the exposure of information by >inserting extra random names in the NSEC/RNXD chain -- in the newly >created spans where no real name exists, use the hash of some name >outside of that span and a synthesized type bitmap. > >I'm assuming that, other than for some wildcard proofs, a resolver >always knows or can easily infer which names it needs to prove the >non-existence of, so it knows what value to look for in the hash, but >I'm not sure if that's actually true or not. > >In any case, thanks again to Gustavo for sharing this idea. Thank you. I will write an updated draft to better explore this idea. >-- 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 Mar 29 16:54:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29537 for ; Tue, 29 Mar 2005 16:54:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGOdU-000KqE-4Q for namedroppers-data@psg.com; Tue, 29 Mar 2005 21:52:32 +0000 Received: from [200.23.30.77] (helo=mail.nic.mx) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGOdS-000Kp0-Eu for namedroppers@ops.ietf.org; Tue, 29 Mar 2005 21:52:30 +0000 Received: from localhost (localhost.nic.mx [127.0.0.1]) by mail.nic.mx (Postfix) with ESMTP id 0427A181705; Tue, 29 Mar 2005 15:52:30 -0600 (CST) Received: from mail.nic.mx ([127.0.0.1]) by localhost (mail.nic.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63283-02; Tue, 29 Mar 2005 15:52:29 -0600 (CST) Received: from glozano.mail.nic.mx (unknown [200.33.1.76]) by mail.nic.mx (Postfix) with ESMTP id 9EA9A181703; Tue, 29 Mar 2005 15:52:29 -0600 (CST) Message-Id: <6.2.1.2.2.20050329153522.05aaf710@mail.nic.mx> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 29 Mar 2005 15:52:29 -0600 To: Alex Bligh , namedroppers@ops.ietf.org From: Gustavo Lozano Ibarra Subject: Re: zone walking and random generated names Cc: Alex Bligh In-Reply-To: References: <6.2.1.2.2.20050328185501.0b730538@mail.nic.mx> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new at nic.mx X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:42 PM 3/29/2005 +0100, Alex Bligh wrote: >>Maybe >>I am missing something said in the last 10 years about random generated >>names. > >I *think* what you are trying to say, is at signature time generate >a number of RR's with random labels within the zone, and use these >as boundary points for non-existence proofs. I may have misunderstood. > >I am taking it that the rnxd needs to have the next (random) domain >in the record, so it is signed (and you cannot have a man in the middle >attack). In this case, there is a walkable chain of random names which >would seem to give nothing away. Each says merely "there is nothing >between R1 and R2 except the label with the hash which comes along >with the record". Correct. >That's all fine and dandy until you realize that you need to put >at least one "random" name between each existent name, as only one >name can be carried in the hash. (Of course you can put more than >one, and the intervals that contain no existing normal names can >have a hash of something outside the interval itself). > >But I think this is not going to hide much of the zone. > >For instance, let's assume the zone has > secret-sausage.co.uk > secret-squirrel.co.uk > secret-squirrel-incorporated.co.uk > secret-squirrel-industries.co.uk > secret-swizzle.co.uk > >then we'd have to generate something like: > secret-sausage.co.uk > secret-smsadg24g34gdsaf.co.uk rnxd > secret-squirrel.co.uk > secret-squirrel-a1423252fb.co.uk rnxd > secret-squirrel-incorporated.co.uk > secret-squirrel-incu41jhgah.co.uk rnxd > secret-squirrel-industries.co.uk > secret-srweadfaskdhjasd.co.uk rnxd > secret-swizzle.co.uk > >All the records with rnxd are visible. So the attacker gets: > secret-smsadg24g34gdsaf.co.uk rnxd > secret-squirrel-a1423252fb.co.uk rnxd > secret-squirrel-incu41jhgah.co.uk rnxd > secret-srweadfaskdhjasd.co.uk rnxd > >Now I grant you we haven't got an exact enumeration there. However >a little bit of analysis based on the distance between records will >tell you how many letters you've got right. Correct. In the actual DNS your minimum universe of search is a tree of 64 levels with [a-z],[0-9],- possibilities per level. Random generated names can cut the universe to subtrees per span and citing the secret-squirrel example you will be able to prone the subtree. You can also use a dictionary, yellow pages... in the actual DNS and obtain a great amount of the names in a zone. I think random generated names have a good level of security and a resolver is able to do a double check for the integrity of the response: the name that was denied is between the boundaries of the span and the signature of the RNXD RR itself. >So if I've understood this correctly, I think it would work, but >I don't see it as less disruption than NSEC3, but gives less >"hiding". I will write an updated draft taking in consideration your feedback. I think we need to have more choices for the zone enumeration problem. Thank you. >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 Tue Mar 29 23:00:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02283 for ; Tue, 29 Mar 2005 23:00:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGUIp-000GNd-VU for namedroppers-data@psg.com; Wed, 30 Mar 2005 03:55:35 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGUIm-000GLk-Nf for namedroppers@ops.ietf.org; Wed, 30 Mar 2005 03:55:32 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2U3sUq18035; Tue, 29 Mar 2005 19:54:30 -0800 (PST) Message-Id: <200503300354.j2U3sUq18035@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4033 on DNS Security Introduction and Requirements Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 29 Mar 2005 19:54:30 -0800 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4033 Title: DNS Security Introduction and Requirements Author(s): R. Arends, R. Austein, M. Larson, D. Massey, S. Rose Status: Standards Track Date: March 2005 Mailbox: roy.arends@telin.nl, sra@isc.org, mlarson@verisign.com, massey@cs.colostate.edu, scott.rose@nist.gov Pages: 21 Characters: 52445 Updates: 1034, 1035, 2136, 2181, 2308, 3225, 3007, 3597, 3226 Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, 3755, 3757, 3845 I-D Tag: draft-ietf-dnsext-dnssec-intro-13.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4033.txt 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 documents that collectively describe DNSSEC. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050329195315.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4033 --OtherAccess Content-Type: Message/External-body; name="rfc4033.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050329195315.RFC@RFC-EDITOR.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 Mar 29 23:00:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02314 for ; Tue, 29 Mar 2005 23:00:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGULg-000GmG-S4 for namedroppers-data@psg.com; Wed, 30 Mar 2005 03:58:32 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGULf-000Glz-Qa for namedroppers@ops.ietf.org; Wed, 30 Mar 2005 03:58:31 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2U3viq19555; Tue, 29 Mar 2005 19:57:44 -0800 (PST) Message-Id: <200503300357.j2U3viq19555@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4035 on Protocol Modifications for the DNS Security Extensions Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 29 Mar 2005 19:57:44 -0800 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4035 Title: Protocol Modifications for the DNS Security Extensions Author(s): R. Arends, R. Austein, M. Larson, D. Massey, S. Rose Status: Standards Track Date: March 2005 Mailbox: roy.arends@telin.nl, sra@isc.org, mlarson@verisign.com, massey@cs.colostate.edu, scott.rose@nist.gov Pages: 53 Characters: 130589 Updates: 1034, 1035, 2136, 2181, 2308, 3225, 3007, 3597, 3226 Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, 3755, 3757, 3845 I-D Tag: draft-ietf-dnsext-dnssec-protocol-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4035.txt This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that 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 by 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. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050329195612.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4035 --OtherAccess Content-Type: Message/External-body; name="rfc4035.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050329195612.RFC@RFC-EDITOR.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 Mar 29 23:00:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02383 for ; Tue, 29 Mar 2005 23:00:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGUJx-000GWj-Ig for namedroppers-data@psg.com; Wed, 30 Mar 2005 03:56:45 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGUJw-000GWS-Gp for namedroppers@ops.ietf.org; Wed, 30 Mar 2005 03:56:44 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2U3u5q18431; Tue, 29 Mar 2005 19:56:05 -0800 (PST) Message-Id: <200503300356.j2U3u5q18431@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4034 on Resource Records for the DNS Security Extensions Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 29 Mar 2005 19:56:05 -0800 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4034 Title: Resource Records for the DNS Security Extensions Author(s): R. Arends, R. Austein, M. Larson, D. Massey, S. Rose Status: Standards Track Date: March 2005 Mailbox: roy.arends@telin.nl, sra@isc.org, mlarson@verisign.com, massey@cs.colostate.edu, scott.rose@nist.gov Pages: 29 Characters: 63879 Updates: 1034, 1035, 2136, 2181, 2308, 3225, 3007, 3597, 3226 Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, 3755, 3757, 3845 I-D Tag: draft-ietf-dnsext-dnssec-records-11.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4034.txt This document is part of a family of documents that describe 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. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050329195438.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4034 --OtherAccess Content-Type: Message/External-body; name="rfc4034.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050329195438.RFC@RFC-EDITOR.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 Wed Mar 30 00:25:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10897 for ; Wed, 30 Mar 2005 00:25:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGVeG-00027S-9x for namedroppers-data@psg.com; Wed, 30 Mar 2005 05:21:48 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DGVeE-00026e-63 for namedroppers@ops.ietf.org; Wed, 30 Mar 2005 05:21:46 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 886EC33C45; Wed, 30 Mar 2005 06:21:42 +0100 (BST) Message-ID: <424A36EC.6070107@algroup.co.uk> Date: Wed, 30 Mar 2005 06:19:40 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian Weimer Cc: Roy Arends , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-nsec3-01 References: <87zmwmba5c.fsf@deneb.enyo.de> In-Reply-To: <87zmwmba5c.fsf@deneb.enyo.de> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Florian Weimer wrote: > * Roy Arends: > > >>I've just submitted draft-ietf-dnsext-nsec3-01 and am hereby solliciting >>comments. > > > In the Performance Considerations, you could mention that the hashed > labels decrease performance of some access methods (e.g. B-trees) due > to poor locality. ? I don't understand this comment - B-trees shouldn't be affected by the distribution of the data (not entirely sure what you mean by "locality" in this context, though). -- 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 Wed Mar 30 01:36:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17089 for ; Wed, 30 Mar 2005 01:36:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGWlS-000Apk-R7 for namedroppers-data@psg.com; Wed, 30 Mar 2005 06:33:18 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGWlP-000AoL-Jv for namedroppers@ops.ietf.org; Wed, 30 Mar 2005 06:33:15 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2U6TYij027419 for ; Wed, 30 Mar 2005 01:29:34 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAkia4I1; Wed, 30 Mar 05 01:29:32 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j2U6VCLA007599; Wed, 30 Mar 2005 01:31:12 -0500 (EST) Date: Wed, 30 Mar 2005 01:31:12 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Ben Laurie cc: Florian Weimer , Roy Arends , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-nsec3-01 In-Reply-To: <424A36EC.6070107@algroup.co.uk> Message-ID: References: <87zmwmba5c.fsf@deneb.enyo.de> <424A36EC.6070107@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 30 Mar 2005, Ben Laurie wrote: > > In the Performance Considerations, you could mention that the hashed > > labels decrease performance of some access methods (e.g. B-trees) due > > to poor locality. > > ? I don't understand this comment - B-trees shouldn't be affected by the > distribution of the data (not entirely sure what you mean by "locality" > in this context, though). Presumably: when answering a query for a non-existing name, an authoritative server must first look for the exact match, then for the span containing the hash of the QNAME. With NSEC-classic, the QNAME and the NSEC covering it can be found remarkably close to one another in the sorted zone. When using a B-tree keyed on the name, presumably the search for the closest predecessor is shorter than starting over at the root at the tree. With NSEC3, the QNAME and the NSEC3 covering hash(QNAME) are generally not adjacent in the sorted zone, so a server storing the zone as a B-tree would need to do two full searches. This doesn't seem like a big deal to me, but I just spent the afternoon hanging around with academic cryptographer types who were dismissing 3-10x growth in message size and computational load as "Oh, it's just some constant factor". -- 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 Mar 30 03:49:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02200 for ; Wed, 30 Mar 2005 03:49:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGYp4-0002Gs-Fs for namedroppers-data@psg.com; Wed, 30 Mar 2005 08:45:10 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGYp1-0002GW-EK for namedroppers@ops.ietf.org; Wed, 30 Mar 2005 08:45:07 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 8396F25D97; Wed, 30 Mar 2005 10:45:06 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 9BD6C25D96; Wed, 30 Mar 2005 10:45:03 +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 j2U8j3et001189; Wed, 30 Mar 2005 10:45:03 +0200 Date: Wed, 30 Mar 2005 10:45:03 +0200 From: "Olaf M. Kolkman" To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis Message-Id: <20050330104503.35033402.olaf@ripe.net> In-Reply-To: References: <200503291826.j2TIQ0o03847@zeder.TechFak.Uni-Bielefeld.DE> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (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-Tests: ALL_TRUSTED,BAYES_00,BIZ_TLD X-RIPE-Spam-Status: U 0.250951 / -3.6 X-RIPE-Signature: 02ca1486fb44ce71e38b3777d759dc6a X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 29 Mar 2005 13:57:25 -0500 Edward Lewis wrote: > Speaking as the person who has to edit a response from all this... > > How about we document that there are inconsistencies in the > definition of DNS which lead to unclear semantics when asterisk > labels are delegation points or DNAME rewrite points. In the spirit > of their being inconsistencies, i.e., no right and wrong, no best > current practice, we declare that we are not going to delineate rules > at this time. Sounds like a fair approach to me. Anybody not agreeing raise your voices. --Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org -- 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 Mar 30 04:18:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04234 for ; Wed, 30 Mar 2005 04:18:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGZJK-0006O9-9R for namedroppers-data@psg.com; Wed, 30 Mar 2005 09:16:26 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGZJJ-0006Nw-4j for namedroppers@ops.ietf.org; Wed, 30 Mar 2005 09:16:25 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 1AB5BC2DA5; Wed, 30 Mar 2005 10:16:24 +0100 (BST) Date: Wed, 30 Mar 2005 10:16:20 +0100 From: Alex Bligh Reply-To: Alex Bligh To: namedroppers@ops.ietf.org Cc: Alex Bligh Subject: nsec3-01 hash truncation for protocol (not crypto) reasons Message-ID: <8569BB53C35F7BC49A8EDBF9@[192.168.100.25]> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm going to risk the disapprobation of our esteemed chairs, and talk about hash truncation. But *NOT* for reasons to do with crypto, for simple protocol reasons (so I hope I can get away with it). I think without hash truncation, "long" names just won't work. For instance, if a "long" (for just about any value of long) hash is used untruncated (which would seem a good thing) it might be (assuming Base-32, SHA-224) 45 octets long. But the maximum DNS name length is (IIRC) 254 octets. So if I have (say) $ORIGIN {20octets}.{63octets}.{63octets}.\ {63octets}.example.com. www IN A 1.1.1.1 then the total length of the NSEC3 label would be an illegal 225+45=270 octets. It seems to me the best solution here is to allow truncated hashes, and make it a rule that the zone signer never constructs NSEC3 records of illegal length. Here (and apologies for fence-post errors and lack of caffeine) there are (about) 16 octets worth of space, which in Base-32 gives a (reasonable) 80 bits worth of hashing. If one allows hash truncation to a signer-definable number of Base-32 octets (think "string truncation"), then one clearly has at least as many characters to play with as the longest label within the zone. This will be provably sufficient even for dense zones if they only use 32 symbols. If they use more, we still run into problems. For instance, consider a zone the parent of which is so long that the longest label can only be a single character. Simply put, there are only 32 possible hash values (as we use Base-32), but there are at least 38 possible labels (for the purist, 256 possible labels). This implies that if NSEC3 is to be able to sign ALL zones (and a fallback to NSEC2 is never required), we are also going to HAVE to implement an identity hash (not for crypto reasons, for protocol reasons). So in such a zone with 38 labels (that's [a-z0-9\*-]), one cannot generate an NSEC3 chain at all, even with truncated hash functions. I would suggest we recommend that NSEC3s for parent zones in excess of (say) 250 octets SHOULD be created with the identity hash anyway. This of course means they are enumerable. A corner case I know, but we might as well get it right. 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 Wed Mar 30 04:33:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04892 for ; Wed, 30 Mar 2005 04:33:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGZXx-0007uy-Sx for namedroppers-data@psg.com; Wed, 30 Mar 2005 09:31:33 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DGZXm-0007uB-Jc for namedroppers@ops.ietf.org; Wed, 30 Mar 2005 09:31:22 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id B6E3C33C45; Wed, 30 Mar 2005 10:31:20 +0100 (BST) Message-ID: <424A716E.9000205@algroup.co.uk> Date: Wed, 30 Mar 2005 10:29:18 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh Cc: namedroppers@ops.ietf.org Subject: Re: nsec3-01 hash truncation for protocol (not crypto) reasons References: <8569BB53C35F7BC49A8EDBF9@[192.168.100.25]> In-Reply-To: <8569BB53C35F7BC49A8EDBF9@[192.168.100.25]> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > I'm going to risk the disapprobation of our esteemed chairs, and talk > about hash truncation. But *NOT* for reasons to do with crypto, for > simple protocol reasons (so I hope I can get away with it). We intend to allow for truncation in the next iteration of the NSEC3 I-D. 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 Wed Mar 30 04:39:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05398 for ; Wed, 30 Mar 2005 04:39:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGZda-0008ho-U6 for namedroppers-data@psg.com; Wed, 30 Mar 2005 09:37:22 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DGZdQ-0008dN-40 for namedroppers@ops.ietf.org; Wed, 30 Mar 2005 09:37:12 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id D533B33C45; Wed, 30 Mar 2005 10:37:08 +0100 (BST) Message-ID: <424A72CA.2030106@algroup.co.uk> Date: Wed, 30 Mar 2005 10:35:06 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samuel Weiler Cc: Florian Weimer , Roy Arends , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-nsec3-01 References: <87zmwmba5c.fsf@deneb.enyo.de> <424A36EC.6070107@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler wrote: > On Wed, 30 Mar 2005, Ben Laurie wrote: > > >>>In the Performance Considerations, you could mention that the hashed >>>labels decrease performance of some access methods (e.g. B-trees) due >>>to poor locality. >> >>? I don't understand this comment - B-trees shouldn't be affected by the >>distribution of the data (not entirely sure what you mean by "locality" >>in this context, though). > > > Presumably: when answering a query for a non-existing name, an > authoritative server must first look for the exact match, then for the > span containing the hash of the QNAME. With NSEC-classic, the QNAME > and the NSEC covering it can be found remarkably close to one another > in the sorted zone. When using a B-tree keyed on the name, presumably > the search for the closest predecessor is shorter than starting over > at the root at the tree. > > With NSEC3, the QNAME and the NSEC3 covering hash(QNAME) are generally > not adjacent in the sorted zone, so a server storing the zone as a > B-tree would need to do two full searches. Obviously if one is going to search by the hash, then one would construct an index using the hash, which would be around as efficient as an index of names (at least, it would be using B-trees). 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 Wed Mar 30 07:54:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23296 for ; Wed, 30 Mar 2005 07:54:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGcea-000BHo-4I for namedroppers-data@psg.com; Wed, 30 Mar 2005 12:50:36 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DGceX-000BHL-4R for namedroppers@ops.ietf.org; Wed, 30 Mar 2005 12:50:33 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j2UCoVKN013559; Wed, 30 Mar 2005 12:50:31 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j2UCoU60013556; Wed, 30 Mar 2005 12:50:30 GMT Date: Wed, 30 Mar 2005 12:50:30 +0000 From: bmanning@vacation.karoshi.com To: "Olaf M. Kolkman" Cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis Message-ID: <20050330125030.GA13516@vacation.karoshi.com.> References: <200503291826.j2TIQ0o03847@zeder.TechFak.Uni-Bielefeld.DE> <20050330104503.35033402.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050330104503.35033402.olaf@ripe.net> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Mar 30, 2005 at 10:45:03AM +0200, Olaf M. Kolkman wrote: > > > On Tue, 29 Mar 2005 13:57:25 -0500 > Edward Lewis wrote: > > > Speaking as the person who has to edit a response from all this... > > > > How about we document that there are inconsistencies in the > > definition of DNS which lead to unclear semantics when asterisk > > labels are delegation points or DNAME rewrite points. In the spirit > > of their being inconsistencies, i.e., no right and wrong, no best > > current practice, we declare that we are not going to delineate rules > > at this time. > > Sounds like a fair approach to me. Anybody not agreeing raise your voices. > > --Olaf i like the words and intent. --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 Mar 30 10:41:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10068 for ; Wed, 30 Mar 2005 10:41:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGfFv-00092E-EX for namedroppers-data@psg.com; Wed, 30 Mar 2005 15:37:19 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGfFt-000910-5X for namedroppers@ops.ietf.org; Wed, 30 Mar 2005 15:37:17 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 1E944C2DA5; Wed, 30 Mar 2005 16:37:16 +0100 (BST) Date: Wed, 30 Mar 2005 16:37:08 +0100 From: Alex Bligh Reply-To: Alex Bligh To: namedroppers@ops.ietf.org Cc: Alex Bligh Subject: NSEC3-01 - more wildcard nits Message-ID: X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think this has been brought up before, but not made the draft. Imagine a zone $ORIGIN example.com. example.com. IN SOA ... IN NS ... IN NS ... www IN A 1.2.3.4 * IN MX 2.3.4.5 H(www.example.com.) IN NSEC3 ... H(example.com.) A RRSIG H(example.com.) IN NSEC3 ... H(*.example.com.) SOA NS RRSIG H(*.example.com) IN NSEC3 ... H(www.example.com.) MX RRSIG I'm using H(blah) to indicate the hash of "blah". Now, under RFC403[345] (DNSSEC-bis), a query with QTYPE=MX returns an MX of 2.3.4.5 for all QNAME queries other than "www.example.com". With NSEC3 that is nearly true. The exception (as currently written) is if the query happens to be one of the hashes of the name, e.g. H(www.example.com.), H(example.com.), H(*.example.com). These will retain empty data. That's because the draft should (but as far as I can see does not) modify the search algorithm such that NSEC3 records are ignored for all searches other than QTYPE=NSEC3. 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 Wed Mar 30 21:57:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27830 for ; Wed, 30 Mar 2005 21:57:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGplZ-000Chr-8q for namedroppers-data@psg.com; Thu, 31 Mar 2005 02:50:41 +0000 Received: from [208.218.130.13] (helo=gis.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGplX-000ChN-8V for namedroppers@ops.ietf.org; Thu, 31 Mar 2005 02:50:39 +0000 Received: from tecotoo.localhost ([207.7.201.254]) by mx05.gis.net; Wed, 30 Mar 2005 21:50:35 -0500 Received: from tecotoo (tecotoo [127.0.0.1]) by tecotoo.localhost (NTMail 3.03.0017/1.aaaa) with ESMTP id oa001392 for ; Wed, 30 Mar 2005 21:25:39 +0000 Message-Id: <4.3.1.2.20050330212328.03cc9ae8@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 30 Mar 2005 21:25:27 -0500 To: Alex Bligh , namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: NSEC3-01 - more wildcard nits Cc: Alex Bligh In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:37 AM 3/30/2005, Alex Bligh wrote: >I think this has been brought up before, but not made the draft. > >Imagine a zone > >$ORIGIN example.com. >example.com. IN SOA ... > IN NS ... > IN NS ... >www IN A 1.2.3.4 >* IN MX 2.3.4.5 >H(www.example.com.) IN NSEC3 ... H(example.com.) A RRSIG >H(example.com.) IN NSEC3 ... H(*.example.com.) SOA NS RRSIG >H(*.example.com) IN NSEC3 ... H(www.example.com.) MX RRSIG I assume you were tired when you wrote this. I think you really meant to write: $ORIGIN example.com. example.com. IN SOA ... IN NS ... IN NS ... www IN A 1.2.3.4 * IN MX 10 mail mail IN A 2.3.4.5 H(www.example.com.) IN NSEC3 ... H(example.com.) A RRSIG H(example.com.) IN NSEC3 ... H(*.example.com.) SOA NS RRSIG H(*.example.com) IN NSEC3 ... H(www.example.com.) MX RRSIG Danny -- 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 Mar 31 03:17:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16945 for ; Thu, 31 Mar 2005 03:17:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGunr-0000hf-8v for namedroppers-data@psg.com; Thu, 31 Mar 2005 08:13:23 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGuno-0000fy-4R for namedroppers@ops.ietf.org; Thu, 31 Mar 2005 08:13:20 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 1FFEFC2DA4; Thu, 31 Mar 2005 09:13:19 +0100 (BST) Date: Thu, 31 Mar 2005 09:13:14 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Danny Mayer , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: NSEC3-01 - more wildcard nits Message-ID: In-Reply-To: <4.3.1.2.20050330212328.03cc9ae8@pop.gis.net> References: <4.3.1.2.20050330212328.03cc9ae8@pop.gis.net> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 30 March 2005 21:25 -0500 Danny Mayer wrote: > I assume you were tired when you wrote this. I think you really meant to Mea culpa, several people pointed this out. My excuse is that the wildcard was against an A record until the minute before I sent it when I thought "a wildcard MX would be more realistic". But let's get it right completely for the records: $ORIGIN example.com. example.com. IN SOA ... IN NS ... IN NS ... www IN A 1.2.3.4 * IN MX 10 mail.example2.com. mail IN A 2.3.4.5 H(www.example.com.) IN NSEC3 ... H(example.com.) A RRSIG H(example.com.) IN NSEC3 ... H(*.example.com.) SOA NS RRSIG H(*.example.com) IN NSEC3 ... H(www.example.com.) MX RRSIG However, I think the point about querying QTYPE=MX, QNAME=H(www.example.com) still holds. 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 Mar 31 04:37:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26295 for ; Thu, 31 Mar 2005 04:37:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGw4k-000Azi-GY for namedroppers-data@psg.com; Thu, 31 Mar 2005 09:34:54 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGw4h-000AzM-CA for namedroppers@ops.ietf.org; Thu, 31 Mar 2005 09:34:51 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id CF2D8266A4; Thu, 31 Mar 2005 11:34:50 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id E699F266A0; Thu, 31 Mar 2005 11:34:47 +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 j2V9Ylet021240; Thu, 31 Mar 2005 11:34:47 +0200 Date: Thu, 31 Mar 2005 11:34:47 +0200 From: "Olaf M. Kolkman" To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Draft DNSEXT @ IETF62 Minutes Message-Id: <20050331113447.61ca5fe3.olaf@ripe.net> In-Reply-To: References: <20050321120518.7b0dd87a.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (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-Tests: ALL_TRUSTED,BAYES_00,BIZ_TLD X-RIPE-Spam-Status: N 0.040265 / -3.6 X-RIPE-Signature: d2b6912eb7a2ca3bbec6c0bbb89facd4 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 25 Mar 2005 15:14:56 -0500 Edward Lewis wrote: > Mostly to clean up characters in the WCard > discussion, just one rewrite for clarity. (Put > my suggested replacement paragraph after the > original for cut and paste ease.) I did the cleanup and as far as I remember your suggested rewrite reflects what was said in the meeting. So in its context this would read: Lars Liman: What you're looking at is an NS record in the parent zone, and you are worrying about the signature of that, but it is not going to be signed in the parent zone. If you ask the parent server for a deleg NS, are you supposed to get an answer, or a referral? Ed Lewis: If you look at the algorithm, there are three parts: (a) a direct match, (b) a delegation point, and (c) a closest encloser., where I answer with a wildcard or no wildcard. When I come down I don't see the cut point, it is not on my search point, so B doesn't work. The reason that the "* NS" does not result in a referral message when seeking "a.example. NS" is this. Following the 4.3.2 algorithm, I would fall into part C, which is the part in which my last matching label is at the closest encloser, so I am in a "wildcard or not situation." Referrals are in part B, but I didn't enter there. Rob Austein: You are going to have to have a case in the ordinary processing for the authoritative nameserver "I know what is supposed to be in the zone but it wasn't there". As far as I can tell this covers this mess. It is general purpose error processing. I don't see why we need a special case. If no further modifications/objectsions I submit these minutes tomorrow. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org -- 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 Mar 31 09:43:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26992 for ; Thu, 31 Mar 2005 09:43:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DH0pa-0006UY-GO for namedroppers-data@psg.com; Thu, 31 Mar 2005 14:39:34 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DH0pJ-0006TF-Ch for namedroppers@ops.ietf.org; Thu, 31 Mar 2005 14:39:17 +0000 Received: from thangorodrim.hactrn.net (h-67-102-148-208.mclnva23.covad.net [67.102.148.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 659466C5 for ; Thu, 31 Mar 2005 09:39:15 -0500 (EST) Received: from thangorodrim.hactrn.net (localhost [IPv6:::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 92AF6AA for ; Thu, 31 Mar 2005 14:37:16 +0000 (UTC) Date: Thu, 31 Mar 2005 09:37:16 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis In-Reply-To: References: <200503291826.j2TIQ0o03847@zeder.TechFak.Uni-Bielefeld.DE> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050331143716.92AF6AA@thangorodrim.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 29 Mar 2005 13:57:25 -0500, Edward Lewis wrote: > > How about we document that there are inconsistencies in the > definition of DNS which lead to unclear semantics when asterisk > labels are delegation points or DNAME rewrite points. In the spirit > of their being inconsistencies, i.e., no right and wrong, no best > current practice, we declare that we are not going to delineate rules > at this time. Ok with me. -- 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 Mar 31 16:13:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10608 for ; Thu, 31 Mar 2005 16:13:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DH6uV-000JMD-Cf for namedroppers-data@psg.com; Thu, 31 Mar 2005 21:09:03 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DH6uE-000JK0-3L for namedroppers@ops.ietf.org; Thu, 31 Mar 2005 21:08:46 +0000 Received: from [10.31.32.83] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2VL8Xbe013887; Thu, 31 Mar 2005 16:08:34 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 31 Mar 2005 10:04:38 -0500 To: Alex Bligh From: Edward Lewis Subject: Re: NSEC3-01 - more wildcard nits Cc: namedroppers@ops.ietf.org, Alex Bligh Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:37 +0100 3/30/05, Alex Bligh wrote: >That's because the draft should (but as far as I can see does not) >modify the search algorithm such that NSEC3 records are ignored for >all searches other than QTYPE=NSEC3. Modifying the search algorithm has caught my attention. This would be very significant. This is an issue related to the "creation" of new names - the hashes - in the zone. What I am thinking is that zone-obfuscating authentic denial approaches need to consider the process has taking place in the rendering of a negative answer reply and not taking place in the search process. One principle of the search algorithm (referencing 1034/4.3.2) is that it first pays attention only to the names involved. Once settling on a place from which to obtain an answer, the next phase is to match on type. This makes me cringe when I think of treating names as special because they have been created as part of authenticated denial. E.g., does a hash name "block" a wildcard? I have been considering treating the hashes of names as functions of the data, not the data themselves. I.e., the hash of a name would not be in the tree. (Note, if the hash of one name is equivalent to another name, so what? The other name is in the tree, the hash is still a hash.) This would avoid having to alter the search algorithm up until a negative answer is rendered into a message. This is not a change to the search algorithm but a change to the rendering of the answer, something I find less troubling. Nonetheless, such a change is considerable. It's a change in how it is said, not what is said. The problem with treating the hashes as pre-computed non-tree entities is that we then need to transfer the hashes from the master to slaves. Perhaps hashes will look like other names in AXFR and zone file format, but be treated differently upon the loading process. An implementation might choose to place hashed in the same database as the zone data. In this case, the implementation would have to treat hashes differently, modifying its implementation of the search algorithm. Another implementation could choose to keep the hashes in a separate place, using the "normal" search algorithm and referring to the hash list only when employing hash-style authenticated denial. Either case, the concepts in 1034/4.3.2 are upheld - recall that the text there is just a "suggested" way of carrying out the search. PS I still have my doubts about finding a successor to NSEC. A flag day would be needed to erase existing NSEC from the DNS and be seamless. Even if the thought is that "NSEC-era" verifiers will be upgraded to overcome this, that's the flag day. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 31 16:18:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12391 for ; Thu, 31 Mar 2005 16:18:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DH71j-000KAC-SG for namedroppers-data@psg.com; Thu, 31 Mar 2005 21:16:31 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DH71i-000K9y-Te for namedroppers@ops.ietf.org; Thu, 31 Mar 2005 21:16:31 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2VLCles004304 for ; Thu, 31 Mar 2005 16:12:47 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0Hayyi; Thu, 31 Mar 05 16:12:44 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j2VLEbCp014899 for ; Thu, 31 Mar 2005 16:14:37 -0500 (EST) Date: Thu, 31 Mar 2005 16:14:35 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Two more NSEC++ proposals Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk First, these are incomplete -- many details, like how to expose empty non-terminals and details of hash parameterization, are not addressed. These may also be very bad ideas for a number of reasons. You've been warned. On Wed, 30 Mar 2005, Alex Bligh wrote: > I think without hash truncation, "long" names just won't work. This is true so long as one assumes that the hashes have to be expressed as part of domain names (i.e. the owner names of NSEC++ RRs). What if one instead moved both (lists of) hashes into the NSEC++ RDATA and somehow encoded them as something other than domain names (or using an alternate domain name encoding that avoids the length limits, remembering that we have full control over the RDATA): ownername NSEC8 start-hash end-hash bitmap This still tells a resolver that any name whose hash falls between the values in this NSEC8 does not exist in this zone. The question then becomes: what does one use as an ownername? Proposal 1: Anything. Make up (truly) random names in the zone. bert.example.com NSEC8 hash1 hash2 bitmap hates.example.com NSEC8 hash2 hash3 bitmap spam.example.com NSEC8 hash3 hash1 bitmap There's still a potential recursion problem (the NSEC8s prove themselves not to exist), but the NSEC3 discussions have led us to think this won't have any real effect. Also, the authoritative server needs to index the NSEC8s by hash values, not ownernames. One could also create a delegation within the zone to keep these names in one place: foo.nsec.example.com NSEC8 hash1 hash2 bitmap bar.nsec.example.com NSEC8 hash2 hash3 bitmap baz.nsec.example.com NSEC8 hash3 hash1 bitmap Proposal 2: Since the ownernames of these NSEC8's don't matter, why not just stick them all at the same name? Even the apex? Having them be part of one big RRset with one RRSIG just won't scale. Instead, treat each NSEC8 as a separate possible NSEC8 RRset for the apex. The authoritative server keeps a table of these and selects the right one, along with its RRSIG, whenever needed. Even better, have each NSEC8 RRset also contain the NSEC8 RR proving that no wildcard exists. Using the example above, there would be three possible NSEC8 RRsets at the apex, and the server would select among them on demand. Assuming that the wildcard hashes between hash2 and hash3, these RRsets would be: example.com NSEC8 hash1 hash2 bitmap (proves no exact) example.com NSEC8 hash2 hash3 bitmap (proves no wildcard) example.com NSEC8 hash2 hash3 bitmap (proves both) example.com NSEC8 hash2 hash3 bitmap (proves no wildcard) example.com NSEC8 hash3 hash1 bitmap (proves no exact) Running for cover, -- 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 Thu Mar 31 16:38:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14666 for ; Thu, 31 Mar 2005 16:38:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DH7K8-000ME0-0O for namedroppers-data@psg.com; Thu, 31 Mar 2005 21:35:32 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DH7K7-000MDd-2c for namedroppers@ops.ietf.org; Thu, 31 Mar 2005 21:35:31 +0000 Received: from [10.31.32.83] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j2VLZNKq014015; Thu, 31 Mar 2005 16:35:23 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 31 Mar 2005 16:35:30 -0500 To: Samuel Weiler From: Edward Lewis Subject: Re: Two more NSEC++ proposals Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:14 -0500 3/31/05, Samuel Weiler wrote: >Proposal 1: > > One could also create a delegation within the zone to keep these > names in one place: It is not wise to propose a new TLD in a protocol document. >Proposal 2: > The authoritative server keeps a table of these and selects the > right one, along with its RRSIG, whenever needed. This is broken on so many levels. For one, database coherency. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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 Mar 31 17:11:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17659 for ; Thu, 31 Mar 2005 17:11:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DH7rJ-0000tU-RE for namedroppers-data@psg.com; Thu, 31 Mar 2005 22:09:49 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DH7rI-0000tG-Vh for namedroppers@ops.ietf.org; Thu, 31 Mar 2005 22:09:49 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4614A13E3F for ; Thu, 31 Mar 2005 22:09:48 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC3-01 - more wildcard nits In-Reply-To: Message from Edward Lewis of "Thu, 31 Mar 2005 10:04:38 EST." X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 31 Mar 2005 22:09:48 +0000 Message-Id: <20050331220948.4614A13E3F@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >That's because the draft should (but as far as I can see does not) > >modify the search algorithm such that NSEC3 records are ignored for > >all searches other than QTYPE=NSEC3. > > Modifying the search algorithm has caught my attention. This would be > very significant. i missed this when i reviewed NSEC3. it would be very significant, and must not be done this way. if you want a new namespace for dnssec metadata, ask michael graff or myself about slabs, but don't add new search rules that are based on rrtypes or any other in-band protocol element. -- 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 Mar 31 18:38:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24865 for ; Thu, 31 Mar 2005 18:38:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DH9Cf-000AM7-0r for namedroppers-data@psg.com; Thu, 31 Mar 2005 23:35:57 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DH9CV-000ALL-5M for namedroppers@ops.ietf.org; Thu, 31 Mar 2005 23:35:47 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 6E18BC2DA4; Fri, 1 Apr 2005 00:35:46 +0100 (BST) Date: Fri, 01 Apr 2005 00:35:41 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: NSEC3-01 - more wildcard nits Message-ID: In-Reply-To: <20050331220948.4614A13E3F@sa.vix.com> References: <20050331220948.4614A13E3F@sa.vix.com> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 31 March 2005 22:09 +0000 Paul Vixie wrote: >> Modifying the search algorithm has caught my attention. This would be >> very significant. > > i missed this when i reviewed NSEC3. it would be very significant, and > must not be done this way. if you want a new namespace for dnssec > metadata, ask michael graff or myself about slabs, but don't add new > search rules that are based on rrtypes or any other in-band protocol > element. If you can 'guarantee' the owner RR would not be queried for anyway (i.e. other than as a hash), you don't have a problem, because it only affects (AFAICS) queries for the hash of an ownername where there is a wildcard. So if noone ever queried for records beginning (say) __NSEC3__ you'd be OK if you prepended all the hashed owner names with that. I (mostly) jokingly suggested a while back suggested appending ".*" to each NSEC3 hash to form the RR on the basis that noone's going to query for that as the behaviour is currently undefined :-) I too would like to avoid changing the search algorithm. I think it would probably be preferable to pick a suffix or prefix and say "if you make your zone using NSEC3 then you can't use this prefix/suffix" unless there is some cleverer method. 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 Mar 31 18:39:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24894 for ; Thu, 31 Mar 2005 18:39:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DH9CW-000ALT-3o for namedroppers-data@psg.com; Thu, 31 Mar 2005 23:35:48 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DH9CT-000ALA-Cd for namedroppers@ops.ietf.org; Thu, 31 Mar 2005 23:35:45 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id A8860C2DA4; Fri, 1 Apr 2005 00:35:44 +0100 (BST) Date: Fri, 01 Apr 2005 00:35:38 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: NSEC3-01 - more wildcard nits Message-ID: <60B518B2765E3A4DD5D8F060@[192.168.100.25]> In-Reply-To: References: X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 31 March 2005 10:04 -0500 Edward Lewis wrote: > > PS I still have my doubts about finding a successor to NSEC. A flag day > would be needed to erase existing NSEC from the DNS and be seamless. > Even if the thought is that "NSEC-era" verifiers will be upgraded to > overcome this, that's the flag day. Why does existing NSEC data need to be "erased from the DNS"? Why can it not continue living there? Surely if we do the rollover suggested several months ago, then we can leave NSEC data in, people may wish to publish zones with both in (to support old resolvers if they aren't worried about enumeration), and those new converts who adopt NSEC3 only will appear to have insecure zones to "old" (i.e. DNSSECbis) resolvers. Sure, zone publishers will need to pick a day when they don't want to support old NSEC anymore. But why an internet wide flag day? 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 Mar 31 20:44:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04605 for ; Thu, 31 Mar 2005 20:44:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHB9u-0000GF-JB for namedroppers-data@psg.com; Fri, 01 Apr 2005 01:41:14 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DHB9s-0000Fx-Ih for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 01:41:12 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j311f0SF014785; Thu, 31 Mar 2005 20:41:00 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <60B518B2765E3A4DD5D8F060@[192.168.100.25]> References: <60B518B2765E3A4DD5D8F060@[192.168.100.25]> Date: Thu, 31 Mar 2005 20:40:50 -0500 To: Alex Bligh From: Edward Lewis Subject: Re: NSEC3-01 - more wildcard nits Cc: Edward Lewis , namedroppers@ops.ietf.org, Alex Bligh Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 0:35 +0100 4/1/05, Alex Bligh wrote: >--On 31 March 2005 10:04 -0500 Edward Lewis wrote: > >> >> PS I still have my doubts about finding a successor to NSEC. A flag day >> would be needed to erase existing NSEC from the DNS and be seamless. >> Even if the thought is that "NSEC-era" verifiers will be upgraded to >> overcome this, that's the flag day. > >Why does existing NSEC data need to be "erased from the DNS"? Why can >it not continue living there? Surely if we do the rollover suggested >several months ago, then we can leave NSEC data in, people may wish >to publish zones with both in (to support old resolvers if they aren't >worried about enumeration), and those new converts who adopt NSEC3 >only will appear to have insecure zones to "old" (i.e. DNSSECbis) >resolvers. > >Sure, zone publishers will need to pick a day when they don't want to >support old NSEC anymore. But why an internet wide flag day? Fair 'nuf question. This is what I'm thinking. The problem I can't get over is that I presume that admins using NSEC* are the ones that don't want to use NSEC. It's not like NSEC* adopters will be happy to also do NSEC. Although the two do not interfere, the reason for NSEC* is that NSEC shouldn't exist. Assuming there will be NSEC-era validators out there before NSEC* gets rolling, once there are NSEC* zones out there, these validators will see the NSEC* zones as broken because there are no NSEC records there. All of the NSEC-era validators would have to be replaced - that's the flag day or event - because in the meantime, the "extra secure" NSEC* zones may just be cut off if these zones are judged to be broken. Maybe its only negative answers that will be broken. Questions remain. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- 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: