From owner-namedroppers@ops.ietf.org Mon Jun 2 02:44:06 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4300E3A6CD4; Mon, 2 Jun 2008 02:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOAOqC1O9v41; Mon, 2 Jun 2008 02:44:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88CB528C1E1; Mon, 2 Jun 2008 02:43:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K36Pf-000Meb-Lj for namedroppers-data@psg.com; Mon, 02 Jun 2008 09:33:11 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K36PB-000Mbz-Im for namedroppers@ops.ietf.org; Mon, 02 Jun 2008 09:32:58 +0000 Received: from mirre.nlnetlabs.nl (mirre.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:fe0b:89f4]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m529Wase026902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Jun 2008 11:32:37 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl) Message-ID: <4843BE34.7000801@NLnetLabs.nl> Date: Mon, 02 Jun 2008 11:32:36 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.12 (X11/20080414) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: rsa/sha2 draft status X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 02 Jun 2008 11:32:37 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-List-ID: namedroppers@psg.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, the last update to draft-ietf-dnsext-dnssec-rsasha256 (-04) has been nearly two months ago, when i removed the NSEC3 aliases. Since that day I haven't had any comments on the draft. That can mean two things, and for now I'll be the optimist and take the positive interpretation: it's about done and everybody thinks it's ready to proceed. I would like to see another implementation though, is anyone aware of any? (ldns-trunk has support for it, with 'guessed' algorithm identifiers). Secondly, it would be nice if someone with fresh eyes and a bit of PKCS knowledge could verify that I got the encoding and identifiers within the signature right. After that, or if people think that isn't necessary, I propose to get the document towards last call. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhDvjQACgkQ4nZCKsdOncVExgCdFV6rWCrlMlMOJoyh6l1Ux/pM qocAn3QY/dvjhkS08coG5E7s0mFWSQTu =sAp0 -----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 Jun 2 10:33:32 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA2E3A69A2; Mon, 2 Jun 2008 10:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0PP5TDT5rVh; Mon, 2 Jun 2008 10:33:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 21E2C3A6C8C; Mon, 2 Jun 2008 10:28:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3Dd0-000NPJ-Ah for namedroppers-data@psg.com; Mon, 02 Jun 2008 17:15:26 +0000 Received: from [206.190.53.37] (helo=smtp132.rog.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3Dcp-000NNl-Cl for namedroppers@ops.ietf.org; Mon, 02 Jun 2008 17:15:20 +0000 Received: (qmail 89011 invoked from network); 2 Jun 2008 17:15:08 -0000 Received: from unknown (HELO connotech.com) (t2i6@rogers.com@209.148.165.15 with plain) by smtp132.rog.mail.re2.yahoo.com with SMTP; 2 Jun 2008 17:15:08 -0000 X-YMail-OSG: H8rZz04VM1njJXt0_jN3rbogZAOQZfYrB51Jkc4Equgo8SAnq1C1foAR7m3JRlWhgg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48442ACE.2050802@connotech.com> Date: Mon, 02 Jun 2008 12:15:58 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jelte Jansen CC: namedroppers@ops.ietf.org Subject: Re: rsa/sha2 draft status References: <4843BE34.7000801@NLnetLabs.nl> In-Reply-To: <4843BE34.7000801@NLnetLabs.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-List-ID: namedroppers@psg.com Jelte Jansen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hi, > > the last update to draft-ietf-dnsext-dnssec-rsasha256 (-04) has been > nearly two months ago, when i removed the NSEC3 aliases. Since that day > I haven't had any comments on the draft. > > That can mean two things, and for now I'll be the optimist and take the > positive interpretation: it's about done and everybody thinks it's ready > to proceed. > > I would like to see another implementation though, is anyone aware of > any? (ldns-trunk has support for it, with 'guessed' algorithm identifiers). > > Secondly, it would be nice if someone with fresh eyes and a bit of PKCS > knowledge could verify that I got the encoding and identifiers within > the signature right. > I did check these prefix encodings and found no inconsistencies. This draft appears to me coherent with the RFC3110 specifications which introduced RSA signatures with SHA-1. Regards, -- - Thierry Moreau -- to unsubscribe send a message to namedroppers-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 Jun 2 11:53:48 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C34F3A6A9E; Mon, 2 Jun 2008 11:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XSG7RzBOgFY; Mon, 2 Jun 2008 11:53:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D67B3A6B10; Mon, 2 Jun 2008 11:53:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3F2G-0007xs-4J for namedroppers-data@psg.com; Mon, 02 Jun 2008 18:45:36 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3F1k-0007sZ-Dx for namedroppers@ops.ietf.org; Mon, 02 Jun 2008 18:45:21 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 5C6A93A691B; Mon, 2 Jun 2008 11:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-axfr-clarify-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080602184501.5C6A93A691B@core3.amsl.com> Date: Mon, 2 Jun 2008 11:45:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-List-ID: namedroppers@psg.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Zone Transfer Protocol (AXFR) Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-axfr-clarify-08.txt Pages : 1 Date : 2008-6-2 The Domain Name System standard facilities for maintaining coherent servers for a zone consist of three elements. The Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The Incremental Zone Transfer (IXFR) is defined in RFC 1995. A mechanism for prompt notification of zone changes (NOTIFY) is defined in RFC 1996. The base definition of these facilities, that of the AXFR, has proven insufficient in detail, resulting in no implementation complying with it. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of the AXFR, new in the sense that is it recording an accurate definition of an interoperable AXFR mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dnsext-axfr-clarify-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-2113115.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 22:26:45 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED583A6840; Mon, 2 Jun 2008 22:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K35hmiLijr8k; Mon, 2 Jun 2008 22:26:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3EB6828C148; Mon, 2 Jun 2008 22:26:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3Ord-0000Gp-Aq for namedroppers-data@psg.com; Tue, 03 Jun 2008 05:15:17 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3OrD-0000D3-Tw for namedroppers@ops.ietf.org; Tue, 03 Jun 2008 05:15:04 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m4VDQlrq047330; Sat, 31 May 2008 15:26:47 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200805311326.m4VDQlrq047330@givry.fdupont.fr> From: Francis Dupont To: Peter Koch cc: IETF DNSEXT WG Subject: Re: Adopt draft-dupont-dnsext-tsig-md5-deprecated as WG draft? In-reply-to: Your message of Thu, 29 May 2008 21:08:20 +0200. <20080529190820.GA27248@unknown.office.denic.de> Date: Sat, 31 May 2008 15:26:47 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-List-ID: namedroppers@psg.com In your previous mail you wrote: favoring adoption does not necessarily mean agreeing with the draft, so here's my "yes" vote. => I am working on a 01 version with editorial fixes (including the title :-), marked as done after. For the reason of making this distinction see the review below: > Internet-Draft ISC > Intended status: Standards Track May 11, 2008 Updates: RFC 2930, RFC 2845, RFC 4635 => done > Deprecated HMAC MD5 in TSIG Deprecation of HMAC MD5 in the DNS TSIG and TKEY Resource Records => done > But it failed to deprecate the HMAC MD5 algorithm. This document is > targeted to correct this point, in details: This was a conscious decision at that time, IIRC, wasn't it? => I don't know, perhaps it was too soon? > 2. IANA Considerations Move this to the end. => it is the usual position but is it mandatory? As far as I know it is only required to have an IANA section... If you can find another document which is mainly about an IANA registry update, I propose to use it as an example. > In the registry of TSIG algorithm names, add this comment > "(deprecated, see hmac-sha256)" in the HMAC-MD5.SIG-ALG.REG.INT > entry. > > This is copied from the registry of DNSSEC algorithm numbers which > was updated by [RFC3110]. Strictly procedurally I do not think a comment in the registry is a good idea. I'd rather have "this" document added to the references list of "HMAC-MD5.SIG-ALG.REG.INT". RFC 3110 set a precedent, but that registry "DNSSEC Algorithm Numbers" already had a "Description" field. An implementer would have to consult the requirements levels anyway, which are part of neither of these registries. (The second sentence above isn't really necessary ;-) => I proposed to follow strictly the RFC 3110 precedent... The IANA shall say what they think about this. > 3. Implementation Requirements > > The table of section 3 of [RFC4635] is updated into: > > +-------------------+--------------------------+ > | Requirement Level | Algorithm Name | > +-------------------+--------------------------+ > | Optional | HMAC-MD5.SIG-ALG.REG.INT | > | Optional | gss-tsig | > | Mandatory | hmac-sha1 | > | Optional | hmac-sha224 | > | Mandatory | hmac-sha256 | > | Optional | hmac-sha384 | > | Optional | hmac-sha512 | > +-------------------+--------------------------+ There's no reference in RFC 4635 explaining what "Optional" and "Mandatory" actually mean, so why not label HMAC-MD5.SIG-ALG.REG.INT "Deprecated" here? => this is more radical I confess. > Implementations that support TSIG MUST also implement HMAC SHA1 and > HMAC SHA256 and MAY implement gss-tsig and the other algorithms > listed above. ... MUST implement the algorithms marked Mandatory and MAY implement those marked Optional or Deprecated. => I agree this is clearer. > 4. TKEY keying material derivation > > When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying > material is derived from the shared secret and TKEY resource record > data using MD5 [RFC1321] at the end of section 4.1 page 8. nit: top of page 9, but better just refer to the section anyway => oops, you're right: the formula is just on the page break! > This is amended into: > > keying material = > XOR ( DH value, SHA256 ( query data | DH value ) | > SHA256 ( server data | DH value ) ) > > using the same conventions. A normative reference to RFC 4634 for SHA256 (well, "SHA-256") is needed here. => I prefer SHA-256 which is the official name but '-' is misleading in a formula so this is a valid exception IMHO. I note to add a reference. What would "amended into" mean? are both algorithms now equally available (and distinguished by length)? Or should SHA256 replace MD5 and if yes, wouldn't that be a backwards compatibility issue? => I don't understand your comment: I proposed to replace MD5 by SHA-256 keeping other things (in particular padding) equal. There is no compatibility issue other the computed shared secrets will very likely be different. > 5. Security Considerations > > The use of MD5 and HMAC MD5 is NOT RECOMMENDED in TSIG and related > specifications (i.e., TKEY). > > But SHA-1 seems to be vulnerable too, so the use of at least SHA256 > is RECOMMENDED. As implementations which support TSIG are REQUIRED This normative language (As .. "REQUIRED") confuses me. => hum, the wording is bad I agree. > to implement HMAC SHA256, in particular the hmac-sha256 algorithm is > RECOMMENDED for default use in TSIG. Agree with Ed here that a reason for the deprecation of HMAC-MD5 must be given, especially since we've heard that this particular use would not be susceptible to the same attacks as MD5 in digital signatures. => the reason is MD5 is today considered as too weak for any use. >From Francis' earlier message I understand the reason was less cryptographic but pragmatic, expecting the removal of md5 from crypto libraries or enabling the implementor to remove it from their product. => this is more than "expecting": a FIPS 140-2 compliant crypto module implements only approved algorithms and MD5 is *not* approved. And that's why I'm not sure I agree with the draft's recommendation. There's also an operational issue with migration from MD5 to SHA-256 through SHA-1, when MD5 capable software needs to cooperate with products following this advice. One might argue they should at least be able to use SHA-1, but then deprecating SHA-1 is around the corner, as well. Maybe it should be explicitly recommended against its use as of now? => HMAC-SHA256 is marked as mandatory in the RFC 4635 table as using it should not be a problem, at least no more a problem than HMAC-SHA1. IMHO it is too soon to deprecate or even change the requirement level for HMAC-SHA1 but I took benefit of this document to introduce a new(*) recommendation and jumped directly to SHA-256. (*) no algo was recommended, MD5 is heavily used only because it is the first to be specified. > 6. Acknowledgments > Olafur Gudmundsson kindly helped in the procedure to deprecate the > MD5 usage in TSIG, i.e., the procedure which gave this memo. What conspiracy was this? :-) => you'd like to be in? (:-) > 7. References > > 7.1. Normative References see above for SHA-256. => noted. Thanks Francis.Dupont@fdupont.fr PS: (previous and these new) changes will be in the 01 version. -- to unsubscribe send a message to namedroppers-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 Jun 3 09:51:31 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09B6A3A6BA3; Tue, 3 Jun 2008 09:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5PaF9cmyRbJ; Tue, 3 Jun 2008 09:51:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC48B28C251; Tue, 3 Jun 2008 09:48:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3ZUS-000176-Cf for namedroppers-data@psg.com; Tue, 03 Jun 2008 16:36:04 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3ZTy-00014R-6r for namedroppers@ops.ietf.org; Tue, 03 Jun 2008 16:35:50 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m53GZPXZ001875 for ; Tue, 3 Jun 2008 12:35:26 -0400 Message-ID: <484572CE.8080502@nist.gov> Date: Tue, 03 Jun 2008 12:35:26 -0400 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: rsa/sha2 draft status References: <4843BE34.7000801@NLnetLabs.nl> In-Reply-To: <4843BE34.7000801@NLnetLabs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Jelte Jansen wrote: > > That can mean two things, and for now I'll be the optimist and take the > positive interpretation: it's about done and everybody thinks it's ready > to proceed. > I have made comments to previous versions, and I agree with the above - I believe it is ready to proceed. > I would like to see another implementation though, is anyone aware of > any? (ldns-trunk has support for it, with 'guessed' algorithm identifiers). > I don't know of any off hand, but I have heard a couple of implementers say they are "ready" but waiting for the identifier to be assigned. > > After that, or if people think that isn't necessary, I propose to get > the document towards last call. > Seconded. Scott > > Jelte -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- ---------------------------------------- Scott Rose Computer Scientist NIST ph: +1 301-975-8439 scott.rose@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Jun 4 15:12:33 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DC93A695A; Wed, 4 Jun 2008 15:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3zpGCQq47Dn; Wed, 4 Jun 2008 15:12:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76E583A6895; Wed, 4 Jun 2008 15:12:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K411j-000CRx-0h for namedroppers-data@psg.com; Wed, 04 Jun 2008 22:00:15 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K411f-000CQY-A9 for namedroppers@ops.ietf.org; Wed, 04 Jun 2008 22:00:12 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id D9B0A3A6D42; Wed, 4 Jun 2008 15:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-axfr-clarify-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080604220001.D9B0A3A6D42@core3.amsl.com> Date: Wed, 4 Jun 2008 15:00:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Zone Transfer Protocol (AXFR) Author(s) : E. Lewis Filename : draft-ietf-dnsext-axfr-clarify-08.txt Pages : 1 Date : 2008-6-2 The Domain Name System standard facilities for maintaining coherent servers for a zone consist of three elements. The Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The Incremental Zone Transfer (IXFR) is defined in RFC 1995. A mechanism for prompt notification of zone changes (NOTIFY) is defined in RFC 1996. The base definition of these facilities, that of the AXFR, has proven insufficient in detail, resulting in no implementation complying with it. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of the AXFR, new in the sense that is it recording an accurate definition of an interoperable AXFR mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dnsext-axfr-clarify-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-4145547.I-D@ietf.org> --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 Jun 4 19:17:29 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905223A6B18; Wed, 4 Jun 2008 19:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYxtSdv6VNiB; Wed, 4 Jun 2008 19:17:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B9643A6AB6; Wed, 4 Jun 2008 19:17:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K44u9-0005ky-D1 for namedroppers-data@psg.com; Thu, 05 Jun 2008 02:08:41 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K44u6-0005kX-2r for namedroppers@ops.ietf.org; Thu, 05 Jun 2008 02:08:39 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m5528YjR088930 for ; Thu, 5 Jun 2008 12:08:34 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806050208.m5528YjR088930@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-axfr-clarify-08.txt Date: Thu, 05 Jun 2008 12:08:34 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Note 2.1.1.a Set to any value that the client desires. There is no specific means for selecting the value in this field. (Recall that AXFR is done only via TCP connections.) I would still be making the point that the id MUST NOT match any other outstanding id on the TCP session. Also why doesn't the draft meet the formating guidelines? I know the RFC editor will correct it but it is a little harder to read as it is currently formatted. Mark -- 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 Jun 5 01:10:16 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1863A6BB3; Thu, 5 Jun 2008 01:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.25 X-Spam-Level: **** X-Spam-Status: No, score=4.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUQLSwayu2Lg; Thu, 5 Jun 2008 01:10:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E02383A6BD6; Thu, 5 Jun 2008 01:10:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4AMk-000DGO-46 for namedroppers-data@psg.com; Thu, 05 Jun 2008 07:58:34 +0000 Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4AMg-000DFf-EW for namedroppers@ops.ietf.org; Thu, 05 Jun 2008 07:58:32 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA050252667; Thu, 5 Jun 2008 09:57:47 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id JAA13300; Thu, 5 Jun 2008 09:57:46 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200806050757.JAA13300@TR-Sys.de> Subject: Re: draft-ietf-dnsext-axfr-clarify-08.txt To: Mark_Andrews@isc.org Date: Thu, 5 Jun 2008 09:57:46 +0200 (MESZ) Cc: namedroppers@ops.ietf.org In-Reply-To: <200806050208.m5528YjR088930@drugs.dv.isc.org> from Mark Andrews at Jun "5," 2008 "12:08:34" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Thu, 05 Jun 2008 12:08:34 +1000, Mark Andrews wrote: > > Note 2.1.1.a Set to any value that the client desires. There > is no specific means for selecting the value in this field. > (Recall that AXFR is done only via TCP connections.) > > I would still be making the point that the id MUST NOT match any > other outstanding id on the TCP session. +1 > Also why doesn't the draft meet the formating guidelines? I know the > RFC editor will correct it but it is a little harder to read as it is > currently formatted. Cf. the announcement: At Wed, 4 Jun 2008 15:00:01 -0700 (PDT), i-d-announce@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. > > Title : DNS Zone Transfer Protocol (AXFR) > Author(s) : E. Lewis > Filename : draft-ietf-dnsext-axfr-clarify-08.txt > Pages : 1 <<<<--------- :-) :-) > Date : 2008-6-2 Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ -- to unsubscribe send a message to namedroppers-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 Jun 5 06:59:41 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75D203A6856; Thu, 5 Jun 2008 06:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zJlczWquN2R; Thu, 5 Jun 2008 06:59:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 037D93A6844; Thu, 5 Jun 2008 06:59:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4FrI-000Ece-KE for namedroppers-data@psg.com; Thu, 05 Jun 2008 13:50:28 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4Fr7-000EbH-Dn for namedroppers@ops.ietf.org; Thu, 05 Jun 2008 13:50:22 +0000 Received: from [192.168.0.73] (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m55Do3Ri008603; Thu, 5 Jun 2008 09:50:04 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200806050208.m5528YjR088930@drugs.dv.isc.org> References: <200806050208.m5528YjR088930@drugs.dv.isc.org> Date: Thu, 5 Jun 2008 09:50:01 -0400 To: Mark Andrews From: Edward Lewis Subject: comment #2 Re: draft-ietf-dnsext-axfr-clarify-08.txt Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 12:08 +1000 6/5/08, Mark Andrews wrote: >Also why doesn't the draft meet the formating guidelines? I know the >RFC editor will correct it but it is a little harder to read as it is >currently formatted. Do you mean the lack of pagination? If so - because it's a pain to add them in vi. I wait until the draft stabilizes before adding them. (That's the way I've been doing it for years.) And then I add the Table of Contents, etc. Other than that, what formatting guidelines are a problem? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Thu Jun 5 07:14:53 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F903A6D32; Thu, 5 Jun 2008 07:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.25 X-Spam-Level: **** X-Spam-Status: No, score=4.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOgAgofHVOgX; Thu, 5 Jun 2008 07:14:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7728A28C231; Thu, 5 Jun 2008 07:11:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4G1r-000GLL-TG for namedroppers-data@psg.com; Thu, 05 Jun 2008 14:01:23 +0000 Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4G1i-000GKK-LQ for namedroppers@ops.ietf.org; Thu, 05 Jun 2008 14:01:21 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA051784433; Thu, 5 Jun 2008 16:00:33 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA13528; Thu, 5 Jun 2008 16:00:31 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200806051400.QAA13528@TR-Sys.de> Subject: Re: Review of draft-ietf-dnsext-forgery-resilience-03.txt To: pk@DENIC.DE Date: Thu, 5 Jun 2008 16:00:31 +0200 (MESZ) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 27 May 2008 11:52:22 +0200, Peter Koch wrote: > > this is a review of draft-ietf-dnsext-forgery-resilience-03.txt. > ... > >> 9. Countermeasures >> >> ... >> >> Resolver implementations MUST have the ability to: >> >> o Use an unpredictable source port for outgoing queries from a range >> (53, or > 1024) of ports that is as large as possible and >> practicable; > > Maybe use >= 1024 and give some reasoning for the choice to avoid > "privileged" ports discussion. Some ports are definitely bad > choices (e.g. the "daytime" port) anyway, so starting at 1024 is OK, > but needs and explanation. I strongly oppose against this latter proposal, as I already did (in previous off-list communications) against the draft text. This 'choice' is a very bad and damaging idea. Such recommendations violate STD 3 (see below), and system administrators following such recommendations are the most effective and annoying, time consuming, single source of denial-of-service attacks we (and others) suffer from. All kind of classification of port numbers only concerns *server* (listen) ports, *not* ephemeral port usage in client-server context. The misconception I observe in a couple of I-Ds and other recommendations circulating on the Web is the improper application of arguments well resonable for *server* port numbers, to *client* (request source) port numbers as well. Recurring symptoms: ================== The user level symptom is inaccessability of Web sites and bouncing of email after long unsuccessful retries. Diagnosis has revealed the typical context: Most NAT/NAPT boxes currently deployed as ISDN or xDSL access routers randomize an "internal" source port number during translation to an available "external" port number in a way that cannot be controlled by the user/administrator. In a typical SOHO environment, a local "split" DNS server is used to authoritatively serve local (non-public) zone(s) and offer recursive caching name service to the local site. It is common that such DNS servers use the single port 53 for listening and for sending queries to public DNS servers as well. In outbound DNS quries, the NAPT substitutes a random value for the internal source port 53, and many such boxes try to maintain the 'classification' of the port, effectively choosing an external source port in the range 1..1023. [Note that common NAT/NAPT boxes operate a local, low-functionality DNS resolver as well, and hence *never* translate the internal source port number 53 identically, because they have an (unbound) pending local Listen on that port.] Packet filters denying DNS queries with such source ports resulting from randomized port mapping make it impossible to obtain DNS service from the sites that have deployed these filters. Since most such filters, in violation to the applicable standards, not even return ICMP error messages, and hence appear as black holes, legitimate queriers are blocked; in particular Mail Transfer Agents suffer from repeated timeouts necessitating them to perform retries for many days, all condemned to ultimate failure. Many adaptors of such black-holing have been responsive to an exposition of the problems (delivered via auxiliary channels), and have removed these filters in the meantime (including the greatest gTLD operators, and well renowned security businesses), but at least one important global player is totally irresponsive. Background: ========== When symptoms of such behavior first occurred roughly two years ago, I have performed a complete review of the relevant RFCs to determine the applicable normative rules. Major result: || There is *no* statement in the DNS specification and more generic || specifications restricting the *source* port for DNS queries. The situation is a bit complicated because STD 3 restricts almost all discussion of port numbers to TCP and simply refers to that scattered discussion in its sections on UDP (and DNS). ---- excerpt from RFC 1122 (pg. 77) ---- 4. TRANSPORT PROTOCOLS 4.1 USER DATAGRAM PROTOCOL -- UDP 4.1.1 INTRODUCTION . . 4.1.2 PROTOCOL WALK-THROUGH There are no known errors in the specification of UDP. 4.1.3 SPECIFIC ISSUES 4.1.3.1 Ports | UDP well-known ports follow the same rules as TCP | well-known ports; see Section 4.2.2.1 below. | If a datagram arrives addressed to a UDP port for which | there is no pending LISTEN call, UDP SHOULD send an ICMP | Port Unreachable message. ---- end of excerpt from RFC 1122 ---- Therefore, we have to also look into the TCP Standard, RFC 793. ---- excerpt from RFC 793 ---- 2.7. Connection Establishment and Clearing | TCPs are free to associate ports with processes however they choose. However, several basic concepts are necessary in any implementation. | There must be well-known sockets which the TCP associates only with | the "appropriate" processes by some means. We envision that processes | may "own" ports, and that processes can initiate connections only on | the ports they own. (Means for implementing ownership is a local issue, but we envision a Request Port user command, or a method of uniquely allocating a group of ports to a given process, e.g., by associating the high order bits of a port name with a given process.) ---- end of excerpt from RFC 793 ---- ---- excerpt from RFC 1122 (pg. 82) ---- 4.2 TRANSMISSION CONTROL PROTOCOL -- TCP 4.2.1 INTRODUCTION . . 4.2.2 PROTOCOL WALK-THROUGH 4.2.2.1 Well-Known Ports: RFC-793 Section 2.7 DISCUSSION: | TCP reserves port numbers in the range 0-255 for | "well-known" ports, used to access services that are | standardized across the Internet. The remainder of the | port space can be freely allocated to application | processes. Current well-known port definitions are listed in the RFC entitled "Assigned Numbers" [INTRO:6]. A prerequisite for defining a new well- known port is an RFC documenting the proposed service in enough detail to allow new implementations. Some systems extend this notion by adding a third subdivision of the TCP port space: reserved ports, which are generally used for operating-system-specific services. For example, reserved ports might fall between 256 and some system-dependent upper limit. | Some systems further choose to protect well-known and | reserved ports by permitting only privileged users to | open TCP connections with those port values. This is | perfectly reasonable as long as the host does not | assume that all hosts protect their low-numbered ports | in this manner. ---- end of excerpt from RFC 1122 (pg. 82) ---- To restate the last sentence using modern (RFC 2119) language: || Management and protection of local port ranges is a local issue. || Any system MAY manage (low) port numbers as it fits and desires, || but it MUST NOT assume that other hosts protect their || low-numbered ports in the same manner. Therefore, any discriminating treatment of particular port ranges used strictly under control of a remote system is not legitimate. Filtering query-response traffic at the server site based on query source port is an instance of such illegitimate behavior. Conclusion: ========== I therefore request that, for conformance with STD 3, the above quoted bullet of Section 9 of draft-ietf-dnsext-forgery-resilience-03 be changed to say: o Use an unpredictable source port for outgoing queries from a range of ports that is as large as possible and practicable; Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ -- to unsubscribe send a message to namedroppers-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 Jun 5 08:19:30 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78673A6A2D; Thu, 5 Jun 2008 08:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwD1leu0a8+L; Thu, 5 Jun 2008 08:19:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 290F93A697D; Thu, 5 Jun 2008 08:19:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4H7K-0002Wo-Ra for namedroppers-data@psg.com; Thu, 05 Jun 2008 15:11:06 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4H71-0002RO-7Z for namedroppers@ops.ietf.org; Thu, 05 Jun 2008 15:11:01 +0000 Received: from commandprompt.com (227-54-222-209.mycybernet.net [209.222.54.227]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m55FCDZB007972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jun 2008 08:12:16 -0700 Date: Thu, 5 Jun 2008 11:10:42 -0400 From: Andrew Sullivan/dnsext co-chair To: namedroppers@ops.ietf.org Subject: Adoption of draft-dupont-dnsext-tsig-md5-deprecated Message-ID: <20080605151042.GB6406@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Thu, 05 Jun 2008 08:12:17 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, In a previous message (which you can find at http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00689.html), we asked whether the working group wanted to adopt the subject draft as a working group item. We received many expressions of support and no arguments against adopting the draft as a WG item. Some of those expressing support thought it was ready for working group last call. There were some substantive remarks on the draft, however, so a last call is not yet warranted. A new draft will appear soon in the repository as draft-ietf-dnsext-tsig-md5-deprecated-00.txt. This version is supposed to include some updates to the draft we considered for adoption, so if you've already made comments, please check the new version after it is announced to see whether your concerns were addressed. Best regards and thanks for your participation, Olafur & Andrew -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- to unsubscribe send a message to namedroppers-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 Jun 5 09:04:21 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14DAC3A69FF; Thu, 5 Jun 2008 09:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUYDN6oxTA93; Thu, 5 Jun 2008 09:04:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C3FD3A698C; Thu, 5 Jun 2008 09:04:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4HrJ-0009Rm-5o for namedroppers-data@psg.com; Thu, 05 Jun 2008 15:58:37 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4HrB-0009QV-4V for namedroppers@ops.ietf.org; Thu, 05 Jun 2008 15:58:31 +0000 Received: from commandprompt.com (227-54-222-209.mycybernet.net [209.222.54.227]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m55Fxtxp009413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jun 2008 08:59:58 -0700 Date: Thu, 5 Jun 2008 11:58:20 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Confusion about trust anchors and DS records from the parent? Message-ID: <20080605155819.GA16165@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Thu, 05 Jun 2008 08:59:59 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: (No hat) Dear colleagues, I was recently arguing (off list) that if the parent of an island of security gets signed, the (former) island of security does not have to worry about the trust anchors validators might have for it, assuming that the zone operator can be reasonably sure that validators had loaded the new trust anchor for the parent. That is, if I'm teenysite.hugezone.com and I know that people have my TA configured, if hugezone.com gets signed I can stop worrying about TA rollovers, because I just publish my DS in hugezone.com. Since anyone who has my TA configured is extremely likely to configure the TA of hugezone.com, if they fail to remove my TA, I don't have to worry about those old TAs when rolling keys. (Substitute zones appropriately higher in the tree, and this argument becomes somewhat more plausible.) My reasoning was that RFC 4035 says (in section 5.1) that normal processes for validating should apply to islands, and says in 5.3.3 that it's possible for more than one signature to match the required procedure, so you have to try all of them. Someone argued (and demonstrated) in response that both BIND and Unbound don't actually work the way I expected. They'll both prefer the TA deeper in the tree instead, and when that fails, they won't use the DS from the parent. Since it seems that at least two implementations have behaviour that differs from what I expected from reading RFC 4035 (and since others read the same RFC and agreed with my interpretation), I believe some clarification is needed. I have two questions. 1. What do others think the right behaviour is in this case? 2. Is something needed in dnssec-bis-updates to make the correct behaviour plain? Best regards, Andrew -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- to unsubscribe send a message to namedroppers-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 Jun 5 16:50:22 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1F93A6A00; Thu, 5 Jun 2008 16:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AZzH3UxtOlP; Thu, 5 Jun 2008 16:50:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDCE83A6A5D; Thu, 5 Jun 2008 16:50:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4P5C-000Lc5-8i for namedroppers-data@psg.com; Thu, 05 Jun 2008 23:41:26 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4P59-000LbJ-3x for namedroppers@ops.ietf.org; Thu, 05 Jun 2008 23:41:24 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m55NfEDp097022; Fri, 6 Jun 2008 09:41:14 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806052341.m55NfEDp097022@drugs.dv.isc.org> To: Alfred =?hp-roman8?B?SM5uZXM=?= Cc: pk@DENIC.DE, namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Review of draft-ietf-dnsext-forgery-resilience-03.txt In-reply-to: Your message of "Thu, 05 Jun 2008 16:00:31 +0200." <200806051400.QAA13528@TR-Sys.de> Date: Fri, 06 Jun 2008 09:41:14 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > At 27 May 2008 11:52:22 +0200, Peter Koch wrote: > > > > > this is a review of draft-ietf-dnsext-forgery-resilience-03.txt. > > ... > > > >> 9. Countermeasures > >> > >> ... > >> > >> Resolver implementations MUST have the ability to: > >> > >> o Use an unpredictable source port for outgoing queries from a range > >> (53, or > 1024) of ports that is as large as possible and > >> practicable; > > > > Maybe use >= 1024 and give some reasoning for the choice to avoid > > "privileged" ports discussion. Some ports are definitely bad > > choices (e.g. the "daytime" port) anyway, so starting at 1024 is OK, > > but needs and explanation. > > I strongly oppose against this latter proposal, as I already did > (in previous off-list communications) against the draft text. > I don't see your problem. The above is setting a minimum requirement. If you want to make all ports available as source ports you are free to do so. I also does not say source ports are restricted to port 53 or ports >= 1024. There are plenty of firewalls that don't allow queries from port 53 in (let alone any other port below 1024) just as there are still some firewalls that only allow queries from port 53 in. If you offer a service then you shouldn't care which port the query is sourced from. Mark -- 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 Jun 5 17:24:38 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A6343A68DC; Thu, 5 Jun 2008 17:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qKSOK+iaEvq; Thu, 5 Jun 2008 17:24:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC3403A68B9; Thu, 5 Jun 2008 17:24:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4PgC-0003Ct-Jc for namedroppers-data@psg.com; Fri, 06 Jun 2008 00:19:40 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4Pg8-0003Bz-Iv for namedroppers@ops.ietf.org; Fri, 06 Jun 2008 00:19:38 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m560JUmA097542; Fri, 6 Jun 2008 10:19:31 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806060019.m560JUmA097542@drugs.dv.isc.org> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Confusion about trust anchors and DS records from the parent? In-reply-to: Your message of "Thu, 05 Jun 2008 11:58:20 -0400." <20080605155819.GA16165@commandprompt.com> Date: Fri, 06 Jun 2008 10:19:30 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > (No hat) > > Dear colleagues, > > I was recently arguing (off list) that if the parent of an island of > security gets signed, the (former) island of security does not have to > worry about the trust anchors validators might have for it, assuming > that the zone operator can be reasonably sure that validators had > loaded the new trust anchor for the parent. That is, if I'm > teenysite.hugezone.com and I know that people have my TA configured, > if hugezone.com gets signed I can stop worrying about TA rollovers, > because I just publish my DS in hugezone.com. Since anyone who has my > TA configured is extremely likely to configure the TA of hugezone.com, > if they fail to remove my TA, I don't have to worry about those old > TAs when rolling keys. (Substitute zones appropriately higher in the > tree, and this argument becomes somewhat more plausible.) You should always roll keys in a way that allows automata to follow the rollover. At a miminum you need to make it clear to the existing TA users that you are not supporting automated TA rollovers anymore. > My reasoning was that RFC 4035 says (in section 5.1) that normal > processes for validating should apply to islands, and says in 5.3.3 > that it's possible for more than one signature to match the required > procedure, so you have to try all of them. Signatures != trust anchors. > Someone argued (and demonstrated) in response that both BIND and > Unbound don't actually work the way I expected. They'll both prefer > the TA deeper in the tree instead, and when that fails, they won't use > the DS from the parent. > > Since it seems that at least two implementations have behaviour that > differs from what I expected from reading RFC 4035 (and since others > read the same RFC and agreed with my interpretation), I believe some > clarification is needed. I have two questions. > > 1. What do others think the right behaviour is in this case? > > 2. Is something needed in dnssec-bis-updates to make the correct > behaviour plain? > > Best regards, > > Andrew > > -- > Andrew Sullivan > ajs@commandprompt.com > +1 503 667 4564 x104 > http://www.commandprompt.com/ > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: If you have a trust anchor then it needs to be managed. If I have a private version of a zone that it signed and a public version of the same zone zone that is signed. Then by configuring the private trust anchor the validator will reject anything that leaks from the public zone. Similarly if I have a trust anchor for my company I really don't want to trust the DS from the infrastructure zone to ensure that the answers for my zone are validated from the trust anchor for my zone. Things are fuzzier when you talking root and TLD but in general if you configure a deeper trust anchor then by the act of adding that trust anchor you are saying that you place more trust in it than in the chain from the higher trust anchor. I know this may not neccessarially be true as we are currently doing bottom up development but in the long term that is the clear statement you are making. Mark -- 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 Jun 5 19:31:42 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1CE3A6992; Thu, 5 Jun 2008 19:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yZFLFReQMzn; Thu, 5 Jun 2008 19:31:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8465A3A6909; Thu, 5 Jun 2008 19:31:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4RZu-000OSe-B9 for namedroppers-data@psg.com; Fri, 06 Jun 2008 02:21:18 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4RZr-000OS7-Jo for namedroppers@ops.ietf.org; Fri, 06 Jun 2008 02:21:16 +0000 Received: from commandprompt.com (227-54-222-209.mycybernet.net [209.222.54.227]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m562MgDE006741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jun 2008 19:22:45 -0700 Date: Thu, 5 Jun 2008 22:21:09 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080606022108.GA62759@commandprompt.com> References: <20080605155819.GA16165@commandprompt.com> <200806060019.m560JUmA097542@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806060019.m560JUmA097542@drugs.dv.isc.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Thu, 05 Jun 2008 19:22:46 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 06, 2008 at 10:19:30AM +1000, Mark Andrews wrote: > If I have a private version of a zone that it signed and a > public version of the same zone zone that is signed. Then > by configuring the private trust anchor the validator will > reject anything that leaks from the public zone. I understand this use case, but it's also what's troubling me about the behaviour. There's nothing anywhere in the protocol, as near as I can tell, to indicate anything like "degrees of trust". The reported behaviour appears to be sneaking that functionality in through the back door. I'm asking whether we want that functionality; and, if we do, whether the documents as they stand are clear enough on this or whether we need clarifying text. A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- to unsubscribe send a message to namedroppers-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 Jun 5 20:05:02 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78D23A6AB2; Thu, 5 Jun 2008 20:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4e4GUtbFCsEg; Thu, 5 Jun 2008 20:05:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C3C63A684A; Thu, 5 Jun 2008 20:04:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4SBd-0005ci-NB for namedroppers-data@psg.com; Fri, 06 Jun 2008 03:00:17 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4SBa-0005bo-Ah for namedroppers@ops.ietf.org; Fri, 06 Jun 2008 03:00:16 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m563094R099294; Fri, 6 Jun 2008 13:00:09 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806060300.m563094R099294@drugs.dv.isc.org> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Confusion about trust anchors and DS records from the parent? In-reply-to: Your message of "Thu, 05 Jun 2008 22:21:09 -0400." <20080606022108.GA62759@commandprompt.com> Date: Fri, 06 Jun 2008 13:00:09 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > On Fri, Jun 06, 2008 at 10:19:30AM +1000, Mark Andrews wrote: > > > If I have a private version of a zone that it signed and a > > public version of the same zone zone that is signed. Then > > by configuring the private trust anchor the validator will > > reject anything that leaks from the public zone. > > I understand this use case, but it's also what's troubling me about > the behaviour. There's nothing anywhere in the protocol, as near as I > can tell, to indicate anything like "degrees of trust". The reported > behaviour appears to be sneaking that functionality in through the > back door. I'm asking whether we want that functionality; and, if we > do, whether the documents as they stand are clear enough on this or > whether we need clarifying text. There is no sneaking anything here. These use case have been discussed for years. I don't think anyone thought one would ever want to go back past a trust anchor which failed to validate the matching DNSKEY RRset and to then look for a higher trust anchor. In my thinking it is a dangerous policy. Mark > A > > -- > Andrew Sullivan > ajs@commandprompt.com > +1 503 667 4564 x104 > http://www.commandprompt.com/ -- 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 Jun 5 20:57:54 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778523A67A3; Thu, 5 Jun 2008 20:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWOqmgY7y8A7; Thu, 5 Jun 2008 20:57:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A34433A695C; Thu, 5 Jun 2008 20:57:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4Syo-000FEx-JK for namedroppers-data@psg.com; Fri, 06 Jun 2008 03:51:06 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4Syk-000FDH-NM for namedroppers@ops.ietf.org; Fri, 06 Jun 2008 03:51:05 +0000 Received: from [192.168.2.102] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m563p03E045287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jun 2008 20:51:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200806060019.m560JUmA097542@drugs.dv.isc.org> References: <200806060019.m560JUmA097542@drugs.dv.isc.org> Date: Thu, 5 Jun 2008 20:50:58 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: Confusion about trust anchors and DS records from the parent? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 10:19 AM +1000 6/6/08, Mark Andrews wrote: > You should always roll keys in a way that allows automata > to follow the rollover. At a miminum you need to make it > clear to the existing TA users that you are not supporting > automated TA rollovers anymore. Over which communication channel is that done? --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 6 00:52:24 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD173A6910; Fri, 6 Jun 2008 00:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.25 X-Spam-Level: **** X-Spam-Status: No, score=4.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkAwYopLA1Qk; Fri, 6 Jun 2008 00:52:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CAC6E3A6840; Fri, 6 Jun 2008 00:52:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4Wbs-000F51-56 for namedroppers-data@psg.com; Fri, 06 Jun 2008 07:43:40 +0000 Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4Wbm-000F3e-MU for namedroppers@ops.ietf.org; Fri, 06 Jun 2008 07:43:37 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA056358171; Fri, 6 Jun 2008 09:42:51 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id JAA14766; Fri, 6 Jun 2008 09:42:50 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200806060742.JAA14766@TR-Sys.de> Subject: Re: Review of draft-ietf-dnsext-forgery-resilience-03.txt To: Mark_Andrews@isc.org Date: Fri, 6 Jun 2008 09:42:50 +0200 (MESZ) Cc: namedroppers@ops.ietf.org In-Reply-To: <200806052341.m55NfEDp097022@drugs.dv.isc.org> from Mark Andrews at Jun "6," 2008 "09:41:14" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >>> this is a review of draft-ietf-dnsext-forgery-resilience-03.txt. >>> ... >>> >>>> 9. Countermeasures >>>> >>>> ... >>>> >>>> Resolver implementations MUST have the ability to: >>>> >>>> o Use an unpredictable source port for outgoing queries from a range >>>> (53, or > 1024) of ports that is as large as possible and >>>> practicable; >>> >>> Maybe use >= 1024 and give some reasoning for the choice to avoid >>> "privileged" ports discussion. Some ports are definitely bad >>> choices (e.g. the "daytime" port) anyway, so starting at 1024 is OK, >>> but needs and explanation. >> >> I strongly oppose against this latter proposal, as I already did >> (in previous off-list communications) against the draft text. >> > I don't see your problem. The above is setting a minimum > requirement. If you want to make all ports available as > source ports you are free to do so. > > I also does not say source ports are restricted to port 53 > or ports >= 1024. > > There are plenty of firewalls that don't allow queries from > port 53 in (let alone any other port below 1024) just as > there are still some firewalls that only allow queries from > port 53 in. > > If you offer a service then you shouldn't care which port > the query is sourced from. That's the point. My concern is that any clause in a future RFC like the above quoted bullet in the DNS forgery resilience draft will be taken by some folks as an easy excuse for not supporting that latter statement. This is not a theoretical assumption; I already had enough trouble with admins arguing based on similar clauses in some dnsop related drafts in support of, and as a rationale for, the DNS blackholes they had deployed. That's the reason why I hope for a more neutral clause in the draft, for instance the version I had proposed: >> o Use an unpredictable source port for outgoing queries from a >> range of ports that is as large as possible and practicable; > > Mark Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ -- to unsubscribe send a message to namedroppers-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 Jun 6 02:06:44 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77A53A6B10; Fri, 6 Jun 2008 02:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.448 X-Spam-Level: X-Spam-Status: No, score=-4.448 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsJ-sdTvGQUf; Fri, 6 Jun 2008 02:06:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 90AC828C1D8; Fri, 6 Jun 2008 02:05:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4XnV-00047h-D6 for namedroppers-data@psg.com; Fri, 06 Jun 2008 08:59:45 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4XnG-000457-1e for namedroppers@ops.ietf.org; Fri, 06 Jun 2008 08:59:32 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0K2100D019Z3NB00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Fri, 06 Jun 2008 09:59:28 +0100 (IST) Received: from [10.0.1.189] ([83.141.81.52]) by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPSA id <0K2100GCFAB1SMC0@cali.ucd.ie>; Fri, 06 Jun 2008 09:59:26 +0100 (IST) Date: Fri, 06 Jun 2008 09:59:23 +0100 From: Niall O'Reilly Subject: Re: Confusion about trust anchors and DS records from the parent? In-reply-to: <200806060300.m563094R099294@drugs.dv.isc.org> To: Mark Andrews Cc: Niall O'Reilly , Andrew Sullivan , namedroppers@ops.ietf.org Message-id: <351D9477-9649-4A58-9242-8FE721B8C4DD@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.753) Content-type: multipart/signed; boundary=Apple-Mail-57-359846808; micalg=pgp-sha1; protocol="application/pgp-signature" Content-transfer-encoding: 7BIT X-Pgp-Agent: GPGMail 1.1.2 (Tiger) References: <200806060300.m563094R099294@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-57-359846808 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 6 Jun 2008, at 04:00, Mark Andrews wrote: > [MA] There is no sneaking anything here. That's arguable, especially as Mark seems to be using the term "sneaking" in a different sense from Andrew's. > [MA] These use case have been discussed for years. That's at least verifiable. > [MA] I don't think anyone thought one > would ever want to go back past a trust anchor which failed > to validate the matching DNSKEY RRset and to then look for a > higher trust anchor. In my thinking it is a dangerous policy. Andrew's question was > [AS] whether we want that functionality; and, if we > do, whether the documents as they stand are clear enough on this or > whether we need clarifying text. Mark, you seem to be saying that whatever discussion has taken place over the years is all the documentation we need. Is that how you intended to be understood? Best regards, Niall O'Reilly University College Dublin IT Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 --Apple-Mail-57-359846808 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFISPxxeYfkja6ZXtkRAm91AJ9EyRmIO766gjRISAINCa9KxtgLCACbB2XH N3oLBlKPP/CNPh8wCmBrXBo= =Fsm/ -----END PGP SIGNATURE----- --Apple-Mail-57-359846808-- -- to unsubscribe send a message to namedroppers-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 Jun 6 02:29:46 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696B028C120; Fri, 6 Jun 2008 02:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbG6C6vymjCN; Fri, 6 Jun 2008 02:29:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C940928C0D8; Fri, 6 Jun 2008 02:29:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4YCg-0008yJ-Tx for namedroppers-data@psg.com; Fri, 06 Jun 2008 09:25:46 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4YCc-0008xJ-HC for namedroppers@ops.ietf.org; Fri, 06 Jun 2008 09:25:44 +0000 X-IronPort-AV: E=Sophos;i="4.27,600,1204498800"; d="scan'208";a="10949118" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Jun 2008 11:25:36 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m569PaeH031321; Fri, 6 Jun 2008 11:25:36 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m569PauO025122; Fri, 6 Jun 2008 09:25:36 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 11:25:36 +0200 Received: from [192.165.72.13] ([10.61.81.251]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 11:25:36 +0200 Cc: Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <5560355C-8305-4C63-9326-DD45293DC8A7@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Mark Andrews In-Reply-To: <200806060300.m563094R099294@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: Confusion about trust anchors and DS records from the parent? Date: Fri, 6 Jun 2008 11:25:25 +0200 References: <200806060300.m563094R099294@drugs.dv.isc.org> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 06 Jun 2008 09:25:36.0266 (UTC) FILETIME=[46E8BEA0:01C8C7B7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=512; t=1212744336; x=1213608336; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20Confusion=20about=20trust=20anchors=20a nd=20DS=20records=20from=20the=20parent?=20 |Sender:=20; bh=Qavx3yScssjTXpRMbkvXx6M/Pmpx7oVosyuu0x08fnM=; b=Xe1nWO+SoFJfGL7T5ArTDA5tjgudrAeZoa9aROOWVCdBERONbBJ71enO4w bj8hlDzfHiml+ZxUKN8q1NQqFH8B73WvMr3t33sJjufetEqFziZJmon4f7Np kN2EtklSjO; Authentication-Results: ams-dkim-1; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 6 jun 2008, at 05.00, Mark Andrews wrote: > There is no sneaking anything here. These use case have > been discussed for years. I don't think anyone thought one > would ever want to go back past a trust anchor which failed > to validate the matching DNSKEY RRset and to then look for a > higher trust anchor. In my thinking it is a dangerous policy. If that was the conclusion, and still is the conclusion, then I say that a clarification in the RFCs is definitely needed. Patrik -- to unsubscribe send a message to namedroppers-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 Jun 6 02:52:48 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136AD3A6838; Fri, 6 Jun 2008 02:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wroiG0UvikE; Fri, 6 Jun 2008 02:52:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE45D3A6927; Fri, 6 Jun 2008 02:52:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4YYk-000D6G-3L for namedroppers-data@psg.com; Fri, 06 Jun 2008 09:48:34 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4YYP-000D2N-Me for namedroppers@ops.ietf.org; Fri, 06 Jun 2008 09:48:19 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m569lrvM012038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2008 11:47:53 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <484907C9.1060600@nlnetlabs.nl> Date: Fri, 06 Jun 2008 11:47:53 +0200 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Mark Andrews , Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: Confusion about trust anchors and DS records from the parent? References: <200806060300.m563094R099294@drugs.dv.isc.org> <5560355C-8305-4C63-9326-DD45293DC8A7@cisco.com> In-Reply-To: <5560355C-8305-4C63-9326-DD45293DC8A7@cisco.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Fri, 06 Jun 2008 11:47:54 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrik Fältström wrote: | On 6 jun 2008, at 05.00, Mark Andrews wrote: | |> There is no sneaking anything here. These use case have |> been discussed for years. I don't think anyone thought one |> would ever want to go back past a trust anchor which failed |> to validate the matching DNSKEY RRset and to then look for a |> higher trust anchor. In my thinking it is a dangerous policy. | | If that was the conclusion, and still is the conclusion, then I say that | a clarification in the RFCs is definitely needed. | | Patrik During the development of unbound, this question came up. No text in RFCs could be found. In unbound we wanted the most secure default settings. So, similar to Mark Andrews, going up is dangerous, there is no text, thus we didn't do it. Unbound has one exception, if parentzone gives a name error during resolution, and it is signed, the parentkey is used to validate that answer. Otherwise, childkey is used for the childzone. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhJB8kACgkQkDLqNwOhpPjOrwCbBiW3NdOrh4hgw1XEWWoo2n// MnAAoKN6KId8P77BfZPDuenUwyDTe8Af =iEh3 -----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 Fri Jun 6 02:57:09 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293423A6AC2; Fri, 6 Jun 2008 02:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.734 X-Spam-Level: X-Spam-Status: No, score=0.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csBTRNkFpAct; Fri, 6 Jun 2008 02:57:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A27C13A6A62; Fri, 6 Jun 2008 02:57:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4Yd0-000DnK-E6 for namedroppers-data@psg.com; Fri, 06 Jun 2008 09:52:58 +0000 Received: from [69.46.124.26] (helo=outbound.afilias.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4Ycw-000Dlw-BS for namedroppers@ops.ietf.org; Fri, 06 Jun 2008 09:52:56 +0000 Received: from bmp-336-ms505.wa.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1K4Ycs-0006ft-5B; Fri, 06 Jun 2008 09:52:50 +0000 Cc: namedroppers@ops.ietf.org Message-Id: From: Shane Kerr To: Andrew Sullivan In-Reply-To: <20080605155819.GA16165@commandprompt.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: Confusion about trust anchors and DS records from the parent? Date: Fri, 6 Jun 2008 11:52:48 +0200 References: <20080605155819.GA16165@commandprompt.com> X-Mailer: Apple Mail (2.924) X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew, On Jun 5, 2008, at 17:58 +0200, Andrew Sullivan wrote: > My reasoning was that RFC 4035 says (in section 5.1) that normal > processes for validating should apply to islands, and says in 5.3.3 > that it's possible for more than one signature to match the required > procedure, so you have to try all of them. > > Someone argued (and demonstrated) in response that both BIND and > Unbound don't actually work the way I expected. They'll both prefer > the TA deeper in the tree instead, and when that fails, they won't use > the DS from the parent. > > Since it seems that at least two implementations have behaviour that > differs from what I expected from reading RFC 4035 (and since others > read the same RFC and agreed with my interpretation), I believe some > clarification is needed. I have two questions. > > 1. What do others think the right behaviour is in this case? It is hard for me to imagine a case where you trust the parent to hand out NS records but not DS records. :) I think that your reasoning is correct, and that resolvers should use a logical OR of the TA. > 2. Is something needed in dnssec-bis-updates to make the correct > behaviour plain? Since it appears all implementations use only the most-specific TA, I think so. :) -- Shane -- to unsubscribe send a message to namedroppers-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 Jun 6 04:41:51 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A1F3A6CC9; Fri, 6 Jun 2008 04:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.25 X-Spam-Level: **** X-Spam-Status: No, score=4.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qz7fPezKQbZC; Fri, 6 Jun 2008 04:41:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 181DE3A6D09; Fri, 6 Jun 2008 04:41:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4aED-0008Bc-Eg for namedroppers-data@psg.com; Fri, 06 Jun 2008 11:35:29 +0000 Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4aE2-00088z-BL for namedroppers@ops.ietf.org; Fri, 06 Jun 2008 11:35:27 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA057342079; Fri, 6 Jun 2008 13:34:39 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA15030; Fri, 6 Jun 2008 13:34:38 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200806061134.NAA15030@TR-Sys.de> Subject: Re: Confusion about trust anchors and DS records from the parent? To: shane@ca.afilias.info Date: Fri, 6 Jun 2008 13:34:38 +0200 (MESZ) Cc: namedroppers@ops.ietf.org In-Reply-To: from Shane Kerr at Jun "6," 2008 "11:52:48" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Shane, thanks for your notes. > Andrew, > > On Jun 5, 2008, at 17:58 +0200, Andrew Sullivan wrote: > >> My reasoning was that RFC 4035 says (in section 5.1) that normal >> processes for validating should apply to islands, and says in 5.3.3 >> that it's possible for more than one signature to match the required >> procedure, so you have to try all of them. >> >> Someone argued (and demonstrated) in response that both BIND and >> Unbound don't actually work the way I expected. They'll both prefer >> the TA deeper in the tree instead, and when that fails, they won't >> use the DS from the parent. >> >> Since it seems that at least two implementations have behaviour that >> differs from what I expected from reading RFC 4035 (and since others >> read the same RFC and agreed with my interpretation), I believe some >> clarification is needed. I have two questions. >> >> 1. What do others think the right behaviour is in this case? > > It is hard for me to imagine a case where you trust the parent to > hand out NS records but not DS records. :) > > I think that your reasoning is correct, and that resolvers should use > a logical OR of the TA. Exactly. 'Trust' per definition is a cumulative matter. Trusting never can mean a reduction in also established trust in . There's no protocol element in DNSSEC to define or distribute *distrust*. TAs establish trust to a DNS (sub)tree extending as far as valid signature chains can be followed, without additional exceptions. Hence, the only possible, conceptually and logically consistent solution is to operate with the *union* of all trust configured, or, as you said, the logical OR of TAs. Beware that similarly, if a zone has multiple signature keys, verification of a single signature suffices to accept an RRset as valid. Here again the principle can be observed that a single valid signature chain conveys trust that cannot be revoked by a failure to validate another possible chain. >> 2. Is something needed in dnssec-bis-updates to make the correct >> behaviour plain? > > Since it appears all implementations use only the most-specific TA, > I think so. :) +1 > -- > Shane Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ -- to unsubscribe send a message to namedroppers-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 Jun 6 05:47:47 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255D03A6D33; Fri, 6 Jun 2008 05:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kp2yh8gQEGx; Fri, 6 Jun 2008 05:47:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 24B2A3A686D; Fri, 6 Jun 2008 05:47:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4bBU-000KGJ-Pa for namedroppers-data@psg.com; Fri, 06 Jun 2008 12:36:44 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4bBL-000KEH-5G for namedroppers@ops.ietf.org; Fri, 06 Jun 2008 12:36:38 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id 22C3D9587A; Fri, 6 Jun 2008 09:36:34 -0300 (BRT) Date: Fri, 6 Jun 2008 09:36:34 -0300 From: Frederico A C Neves To: Shane Kerr Cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080606123634.GA14433@registro.br> Mail-Followup-To: Frederico A C Neves , Shane Kerr , Andrew Sullivan , namedroppers@ops.ietf.org References: <20080605155819.GA16165@commandprompt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 06, 2008 at 11:52:48AM +0200, Shane Kerr wrote: > Andrew, > > On Jun 5, 2008, at 17:58 +0200, Andrew Sullivan wrote: > > >My reasoning was that RFC 4035 says (in section 5.1) that normal > >processes for validating should apply to islands, and says in 5.3.3 > >that it's possible for more than one signature to match the required > >procedure, so you have to try all of them. > > > >Someone argued (and demonstrated) in response that both BIND and > >Unbound don't actually work the way I expected. They'll both prefer > >the TA deeper in the tree instead, and when that fails, they won't use > >the DS from the parent. > > > >Since it seems that at least two implementations have behaviour that > >differs from what I expected from reading RFC 4035 (and since others > >read the same RFC and agreed with my interpretation), I believe some > >clarification is needed. I have two questions. > > > >1. What do others think the right behaviour is in this case? > > It is hard for me to imagine a case where you trust the parent to hand > out NS records but not DS records. :) Completely agree. Specially when there is a greater trust value on them, DSs are not just hints like the NSs. > I think that your reasoning is correct, and that resolvers should use > a logical OR of the TA. > > >2. Is something needed in dnssec-bis-updates to make the correct > >behaviour plain? > > Since it appears all implementations use only the most-specific TA, I > think so. :) There is one tha behaves differently. dig sigchase fails the most-specific and then follows the less-specific TA and validates. Fred -- to unsubscribe send a message to namedroppers-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 Jun 6 16:38:14 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1D53A6C28; Fri, 6 Jun 2008 16:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMmHYozSEaoW; Fri, 6 Jun 2008 16:38:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C2893A6875; Fri, 6 Jun 2008 16:38:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4lHA-0005RC-Q8 for namedroppers-data@psg.com; Fri, 06 Jun 2008 23:23:16 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4lH6-0005QT-JT for namedroppers@ops.ietf.org; Fri, 06 Jun 2008 23:23:14 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=EhhKwCXQvO0bUXOcHJzXRn30+A5rYk5Drk9q8ASRuXGfwt9/2zsUHV6K kULN1r2C1fypCmxVxzZFNQoyMWohyvJL0L/rhStw063iWXZCMm2LduOnC 0bmGAtDyw3ERKq3; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1212794592; x=1244330592; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20Confusion=20about=20trust=20anchors=20and=20DS =20records=20from=20the=20parent?|Date:=20Sat,=207=20Jun =202008=2001:23:10=20+0200|Message-ID:=20|To:=20Andrew=20Sullivan=20|Cc: =20namedroppers@ops.ietf.org|MIME-Version:=201.0 |In-Reply-To:=20<20080605155819.GA16165@commandprompt.com >|References:=20<20080605155819.GA16165@commandprompt.com >; bh=BAFmV40VsquENhktj6gWNzH8e4bR9AeZeLbsGd62SVc=; b=H/BBOOXsORVAgJt1LIMYaomnI6fB15PZ5vJF4mYafyi8JYWc8uhxJ3CG s4TloBZuKGh1o0+bK5a3f5PHo4SbIhEeXzGO/3CNWKeG0kkdSovy7gtZh DH87dFlv+Ld5bou; X-IronPort-AV: E=Sophos;i="4.27,603,1204502400"; d="scan'208";a="1765104" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 07 Jun 2008 00:23:10 +0100 In-Reply-To: <20080605155819.GA16165@commandprompt.com> References: <20080605155819.GA16165@commandprompt.com> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: Confusion about trust anchors and DS records from the parent? MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Sat, 7 Jun 2008 01:23:10 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 07/06/2008 12:23:10 AM, Serialize complete at 07/06/2008 12:23:10 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew Sullivan wrote on 06/05/2008 05:58:20 PM: > (No hat) > > Dear colleagues, > > I was recently arguing (off list) that if the parent of an island of > security gets signed, the (former) island of security does not have to > worry about the trust anchors validators might have for it, assuming > that the zone operator can be reasonably sure that validators had > loaded the new trust anchor for the parent. That is, if I'm > teenysite.hugezone.com and I know that people have my TA configured, > if hugezone.com gets signed I can stop worrying about TA rollovers, > because I just publish my DS in hugezone.com. Since anyone who has my > TA configured is extremely likely to configure the TA of hugezone.com, > if they fail to remove my TA, I don't have to worry about those old > TAs when rolling keys. (Substitute zones appropriately higher in the > tree, and this argument becomes somewhat more plausible.) > > My reasoning was that RFC 4035 says (in section 5.1) that normal > processes for validating should apply to islands, and says in 5.3.3 > that it's possible for more than one signature to match the required > procedure, so you have to try all of them. > > Someone argued (and demonstrated) in response that both BIND and > Unbound don't actually work the way I expected. They'll both prefer > the TA deeper in the tree instead, and when that fails, they won't use > the DS from the parent. > > Since it seems that at least two implementations have behaviour that > differs from what I expected from reading RFC 4035 (and since others > read the same RFC and agreed with my interpretation), I believe some > clarification is needed. I have two questions. > > 1. What do others think the right behaviour is in this case? It is my opinion that the desired behavior is as follows: When there are multiple chains of trust, at least one must validate correctly. We have explicitly avoided terms like 'more trusted' or 'more secure' when writing these documents. I feel uncomfortable to blindly assume that the shortest chain of trust is the most secure. To measure the most secure, we'd have to include algorithm type, key size, even key age, and that is a slippery slope, and we need to avoid that. > 2. Is something needed in dnssec-bis-updates to make the correct > behaviour plain? Yes. We need to add text to dnssec-bis-updates to make that explicit. Note that the there is text in RFC 2535 that supports the current behavior of BIND and UNBOUND. However, that does not appear in the subsequent DNSSEC standards which obsoletes 2535. 6.3.2 Conflicting Data It is possible that there will be multiple SIG-KEY chains that appear to authenticate conflicting RRset answers to the same query. A resolver should choose only the most reliable answer to return and discard other data. This choice of most reliable is a matter of local policy which could take into account differing trust in algorithms, key sizes, staticly configured keys, zones traversed, etc. The technique given below is recommended for taking into account SIG-KEY chain length. A resolver should keep track of the number of successive secure zones traversed from a staticly configured key starting point to any secure zone it can reach. In general, the lower such a distance number is, the greater the confidence in the data. Staticly configured data should be given a distance number of zero. If a query encounters different Authenticated data for the same query with different distance values, that with a larger value should be ignored unless some other local policy covers the case. I would rather avoid a protocol fight over this. I think it is sensible to assume that all configured trust anchors are all trusted equally, which implies that all chains of trust should be trusted equally, so it would suffice to have one validated chain of trust. In case one chain fails, try the next chain. 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 Fri Jun 6 19:37:39 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82FEA3A6835; Fri, 6 Jun 2008 19:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpG5t5Klt-Qm; Fri, 6 Jun 2008 19:37:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 90D123A67D0; Fri, 6 Jun 2008 19:37:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4oBo-0006nm-6j for namedroppers-data@psg.com; Sat, 07 Jun 2008 02:29:56 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4oBi-0006n5-0q for namedroppers@ops.ietf.org; Sat, 07 Jun 2008 02:29:52 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2BD1C1145C; Sat, 7 Jun 2008 02:29:47 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "Roy Arends" cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: Confusion about trust anchors and DS records from the parent? In-Reply-To: Your message of "Sat, 07 Jun 2008 01:23:10 +0200." References: <20080605155819.GA16165@commandprompt.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 07 Jun 2008 02:29:47 +0000 Message-ID: <43009.1212805787@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > ... > Yes. We need to add text to dnssec-bis-updates to make that explicit. agreed. > Note that the there is text in RFC 2535 that supports the current behavior > of BIND and UNBOUND. However, that does not appear in the subsequent > DNSSEC standards which obsoletes 2535. > ... > I would rather avoid a protocol fight over this. I think it is sensible to > assume that all configured trust anchors are all trusted equally, which > implies that all chains of trust should be trusted equally, so it would > suffice to have one validated chain of trust. In case one chain fails, try > the next chain. i would like to retain the option, non-default, of requiring that a zone use a key that i have an anchor for. but just as any RRSIG->DNSKEY->DS chain that works causes success, even if some don't work, so it should be, by default, that if a trust anchor isn't needed, it won't be used, and so it won't matter whether or not it would work if tried. -- to unsubscribe send a message to namedroppers-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 Jun 8 21:44:33 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01083A67AA; Sun, 8 Jun 2008 21:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5rT2DFtScEZ; Sun, 8 Jun 2008 21:44:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E2DE3A6A0D; Sun, 8 Jun 2008 21:44:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5Z6h-000ELs-2Y for namedroppers-data@psg.com; Mon, 09 Jun 2008 04:35:47 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5Z63-000EDg-RF for namedroppers@ops.ietf.org; Mon, 09 Jun 2008 04:35:10 +0000 Received: from dynip226st208.kpn-cc.nl (dynip226st208.kpn-cc.nl [77.241.226.208]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m594Yx57014065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Jun 2008 06:35:00 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Cc: Olaf Kolkman Message-Id: From: Olaf Kolkman To: IETF DNSEXT WG In-Reply-To: <43009.1212805787@sa.vix.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-603170667" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: Confusion about trust anchors and DS records from the parent? Date: Mon, 9 Jun 2008 06:34:48 +0200 References: <20080605155819.GA16165@commandprompt.com> <43009.1212805787@sa.vix.com> X-Pgp-Agent: GPGMail d52 (v52, Leopard) X-Mailer: Apple Mail (2.924) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Mon, 09 Jun 2008 06:35:00 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-603170667 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 7, 2008, at 4:29 AM, Paul Vixie wrote: >> ... >> Yes. We need to add text to dnssec-bis-updates to make that explicit. > > agreed. 1++, bis needs clarification. > > >> Note that the there is text in RFC 2535 that supports the current >> behavior >> of BIND and UNBOUND. However, that does not appear in the subsequent >> DNSSEC standards which obsoletes 2535. >> ... >> I would rather avoid a protocol fight over this. I think it is >> sensible to >> assume that all configured trust anchors are all trusted equally, >> which >> implies that all chains of trust should be trusted equally, so it >> would >> suffice to have one validated chain of trust. In case one chain >> fails, try >> the next chain. > > i would like to retain the option, non-default, of requiring that a > zone use > a key that i have an anchor for. but just as any RRSIG->DNSKEY->DS > chain > that works causes success, even if some don't work, so it should be, > by > default, that if a trust anchor isn't needed, it won't be used, and > so it > won't matter whether or not it would work if tried. > During DNSSEC bis development we have used the stop-gap local policy in many cases and I believe this was one. I would argue that one would like to retain an option for (any) local policy. The update document should be very clear about what the default is and allow for other use-cases. I can subscribe to both the use case where closest trust-anchor is authoritative for the validation and the use case where the chain of trust overwrites the closest trust-anchor. For the latter I can see many different policies. Anyhow I can consent with keeping the closest trust-anchor as authority. I can see the need for a small client side maintenance tool: One that implements the timers-rollover and also one that clears out trust- anchors for which longer chains exist (Labs is working on it :-) ) --Olaf --Olaf --Apple-Mail-2-603170667 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: This message is locally signed. iEYEARECAAYFAkhMsugACgkQtN/ca3YJIofQmQCfU3TgiSQX9gzNbJzYC2dFJyl6 PW8An1PcN31M+60+S20uZp5zfku330vd =h8ug -----END PGP SIGNATURE----- --Apple-Mail-2-603170667-- -- to unsubscribe send a message to namedroppers-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 Jun 8 22:08:34 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17BC3A6AAB; Sun, 8 Jun 2008 22:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5X9N3RJNVJ5; Sun, 8 Jun 2008 22:08:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81E853A6A0D; Sun, 8 Jun 2008 22:08:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5ZXr-000JJO-0D for namedroppers-data@psg.com; Mon, 09 Jun 2008 05:03:51 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5ZXj-000JIE-7I for namedroppers@ops.ietf.org; Mon, 09 Jun 2008 05:03:49 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=2z7pWSJzG64/3xwQAzRqXhyiUvqG8EeB6jQ+KZe9FsOI/OXzd0GhjnC4 cSTfRowMqSiWPJ91aQy4YhNEgtuOFO6PQIlORO6yqEthZJ/OWzdYf2S5E WcVicMNwHfHch9A; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1212987823; x=1244523823; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20Confusion=20about=20trust=20anchors=20and=20DS =20records=20from=20the=20parent?|Date:=20Mon,=209=20Jun =202008=2007:03:39=20+0200|Message-ID:=20|To:=20Olaf=20Kolkman=20|Cc:=20IETF =20DNSEXT=20WG=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20<20080605155 819.GA16165@commandprompt.com>=20=20=20 =20<43009.1212805787@sa.vix.com>=20; bh=ns8Uzu9m2a0Y/eHZAE9Hole94TO3sRy/uVouEsK1Ah0=; b=VzyyzCa3ULVEX6nY4EEBBHzI1lJQYpANI2Sl0I4yyq7dAloxYRQx0Z7K jI+QWid6Im5WZpPK+4jeLcyZVRk03i+GPRNw6wnT+vakpv0av8E/OcC96 G/VvofAeYXShKv2; X-IronPort-AV: E=Sophos;i="4.27,611,1204502400"; d="scan'208";a="2389680" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 09 Jun 2008 06:03:40 +0100 In-Reply-To: References: <20080605155819.GA16165@commandprompt.com> <43009.1212805787@sa.vix.com> To: Olaf Kolkman Cc: IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Mon, 9 Jun 2008 07:03:39 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 09/06/2008 06:03:40 AM, Serialize complete at 09/06/2008 06:03:40 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Olaf Kolkman wrote on 06/09/2008 06:34:48 AM: > Anyhow I can consent with keeping the closest trust-anchor as authority. As an option, or as the default? Roy Arends 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 Mon Jun 9 06:34:24 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE333A6C54; Mon, 9 Jun 2008 06:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSbP5AomzxPI; Mon, 9 Jun 2008 06:34:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6767B3A67F7; Mon, 9 Jun 2008 06:34:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5hJ2-0008T5-9N for namedroppers-data@psg.com; Mon, 09 Jun 2008 13:21:04 +0000 Received: from [216.168.239.74] (helo=peregrine.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5hIq-0008Qs-L5 for namedroppers@ops.ietf.org; Mon, 09 Jun 2008 13:20:58 +0000 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id m59D7Zwo004210; Mon, 9 Jun 2008 09:07:35 -0400 Received: from dul1wnexmb02.vcorp.ad.vrsn.com ([10.170.12.135]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 09:20:47 -0400 Received: from dul1mcdblacka-l1.vcorp.ad.vrsn.com ([10.131.29.157]) by dul1wnexmb02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 09:20:47 -0400 Cc: IETF DNSEXT WG Message-Id: <7AAEA0F6-22C7-4902-B1D1-A6AB5AC3BF04@verisign.com> From: David Blacka To: Olaf Kolkman In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-23-634729673; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: Confusion about trust anchors and DS records from the parent? Date: Mon, 9 Jun 2008 09:20:47 -0400 References: <20080605155819.GA16165@commandprompt.com> <43009.1212805787@sa.vix.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 09 Jun 2008 13:20:47.0227 (UTC) FILETIME=[A0EFC4B0:01C8CA33] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-23-634729673 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 9, 2008, at 12:34 AM, Olaf Kolkman wrote: > > During DNSSEC bis development we have used the stop-gap local policy > in many cases and I believe this was one. > > > I would argue that one would like to retain an option for (any) > local policy. The update document should be very clear about what > the default is and allow for other use-cases. I can subscribe to > both the use case where closest trust-anchor is authoritative for > the validation and the use case where the chain of trust overwrites > the closest trust-anchor. For the latter I can see many different > policies. To be clear, I don't think anyone suggested having the chain of trust "overwrite" the closest trust anchor. Instead, the suggestion was simply to try all trust anchors until one succeeded. -- David Blacka Sr. Engineer VeriSign Platform Product Development --Apple-Mail-23-634729673 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILiDCCA6Yw ggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFy eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2ln biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BV c2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWty IChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHPbxY7 wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+4ec3 JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhCAQEE BAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQt MCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3DQEB BQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9juNL Lt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wazfVH bSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTANBgkq hkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENsYXNz IDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYD VQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1kS3Z OO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6cGFP hkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYwDwYD VR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAroCmG J2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUFAAOB gQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVwWk4o Hd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb6NDb if1JwnUEA5el1JaB2CNB8DCCBBYwggN/oAMCAQICEH/ky2MD0Ks+tybXzdJAD/EwDQYJKoZIhvcN AQEFBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVt cGxveWVlIENBMB4XDTA4MDMwMzAwMDAwMFoXDTA5MDMwMzIzNTk1OVowajERMA8GA1UEChMIVkVS SVNJR04xEDAOBgNVBAsTB1ZBLUVBU1QxEzARBgNVBAMTClJlY2lwaWVudHMxLjAsBgNVBAMTJWRh dmlkYiAoQmxhY2thIERhdmlkLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALf4yQLwzdrWeSe8hErx/kvENPF+K5/iHQcWFp4QZuGga+UeifgP6YNZdgTvzPmO4eZV ZADPq7tuQwvwsXtbSxqLjw7b8xpzyFDlG1LxrLdLDCUcEnWGtazaDaThrN/2VS72bfN6COSRB+Gj YjGO2CKeZ3OoaCnIUCoYistgQJabAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1UdHwRSMFAw TqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhjaGFuZ2VF bXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETZGF2aWRiQHZl cmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJ bmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4g KGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjANBgkqhkiG9w0BAQUFAAOBgQAmUg2DmlM+ixRWjnMTDWoPPaSa9S0cA8/n1cnjv7FS 4IMZqIdAcgWi/sTCoarffoH6FsXLmScTGTTWaCPZDL+ydxeQp25IW4kkOS3mNQrqnmZZYGVofvqg Ea9Yrn3aOm5X/2baHHR5d+vMdFGvZYh4vVwatnufLTU0oo6xRvwb8TGCA3UwggNxAgEBMIHBMIGs MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNp Z24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBD QQIQf+TLYwPQqz63JtfN0kAP8TAJBgUrDgMCGgUAoIICCTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MDkxMzIwNDdaMCMGCSqGSIb3DQEJBDEWBBR235muCoow YX38/4vI3lnwkiU+gTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQf+TLYwPQqz63JtfN0kAP8TCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJt cyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJp U2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB/5MtjA9CrPrcm183SQA/xMA0GCSqGSIb3DQEBAQUA BIGAWOOl+OvMzOD1aGppQOTxGTWGeAXnHuMicuQl3MLiblMhYqU3h6kZQnSkmiTctQKGgAyaTlpz XkpxAZBSiDrgnJQmXaOsTx6AJseSRQ9z7+T64moE/v9n7qycIMqUhzImU4jgYZYE58soI4gRsK/F QVzAWsWpcI7vauZT2qre/rsAAAAAAAA= --Apple-Mail-23-634729673-- -- to unsubscribe send a message to namedroppers-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 Jun 9 07:57:58 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259FD3A6C3E; Mon, 9 Jun 2008 07:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.987 X-Spam-Level: X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQTy3ijCIXKG; Mon, 9 Jun 2008 07:57:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41B5E3A6BD3; Mon, 9 Jun 2008 07:57:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5ihA-000O3z-Bw for namedroppers-data@psg.com; Mon, 09 Jun 2008 14:50:04 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5ih2-000O26-IF for namedroppers@ops.ietf.org; Mon, 09 Jun 2008 14:49:58 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m59EngMC080161; Mon, 9 Jun 2008 10:49:43 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20080605155819.GA16165@commandprompt.com> <43009.1212805787@sa.vix.com> Date: Mon, 9 Jun 2008 10:49:43 -0400 To: "Roy Arends" From: Edward Lewis Subject: Re: Confusion about trust anchors and DS records from the parent? Cc: Olaf Kolkman , IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 7:03 +0200 6/9/08, Roy Arends wrote: >Olaf Kolkman wrote on 06/09/2008 06:34:48 AM: > >> Anyhow I can consent with keeping the closest trust-anchor as authority. > >As an option, or as the default? I would opine that the on-line learned key is superior to the statically configured trust anchor. Yeah, I know it's safer to trust the disk than ether, but the ether is probably more fresh. And "superior" doesn't necessarily mean more trustworthy. If the TV news says the bridge was washed out by the storm but your hand drawn map made last week shows there is a open bridge, what do you rely on? Even if the news report was sandwiched between a report of an alien abduction and the presentation of the lottery numbers? I bet you'd trust that the bridge was unusable. Ultimately, to avoid security just making the system more brittle and rigid, if there is a verifiable copy of the data, go for it. But maybe more cautiously if there are conflicting reports. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Mon Jun 9 09:47:33 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4633A6B75; Mon, 9 Jun 2008 09:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d0Wup7-Y4Yj; Mon, 9 Jun 2008 09:47:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF5033A68EB; Mon, 9 Jun 2008 09:47:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5kPi-000GUP-Ql for namedroppers-data@psg.com; Mon, 09 Jun 2008 16:40:10 +0000 Received: from [81.91.160.182] (helo=office.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5kPY-000GSD-8m for namedroppers@ops.ietf.org; Mon, 09 Jun 2008 16:40:04 +0000 Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1K5kPV-0003LT-PV; Mon, 09 Jun 2008 18:39:57 +0200 Received: from localhost by x27.adm.denic.de with local id 1K5kOh-0003Xy-EQ; Mon, 09 Jun 2008 18:39:07 +0200 Date: Mon, 9 Jun 2008 18:39:07 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080609163907.GB10231@x27.adm.denic.de> References: <20080605155819.GA16165@commandprompt.com> <43009.1212805787@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 09, 2008 at 06:34:48AM +0200, Olaf Kolkman wrote: > 1++, bis needs clarification. agreed. > policy. The update document should be very clear about what the > default is and allow for other use-cases. I can subscribe to both the > use case where closest trust-anchor is authoritative for the > validation and the use case where the chain of trust overwrites the > closest trust-anchor. For the latter I can see many different policies. Thinking of the introduction of DNSSEC for e164.arpa, where the zone was signed without publishing DS RRs for a couple of months, we might need both ways, so a logical "or" seems reasonable to me. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 9 09:55:28 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745533A6C63; Mon, 9 Jun 2008 09:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.365 X-Spam-Level: X-Spam-Status: No, score=-1.365 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieglJOXnqxv6; Mon, 9 Jun 2008 09:55:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2FB3E3A6C67; Mon, 9 Jun 2008 09:55:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5kam-000IAz-6L for namedroppers-data@psg.com; Mon, 09 Jun 2008 16:51:36 +0000 Received: from [76.96.62.40] (helo=QMTA04.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5kaZ-000I7F-Hn for namedroppers@ops.ietf.org; Mon, 09 Jun 2008 16:51:34 +0000 Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA04.westchester.pa.mail.comcast.net with comcast id bpgk1Z00L17dt5G540Kp00; Mon, 09 Jun 2008 16:51:22 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA13.westchester.pa.mail.comcast.net with comcast id bsrH1Z00F2P9w053ZsrHa8; Mon, 09 Jun 2008 16:51:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=O9aPfwluJOIA:10 a=Ifs8zq1En8cA:10 a=10CFcY03AAAA:8 a=48vgC7mUAAAA:8 a=naSM2-NUNYqgg-e3XxIA:9 a=iDouLJWvsnRWJjF0YyQA:7 a=TDhHFbdYLTU_mo5dTB13Endvc9UA:4 a=iyt2JYO3dpYA:10 a=GEO3fhvhlRQA:10 a=iw4bf7yTzGQA:10 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Jun 2008 12:51:18 -0400 To: Mark Andrews , Andrew Sullivan ,paul@vix.com From: Michael StJohns Subject: Re: Confusion about trust anchors and DS records from the parent? Cc: namedroppers@ops.ietf.org In-Reply-To: <200806060300.m563094R099294@drugs.dv.isc.org> References: <200806060300.m563094R099294@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 11:00 PM 6/5/2008, Mark Andrews wrote: >> On Fri, Jun 06, 2008 at 10:19:30AM +1000, Mark Andrews wrote: >> >> > If I have a private version of a zone that it signed and a >> > public version of the same zone zone that is signed. Then >> > by configuring the private trust anchor the validator will >> > reject anything that leaks from the public zone. >> >> I understand this use case, but it's also what's troubling me about >> the behaviour. There's nothing anywhere in the protocol, as near as I >> can tell, to indicate anything like "degrees of trust". The reported >> behaviour appears to be sneaking that functionality in through the >> back door. I'm asking whether we want that functionality; and, if we >> do, whether the documents as they stand are clear enough on this or >> whether we need clarifying text. > > There is no sneaking anything here. These use case have > been discussed for years. I don't think anyone thought one > would ever want to go back past a trust anchor which failed > to validate the matching DNSKEY RRset and to then look for a > higher trust anchor. In my thinking it is a dangerous policy. I delayed a response hoping you'd explain why you think this is a "dangerous policy". Your approach is a violation of the "be generous in what you accept" principle. Granted that for "security" reasons, we sometimes violate this, but I doubt there are any reasonable security reasons for not allowing a DNSKEY RRSet to be validated by chaining even if you've got a trust anchor for the sub zone that doesn't validate the RRSet. Look, the in-band signalling of whether a trust anchor for a zone is still valid (RFC5011 for example) is, due to the nature of DNS, a very loosely coupled protocol. It's possible the termination of publication of separate trust anchors for the zone following the security adoption (e.g. publishing of DS records) of a signed subzone by its parent could be missed by a resolver, either due to timing issues or due to the zone owner fumbling the process. The resolver may have a chainable signature through a DS record pointing to a SEP DNSKey that signs the apex DNSKey RRSet while still having a DNSKey trust anchor that no longer is part of that RRSet. Under your rules, that zone, although validly signed, would be considered bogus. Vixie posted: >i would like to retain the option, non-default, of requiring that a zone use >a key that i have an anchor for. but just as any RRSIG->DNSKEY->DS chain >that works causes success, even if some don't work, so it should be, by >default, that if a trust anchor isn't needed, it won't be used, and so it >won't matter whether or not it would work if tried. I can't parse this. The first part says "I want to use the trust anchor", but I think the second part says "If I'm able to validate by not using a trust anchor (?? by chaining ??) then I won't use the trust anchor"? Or did you mean - "If I have trust anchors configured for a zone, then I want the option to try validation with them and only them and if any trust anchor validates, then the zone validates otherwise it does not validate regardless of whether it validly chains"? As Olaf notes in one of his emails, local policy may certainly be specified. I'd recommend against permitting your suggestion (trust anchor only validation) as a local policy because it increases the fragility of the system without providing any security (my opinion) - but wouldn't argue too strenuously as long as the default is that any validation path validates the zone. I'd hope that you (or Mark) would provide additional text as to why a resolver owner might turn on the trust-anchor-only-validate option as a condition for adding the option to the text of the revision. Mike > Mark > >> A >> >> -- >> Andrew Sullivan >> ajs@commandprompt.com >> +1 503 667 4564 x104 >> http://www.commandprompt.com/ >-- >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 Mon Jun 9 14:27:16 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B233A6A57; Mon, 9 Jun 2008 14:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.75 X-Spam-Level: X-Spam-Status: No, score=-3.75 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAiOX9ChYPUP; Mon, 9 Jun 2008 14:27:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 604763A6A55; Mon, 9 Jun 2008 14:27:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5oma-0001Zr-6u for namedroppers-data@psg.com; Mon, 09 Jun 2008 21:20:04 +0000 Received: from [81.91.160.182] (helo=office.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5omW-0001Yp-65 for namedroppers@ops.ietf.org; Mon, 09 Jun 2008 21:20:02 +0000 Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1K5omQ-0007ZI-Co; Mon, 09 Jun 2008 23:19:54 +0200 Received: from localhost by x27.adm.denic.de with local id 1K5olb-0005jp-UT; Mon, 09 Jun 2008 23:19:03 +0200 Date: Mon, 9 Jun 2008 23:19:03 +0200 From: Peter Koch To: Francis Dupont Cc: IETF DNSEXT WG Subject: Re: Adopt draft-dupont-dnsext-tsig-md5-deprecated as WG draft? Message-ID: <20080609211903.GF14279@x27.adm.denic.de> References: <20080529190820.GA27248@unknown.office.denic.de> <200805311326.m4VDQlrq047330@givry.fdupont.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200805311326.m4VDQlrq047330@givry.fdupont.fr> User-Agent: Mutt/1.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hi Francis, thanks for your explanations. > > But it failed to deprecate the HMAC MD5 algorithm. This document is > > targeted to correct this point, in details: > > This was a conscious decision at that time, IIRC, wasn't it? > > => I don't know, perhaps it was too soon? the current wording makes it look like an oversight, where it probably was intentional. > > 2. IANA Considerations > > Move this to the end. > > => it is the usual position but is it mandatory? As far as I know > it is only required to have an IANA section... If you can find > another document which is mainly about an IANA registry update, > I propose to use it as an example. RFC 5226 says: - The IANA Considerations section should summarize all of the IANA actions, with pointers to the relevant sections elsewhere in the document as appropriate. But in the end IANA needs to be happy with it ... > Strictly procedurally I do not think a comment in the registry is a good > idea. I'd rather have "this" document added to the references list of > "HMAC-MD5.SIG-ALG.REG.INT". RFC 3110 set a precedent, but that registry > "DNSSEC Algorithm Numbers" already had a "Description" field. > An implementer would have to consult the requirements levels anyway, > which are part of neither of these registries. (The second sentence > above isn't really necessary ;-) > > => I proposed to follow strictly the RFC 3110 precedent... The IANA > shall say what they think about this. Well, yes and know - but let's follow your suggestion and ask IANA first. > There's no reference in RFC 4635 explaining what "Optional" and "Mandatory" > actually mean, so why not label HMAC-MD5.SIG-ALG.REG.INT "Deprecated" here? > > => this is more radical I confess. It's probably more clear. The IANA registry just lists identifiers without mapping them to, say, a number like for QTYPEs. So, freeing the old identifier is not an option to avoid later collisions. So, regarding the registry, one would somehow convey the message that someone browsing the list need not bother implementing the outdated algorithm. The actual registry, however, doesn't contain any requirements level information, so adding that in the draft under consideration looks more straight forward to me. > => I prefer SHA-256 which is the official name but '-' is misleading > in a formula so this is a valid exception IMHO. I note to add a reference. Good luck for AUTH48 on the '-' ... > What would "amended into" mean? are both algorithms now equally available > (and distinguished by length)? Or should SHA256 replace MD5 and if yes, > wouldn't that be a backwards compatibility issue? > > => I don't understand your comment: I proposed to replace MD5 by SHA-256 > keeping other things (in particular padding) equal. There is no > compatibility issue other the computed shared secrets will very likely > be different. This would introduce a hard cut-over, where with TSIG we have a smooth migration from MD5 through SHA1 to SHA-2*. If MD5 is instantly deprecated and replaced by SHA-2, there's no lowest common denominator for two implementations. I must admit, though, I don't know how much operational relevance this really has. > Agree with Ed here that a reason for the deprecation of HMAC-MD5 must be > given, especially since we've heard that this particular use would not > be susceptible to the same attacks as MD5 in digital signatures. > > => the reason is MD5 is today considered as too weak for any use. That we'd need a reference for! > but pragmatic, expecting the removal of md5 from crypto libraries or > enabling the implementor to remove it from their product. > > => this is more than "expecting": a FIPS 140-2 compliant crypto module > implements only approved algorithms and MD5 is *not* approved. OK, sounds like a reason. > this advice. One might argue they should at least be able to use SHA-1, > but then deprecating SHA-1 is around the corner, as well. Maybe it > should be explicitly recommended against its use as of now? > > => HMAC-SHA256 is marked as mandatory in the RFC 4635 table as using it > should not be a problem, at least no more a problem than HMAC-SHA1. > IMHO it is too soon to deprecate or even change the requirement level > for HMAC-SHA1 but I took benefit of this document to introduce a new(*) > recommendation and jumped directly to SHA-256. There's a difference between deprecating its use and deprecating its implementation. While SHA1 should continue to be implemented, maybe the _use_ of SHA-2 could be recommended (if that makes sense cryptographically or library wise). > > Olafur Gudmundsson kindly helped in the procedure to deprecate the > > MD5 usage in TSIG, i.e., the procedure which gave this memo. > > What conspiracy was this? :-) > > => you'd like to be in? (:-) "There is no conspiracy." On the first read it looked like MD5 was already magicly deprecated, where the draft will just initiate just that once it will be approved ;-) Best regards, Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 10 06:19:51 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF583A687A; Tue, 10 Jun 2008 06:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSNJq1AjmZSQ; Tue, 10 Jun 2008 06:19:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 22F273A6A83; Tue, 10 Jun 2008 06:19:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K63aY-00013F-PY for namedroppers-data@psg.com; Tue, 10 Jun 2008 13:08:38 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K63aM-00011h-Rw for namedroppers@ops.ietf.org; Tue, 10 Jun 2008 13:08:36 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m5AD3AxG022479; Tue, 10 Jun 2008 13:03:10 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m5AD33a9022478; Tue, 10 Jun 2008 13:03:03 GMT Date: Tue, 10 Jun 2008 13:03:03 +0000 From: bmanning@vacation.karoshi.com To: David Blacka Cc: Olaf Kolkman , IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080610130303.GA22418@vacation.karoshi.com.> References: <20080605155819.GA16165@commandprompt.com> <43009.1212805787@sa.vix.com> <7AAEA0F6-22C7-4902-B1D1-A6AB5AC3BF04@verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7AAEA0F6-22C7-4902-B1D1-A6AB5AC3BF04@verisign.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 09, 2008 at 09:20:47AM -0400, David Blacka wrote: > > On Jun 9, 2008, at 12:34 AM, Olaf Kolkman wrote: > > > >During DNSSEC bis development we have used the stop-gap local policy > >in many cases and I believe this was one. > > > > > >I would argue that one would like to retain an option for (any) > >local policy. The update document should be very clear about what > >the default is and allow for other use-cases. I can subscribe to > >both the use case where closest trust-anchor is authoritative for > >the validation and the use case where the chain of trust overwrites > >the closest trust-anchor. For the latter I can see many different > >policies. > > To be clear, I don't think anyone suggested having the chain of trust > "overwrite" the closest trust anchor. Instead, the suggestion was > simply to try all trust anchors until one succeeded. > > -- > David Blacka > Sr. Engineer VeriSign Platform Product Development > > > > > > actually, this may be the wrong alogrithm. trust comes in degrees. one thing we tried was where the closer to the root, the less trust in the anchor - based on the presumption that one trusts ones peers (the folks "closest" to me in the naming heirarchy) more than folks farther away from me in the naming heirarchy. similar arguments can and have been made regarding key lengths; e.g. the closer to the root, the longer the key length. --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 Jun 10 08:32:50 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C195E3A6873; Tue, 10 Jun 2008 08:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DI3RSTF7RbTc; Tue, 10 Jun 2008 08:32:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D9A23A6806; Tue, 10 Jun 2008 08:32:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K65iL-000GxR-P4 for namedroppers-data@psg.com; Tue, 10 Jun 2008 15:24:49 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K65iA-000Gvb-Jt for namedroppers@ops.ietf.org; Tue, 10 Jun 2008 15:24:43 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m5AFOZ4V028002; Tue, 10 Jun 2008 17:24:35 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200806101524.m5AFOZ4V028002@givry.fdupont.fr> From: Francis Dupont To: Peter Koch cc: IETF DNSEXT WG Subject: Re: Adopt draft-dupont-dnsext-tsig-md5-deprecated as WG draft? In-reply-to: Your message of Mon, 09 Jun 2008 23:19:03 +0200. <20080609211903.GF14279@x27.adm.denic.de> Date: Tue, 10 Jun 2008 17:24:35 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: > This was a conscious decision at that time, IIRC, wasn't it? > > => I don't know, perhaps it was too soon? the current wording makes it look like an oversight, where it probably was intentional. => it was (according to Olafur). So I've to improve the wording. This would introduce a hard cut-over, where with TSIG we have a smooth migration from MD5 through SHA1 to SHA-2*. If MD5 is instantly deprecated and replaced by SHA-2, there's no lowest common denominator for two implementations. I must admit, though, I don't know how much operational relevance this really has. => it is an indirect and private usage: indirect because it is only about how to derive a key, private because both parties must already trust together. IMHO the best is to minimize choices so SHA-1 should be avoided. > => the reason is MD5 is today considered as too weak for any use. That we'd need a reference for! => I have a nice one. There's a difference between deprecating its use and deprecating its implementation. While SHA1 should continue to be implemented, maybe the _use_ of SHA-2 could be recommended (if that makes sense cryptographically or library wise). => this is exactly what I am trying to propose. Thanks Francis.Dupont@fdupont.fr -- to unsubscribe send a message to namedroppers-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 Jun 10 11:06:00 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB38D3A68BD; Tue, 10 Jun 2008 11:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 478dlEhg+rP5; Tue, 10 Jun 2008 11:05:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE5E43A6873; Tue, 10 Jun 2008 11:05:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K686P-00096c-PG for namedroppers-data@psg.com; Tue, 10 Jun 2008 17:57:49 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K686L-00095q-J8 for namedroppers@ops.ietf.org; Tue, 10 Jun 2008 17:57:47 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AHvhEk094024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 10:57:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080610130303.GA22418@vacation.karoshi.com.> References: <20080605155819.GA16165@commandprompt.com> <43009.1212805787@sa.vix.com> <7AAEA0F6-22C7-4902-B1D1-A6AB5AC3BF04@verisign.com> <20080610130303.GA22418@vacation.karoshi.com.> Date: Tue, 10 Jun 2008 10:55:44 -0700 To: bmanning@vacation.karoshi.com From: Paul Hoffman Subject: Re: Confusion about trust anchors and DS records from the parent? Cc: IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 1:03 PM +0000 6/10/08, bmanning@vacation.karoshi.com wrote: > actually, this may be the wrong alogrithm. > trust comes in degrees. In people, yes definitely. In protocols, rarely. Where in DNSSEC are "degrees of trust" described? > one thing we tried was > where the closer to the root, the less trust in the > anchor - based on the presumption that one trusts ones > peers (the folks "closest" to me in the naming heirarchy) > more than folks farther away from me in the naming heirarchy. Given that we're talking about trust anchors installed in DNSSEC resolvers, what makes a particular resolver "closer to the root" for this algorithm? --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 10 15:58:48 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D403A6895; Tue, 10 Jun 2008 15:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmVHtmIY4Zft; Tue, 10 Jun 2008 15:58:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B6063A68C7; Tue, 10 Jun 2008 15:58:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Cf3-000Jml-Rz for namedroppers-data@psg.com; Tue, 10 Jun 2008 22:49:53 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Ceo-000JlV-W5 for namedroppers@ops.ietf.org; Tue, 10 Jun 2008 22:49:42 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m5AMmYxG027718; Tue, 10 Jun 2008 22:48:34 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m5AMmXlC027717; Tue, 10 Jun 2008 22:48:33 GMT Date: Tue, 10 Jun 2008 22:48:33 +0000 From: bmanning@vacation.karoshi.com To: Paul Hoffman Cc: bmanning@vacation.karoshi.com, IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080610224833.GA27668@vacation.karoshi.com.> References: <20080605155819.GA16165@commandprompt.com> <43009.1212805787@sa.vix.com> <7AAEA0F6-22C7-4902-B1D1-A6AB5AC3BF04@verisign.com> <20080610130303.GA22418@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jun 10, 2008 at 10:55:44AM -0700, Paul Hoffman wrote: > At 1:03 PM +0000 6/10/08, bmanning@vacation.karoshi.com wrote: > > actually, this may be the wrong alogrithm. > > trust comes in degrees. > > In people, yes definitely. In protocols, rarely. Where in DNSSEC are > "degrees of trust" described? DNSSEC treats all trust as atomic. This is (imho) a weakness, -IF- one presumes all atomic transactions are equally valid. > > > one thing we tried was > > where the closer to the root, the less trust in the > > anchor - based on the presumption that one trusts ones > > peers (the folks "closest" to me in the naming heirarchy) > > more than folks farther away from me in the naming heirarchy. > > Given that we're talking about trust anchors installed in DNSSEC > resolvers, what makes a particular resolver "closer to the root" for > this algorithm? trust anchors that are for points nearer to me in the name heirarchy are closer to me than points farther away. e.g. if I am the node bill.gov.br. - i would likley have a local policy to have a higher confidence in the "gov.br" trust anchor than in either the "br" or "." trust anchor. -bill > > --Paul Hoffman, Director > --VPN Consortium > > -- > to 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 Jun 10 16:32:23 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6443A6849; Tue, 10 Jun 2008 16:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaEA76inDpWd; Tue, 10 Jun 2008 16:32:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 52C3E3A67EE; Tue, 10 Jun 2008 16:32:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6DGl-000OHA-QH for namedroppers-data@psg.com; Tue, 10 Jun 2008 23:28:51 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6DGi-000OGZ-3d for namedroppers@ops.ietf.org; Tue, 10 Jun 2008 23:28:50 +0000 Received: from [0.0.0.0] (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5ANSdxb002281; Tue, 10 Jun 2008 19:28:40 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080610224833.GA27668@vacation.karoshi.com.> References: <20080605155819.GA16165@commandprompt.com> <43009.1212805787@sa.vix.com> <7AAEA0F6-22C7-4902-B1D1-A6AB5AC3BF04@verisign.com> <20080610130303.GA22418@vacation.karoshi.com.> <20080610224833.GA27668@vacation.karoshi.com.> Date: Tue, 10 Jun 2008 19:25:12 -0400 To: IETF DNSEXT WG From: Edward Lewis Subject: Re: Confusion about trust anchors and DS records from the parent? Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 22:48 +0000 6/10/08, bmanning@vacation.karoshi.com wrote: > DNSSEC treats all trust as atomic. This is (imho) a weakness, > -IF- one presumes all atomic transactions are equally valid. But the entire question being answered by DNSSEC is "did this record come from the appropriate zone admin? Yes or no?" It's not like, "well www.bill.mars. has an v4address of 287.214.11.78, +/- 6." DNSSEC will tell you if the record came from the signer. It can't and won't tell you if the record is the freshest, most accurate, or best. That's because those capabilities didn't exist in DNS when we started. We can't do freshest because DNS lacks time. We can't do accurate because admins have historically fat fingers. We can't to best because, well, that depends on what the measure is. We only hardened the pipes. We didn't bend them. Although we tried. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Tue Jun 10 18:46:38 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893433A67AF; Tue, 10 Jun 2008 18:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbUAM8ROBRve; Tue, 10 Jun 2008 18:46:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 471BF3A6768; Tue, 10 Jun 2008 18:46:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6FKK-000GTb-Vv for namedroppers-data@psg.com; Wed, 11 Jun 2008 01:40:40 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6FKH-000GT2-9x for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 01:40:39 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m5B1dVxG028866; Wed, 11 Jun 2008 01:39:31 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m5B1dSrj028865; Wed, 11 Jun 2008 01:39:28 GMT Date: Wed, 11 Jun 2008 01:39:28 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080611013928.GB28799@vacation.karoshi.com.> References: <20080605155819.GA16165@commandprompt.com> <43009.1212805787@sa.vix.com> <7AAEA0F6-22C7-4902-B1D1-A6AB5AC3BF04@verisign.com> <20080610130303.GA22418@vacation.karoshi.com.> <20080610224833.GA27668@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jun 10, 2008 at 07:25:12PM -0400, Edward Lewis wrote: > At 22:48 +0000 6/10/08, bmanning@vacation.karoshi.com wrote: > > > DNSSEC treats all trust as atomic. This is (imho) a weakness, > > -IF- one presumes all atomic transactions are equally valid. > > But the entire question being answered by DNSSEC is "did this record > come from the appropriate zone admin? Yes or no?" > > It's not like, "well www.bill.mars. has an v4address of 287.214.11.78, +/- > 6." > > DNSSEC will tell you if the record came from the signer. It can't > and won't tell you if the record is the freshest, most accurate, or > best. That's because those capabilities didn't exist in DNS when we > started. > > We can't do freshest because DNS lacks time. > We can't do accurate because admins have historically fat fingers. > We can't to best because, well, that depends on what the measure is. > > We only hardened the pipes. We didn't bend them. > > Although we tried. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 so, young Ed. what happens when this validator gets back -two- answers with different data? I know, always use the first one back - cause all we got is QUERY. So we do "freshest" where that is the first thing back. (me, on the other hand, I have DISCOVER, so I can get multiple replies and have to figure out what happens when near duplicates occur...) trying to do "best" - where best is defined as local policy. --bill (still bending pipes in the basement...) -- to unsubscribe send a message to namedroppers-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 Jun 10 20:21:14 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9002A3A67D1; Tue, 10 Jun 2008 20:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekIQfn0ZlQcg; Tue, 10 Jun 2008 20:21:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA2CC3A677D; Tue, 10 Jun 2008 20:21:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6GjO-00014K-VG for namedroppers-data@psg.com; Wed, 11 Jun 2008 03:10:38 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6GjL-00013Y-5u for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 03:10:37 +0000 Received: from [192.168.1.101] (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5B3AOUK003748; Tue, 10 Jun 2008 23:10:25 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080611013928.GB28799@vacation.karoshi.com.> References: <20080605155819.GA16165@commandprompt.com> <43009.1212805787@sa.vix.com> <7AAEA0F6-22C7-4902-B1D1-A6AB5AC3BF04@verisign.com> <20080610130303.GA22418@vacation.karoshi.com.> <20080610224833.GA27668@vacation.karoshi.com.> <20080611013928.GB28799@vacation.karoshi.com.> Date: Tue, 10 Jun 2008 23:10:17 -0400 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: Confusion about trust anchors and DS records from the parent? Cc: Edward Lewis , IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 1:39 +0000 6/11/08, bmanning@vacation.karoshi.com wrote: > so, young Ed. > > what happens when this validator gets back -two- answers with > different data? I know, always use the first one back - cause > all we got is QUERY. So we do "freshest" where that is the first > thing back. > > (me, on the other hand, I have DISCOVER, > so I can get multiple replies and have to figure out what happens > when near duplicates occur...) > > trying to do "best" - where best is defined as local policy. > >--bill (still bending pipes in the basement...) So, wizened sage Bill, For years "resolvers" (in the days before validators) would just get the first arrival, fold up the socket and pass on the result. Once we added the SIG record (and then whatever they are now) with expirations and inception times we thought we had introduced absolute time to the DNS and the ability to handle multiple answers. Oh what fools we were! I remember a phone call one day, I was at that house on the Severn. Great place, scenic, quiet and restful. As I paced the deck I was on a call listening to our illustrious WG chair tell me about a goofy idea to use the expiration and inception times for "a good purpose." The problem was and still is is that the inception and expiration times are not time stamps! What if I sign an A record set with key A for 1-7/6/2008 (as in June 1st-7th), and key B for 8-14/6/2008. Then I find that, in three days, the set is wrong and I sign it with key C for 4-10/6/2008. Which is "fresher"? The signature for 8-14/6 or 4-10/6? The former was signed first but has a later effectivity. You want duplicates? An exchange between Lt. Kaffee and Col. Jessep comes to mind: Kaffee: "I want the duplicate!" Jessep: "You can't handle the duplicate!" -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Jun 11 03:04:21 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520703A6A98; Wed, 11 Jun 2008 03:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYJwh+FxVKK6; Wed, 11 Jun 2008 03:04:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B03853A6A47; Wed, 11 Jun 2008 03:04:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6N4D-0004mr-Qs for namedroppers-data@psg.com; Wed, 11 Jun 2008 09:56:33 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6N49-0004mG-7X for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 09:56:31 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 0BD55114021 for ; Wed, 11 Jun 2008 09:56:24 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id BD44EE6023 for ; Wed, 11 Jun 2008 09:56: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.14.2/8.14.2) with ESMTP id m5B9t6a9003385; Wed, 11 Jun 2008 19:55:09 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806110955.m5B9t6a9003385@drugs.dv.isc.org> To: Michael StJohns Cc: Andrew Sullivan , Paul_Vixie@isc.org, namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Confusion about trust anchors and DS records from the parent? In-reply-to: Your message of "Mon, 09 Jun 2008 12:51:18 -0400." <20080609165127.27385114050@mx.isc.org> Date: Wed, 11 Jun 2008 19:55:06 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > At 11:00 PM 6/5/2008, Mark Andrews wrote: > > >> On Fri, Jun 06, 2008 at 10:19:30AM +1000, Mark Andrews wrote: > >> > >> > If I have a private version of a zone that it signed and a > >> > public version of the same zone zone that is signed. Then > >> > by configuring the private trust anchor the validator will > >> > reject anything that leaks from the public zone. > >> > >> I understand this use case, but it's also what's troubling me about > >> the behaviour. There's nothing anywhere in the protocol, as near as I > >> can tell, to indicate anything like "degrees of trust". The reported > >> behaviour appears to be sneaking that functionality in through the > >> back door. I'm asking whether we want that functionality; and, if we > >> do, whether the documents as they stand are clear enough on this or > >> whether we need clarifying text. > > > > There is no sneaking anything here. These use case have > > been discussed for years. I don't think anyone thought one > > would ever want to go back past a trust anchor which failed > > to validate the matching DNSKEY RRset and to then look for a > > higher trust anchor. In my thinking it is a dangerous policy. > > I delayed a response hoping you'd explain why you think this is a "dangerous > policy". Please look back at my previous usage examples. They all give "bad" results if you follow the DS rather that rejecting the answer when it fails to match a configured TA. > Your approach is a violation of the "be generous in what you accept" principl > e. Granted that for "security" reasons, we sometimes violate this, but I do > ubt there are any reasonable security reasons for not allowing a DNSKEY RRSet > to be validated by chaining even if you've got a trust anchor for the sub zo > ne that doesn't validate the RRSet. > > Look, the in-band signalling of whether a trust anchor for a zone is still va > lid (RFC5011 for example) is, due to the nature of DNS, a very loosely couple > d protocol. It's possible the termination of publication of separate trust > anchors for the zone following the security adoption (e.g. publishing of DS r > ecords) of a signed subzone by its parent could be missed by a resolver, eith > er due to timing issues or due to the zone owner fumbling the process. The > resolver may have a chainable signature through a DS record pointing to a SE > P DNSKey that signs the apex DNSKey RRSet while still having a DNSKey trust a > nchor that no longer is part of that RRSet. Under your rules, that zone, alt > hough validly signed, would be considered bogus. Correct. But you have to ask "Why was the TA configured when there is a higher TA configured and a valid trust chain from that TA despite knowing that TA tracking is error prone?" This is the long term state of validator management. Extra TA are not added on a whim. People are complaining at the moment because were are in a grow from the bottom expansion. Islands are being joined together etc. This is not long term behaviour. It will switch to top down as the TLD's start to sign delegations. People will remove TA's that are unnecessary as that reduces the maintenance effort required. It will be test and remove. > Vixie posted: > >i would like to retain the option, non-default, of requiring that a zone use > >a key that i have an anchor for. but just as any RRSIG->DNSKEY->DS chain > >that works causes success, even if some don't work, so it should be, by > >default, that if a trust anchor isn't needed, it won't be used, and so it > >won't matter whether or not it would work if tried. > > I can't parse this. The first part says "I want to use the trust anchor", bu > t I think the second part says "If I'm able to validate by not using a trust > anchor (?? by chaining ??) then I won't use the trust anchor"? Or did you me > an - "If I have trust anchors configured for a zone, then I want the option t > o try validation with them and only them and if any trust anchor validates, t > hen the zone validates otherwise it does not validate regardless of whether i > t validly chains"? > > > As Olaf notes in one of his emails, local policy may certainly be specified. > I'd recommend against permitting your suggestion (trust anchor only validati > on) as a local policy because it increases the fragility of the system withou > t providing any security (my opinion) - but wouldn't argue too strenuously as > long as the default is that any validation path validates the zone. I'd hop > e that you (or Mark) would provide additional text as to why a resolver owner > might turn on the trust-anchor-only-validate option as a condition for addin > g the option to the text of the revision. > > Mike > > > > > > Mark > > > >> A > >> > >> -- > >> Andrew Sullivan > >> ajs@commandprompt.com > >> +1 503 667 4564 x104 > >> http://www.commandprompt.com/ > >-- > >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: > > -- 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 Jun 11 03:30:02 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 460553A6994; Wed, 11 Jun 2008 03:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRWjHYMPk8Xv; Wed, 11 Jun 2008 03:30:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 40E033A6A22; Wed, 11 Jun 2008 03:30:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6NVV-0008Ni-C5 for namedroppers-data@psg.com; Wed, 11 Jun 2008 10:24:45 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6NVH-0008ME-Kz for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 10:24:42 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id C438111402C for ; Wed, 11 Jun 2008 10:24:29 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id DA092E6020 for ; Wed, 11 Jun 2008 10:24:28 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m5BAO7Yx003903; Wed, 11 Jun 2008 20:24:10 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806111024.m5BAO7Yx003903@drugs.dv.isc.org> To: Edward Lewis Cc: IETF DNSEXT WG From: Mark Andrews Subject: Re: Confusion about trust anchors and DS records from the parent? In-reply-to: Your message of "Tue, 10 Jun 2008 19:25:12 -0400." Date: Wed, 11 Jun 2008 20:24:07 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > At 22:48 +0000 6/10/08, bmanning@vacation.karoshi.com wrote: > > > DNSSEC treats all trust as atomic. This is (imho) a weakness, > > -IF- one presumes all atomic transactions are equally valid. > > But the entire question being answered by DNSSEC is "did this record > come from the appropriate zone admin? Yes or no?" I'm the zone admin. I know what my trust anchor is. I've configured it into named.conf. I don't want named trusting anything that doesn't verify against the trust anchor that I have in my config. The fact that I also have a trust anchor for higher up the tree does not change say that I want to accept answers that don't validate against my trust anchor. The trust anchor for higher up in the tree is for my neibours, not for my own zone. > It's not like, "well www.bill.mars. has an v4address of 287.214.11.78, +/- 6. > " > > DNSSEC will tell you if the record came from the signer. It can't > and won't tell you if the record is the freshest, most accurate, or > best. That's because those capabilities didn't exist in DNS when we > started. > > We can't do freshest because DNS lacks time. > We can't do accurate because admins have historically fat fingers. > We can't to best because, well, that depends on what the measure is. > > We only hardened the pipes. We didn't bend them. > > Although we tried. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Never confuse activity with progress. Activity pays 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: -- 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 Jun 11 04:47:29 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 739AB3A6A20; Wed, 11 Jun 2008 04:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.734 X-Spam-Level: X-Spam-Status: No, score=0.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yro6imGoM+f; Wed, 11 Jun 2008 04:47:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 282523A6AA1; Wed, 11 Jun 2008 04:47:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6OfT-000I1R-9z for namedroppers-data@psg.com; Wed, 11 Jun 2008 11:39:07 +0000 Received: from [69.46.124.26] (helo=outbound.afilias.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6OfN-000I0n-Va for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 11:39:03 +0000 Received: from bmp-336-ms505.wa.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1K6OfJ-0005vx-6K; Wed, 11 Jun 2008 11:38:58 +0000 Cc: IETF DNSEXT WG Message-Id: <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> From: Shane Kerr To: Mark Andrews In-Reply-To: <200806111024.m5BAO7Yx003903@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: Confusion about trust anchors and DS records from the parent? Date: Wed, 11 Jun 2008 13:38:56 +0200 References: <200806111024.m5BAO7Yx003903@drugs.dv.isc.org> X-Mailer: Apple Mail (2.924) X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark, On Jun 11, 2008, at 12:24 +0200, Mark Andrews wrote: > > I'm the zone admin. I know what my trust anchor is. I've > configured it into named.conf. I don't want named trusting > anything that doesn't verify against the trust anchor that > I have in my config. The fact that I also have a trust anchor > for higher up the tree does not change say that I want to accept > answers that don't validate against my trust anchor. The trust > anchor for higher up in the tree is for my neibours, not for > my own zone. If you're the zone administrator, why didn't you send your DS record to your parent zone? Or did your parent somehow publish a DS record without your permission? In either case, why do you trust your parent to publish NS records (not authoritative I know, but resolvers have no way to find your servers without them), but not DS records? To be honest, I think it is perfectly acceptable for software to implement this if for some reason an administrator actually wants this behavior. But the general case will be for someone (not the zone administrator) to forget they configured a trust anchor locally and suffer some period of breakage until they figure out why DNS stops working when going to a specific domain, after the administrators of that zone publish DS records in their parent and they stop maintaining a separate trust anchor. DNSSEC should tend towards not breaking, if at all possible, especially considering the state of the debugging tools right now. :-/ So, is there any objection to making the default a logical-OR of all trust chains, but allowing local configuration to override that? (I think this is what Olaf was suggesting.) -- Shane -- to unsubscribe send a message to namedroppers-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 Jun 11 05:10:49 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C1523A68C3; Wed, 11 Jun 2008 05:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.42 X-Spam-Level: X-Spam-Status: No, score=-4.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecjimJDTFwue; Wed, 11 Jun 2008 05:10:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B9B03A67ED; Wed, 11 Jun 2008 05:10:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6P4m-000LF8-Th for namedroppers-data@psg.com; Wed, 11 Jun 2008 12:05:16 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6P4f-000LEL-77 for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 12:05:14 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m5BC43xG013498; Wed, 11 Jun 2008 12:04:03 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m5BC43SU013497; Wed, 11 Jun 2008 12:04:03 GMT Date: Wed, 11 Jun 2008 12:04:03 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: bmanning@vacation.karoshi.com, IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080611120403.GB13231@vacation.karoshi.com.> References: <43009.1212805787@sa.vix.com> <7AAEA0F6-22C7-4902-B1D1-A6AB5AC3BF04@verisign.com> <20080610130303.GA22418@vacation.karoshi.com.> <20080610224833.GA27668@vacation.karoshi.com.> <20080611013928.GB28799@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jun 10, 2008 at 11:10:17PM -0400, Edward Lewis wrote: > At 1:39 +0000 6/11/08, bmanning@vacation.karoshi.com wrote: > > > so, young Ed. > > > > what happens when this validator gets back -two- answers with > > different data? I know, always use the first one back - cause > > all we got is QUERY. So we do "freshest" where that is the first > > thing back. > > > > (me, on the other hand, I have DISCOVER, > > so I can get multiple replies and have to figure out what happens > > when near duplicates occur...) > > > > trying to do "best" - where best is defined as local policy. > > > >--bill (still bending pipes in the basement...) > > So, wizened sage Bill, > > For years "resolvers" (in the days before validators) would just get > the first arrival, fold up the socket and pass on the result. Once > we added the SIG record (and then whatever they are now) with > expirations and inception times we thought we had introduced absolute > time to the DNS and the ability to handle multiple answers. Oh what > fools we were! regardless, since the resolver itself still is stuck using the QUERY opcode, it will still take the first arrival (the freshest - by definition), fold up the socket and pass on the result. the DISCOVER opcode gets multiple replies (if any) and passes them on for "additional processing". the resolver itself does not care - the application cares - and in this case, the application is the DNS. -- 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 Jun 11 05:15:05 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E703A6812; Wed, 11 Jun 2008 05:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1HIkgOjFfgT; Wed, 11 Jun 2008 05:15:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CE98C3A63D2; Wed, 11 Jun 2008 05:15:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6PAM-000Ly0-Un for namedroppers-data@psg.com; Wed, 11 Jun 2008 12:11:02 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6PAA-000Lwo-24 for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 12:10:52 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m5BC8IxG013643; Wed, 11 Jun 2008 12:08:18 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m5BC89lW013635; Wed, 11 Jun 2008 12:08:09 GMT Date: Wed, 11 Jun 2008 12:08:09 +0000 From: bmanning@vacation.karoshi.com To: Shane Kerr Cc: Mark Andrews , IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080611120809.GC13231@vacation.karoshi.com.> References: <200806111024.m5BAO7Yx003903@drugs.dv.isc.org> <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 11, 2008 at 01:38:56PM +0200, Shane Kerr wrote: > Mark, > > On Jun 11, 2008, at 12:24 +0200, Mark Andrews wrote: > > > > I'm the zone admin. I know what my trust anchor is. I've > > configured it into named.conf. I don't want named trusting > > anything that doesn't verify against the trust anchor that > > I have in my config. The fact that I also have a trust anchor > > for higher up the tree does not change say that I want to accept > > answers that don't validate against my trust anchor. The trust > > anchor for higher up in the tree is for my neibours, not for > > my own zone. > > If you're the zone administrator, why didn't you send your DS record > to your parent zone? my parent refused to take it.. > Or did your parent somehow publish a DS record without your permission? someone who claims to be my parent pubished a DS rr for my delegation, but its not mine. (think alternate root constructs) > In either case, why do you trust your parent to publish NS records > (not authoritative I know, but resolvers have no way to find your > servers without them), but not DS records? i may trust my parent to do so, when contractually bound. > So, is there any objection to making the default a logical-OR of all > trust chains, but allowing local configuration to override that? (I > think this is what Olaf was suggesting.) logical OR is fine - IF - i can force the search order. --bill > > -- > Shane > > -- > to 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 Jun 11 05:31:06 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2473A6780; Wed, 11 Jun 2008 05:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.765 X-Spam-Level: X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi7rjuO28bpr; Wed, 11 Jun 2008 05:31:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C5FBE3A63D2; Wed, 11 Jun 2008 05:31:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6PQE-000OHn-Um for namedroppers-data@psg.com; Wed, 11 Jun 2008 12:27:26 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6PQB-000OH3-3x for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 12:27:25 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5BCR8AH008216; Wed, 11 Jun 2008 08:27:15 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 11 Jun 2008 08:21:11 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: expired draft Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I went looking for: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-06.txt and discovered it to have expired on May 22. It's not listed in the WG charter page. (I had thought that even expired drafts remained in the list. Maybe I was wrong, maybe the new system changed, dunno.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Jun 11 05:57:23 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9673A6838; Wed, 11 Jun 2008 05:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.322 X-Spam-Level: X-Spam-Status: No, score=-1.322 tagged_above=-999 required=5 tests=[AWL=-1.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GL6baj+vugg; Wed, 11 Jun 2008 05:57:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 489093A6812; Wed, 11 Jun 2008 05:57:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6PoB-0002Px-EV for namedroppers-data@psg.com; Wed, 11 Jun 2008 12:52:11 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Pnx-0002ON-T2 for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 12:52:08 +0000 Received: from Puki.ogud.com (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5BCpsg3008670 for ; Wed, 11 Jun 2008 08:51:54 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200806111251.m5BCpsg3008670@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Jun 2008 08:51:24 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Re: expired draft In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: It looks like the Secretariat's automatically generated working group page only contains the non expired drafts. Even the draft that is stalled at the IESG is missing and these drafts used to show up. Moral http://tools.ietf.org/wg/dnsext/ is a MUCH better place to search for things. Olafur At 08:21 11/06/2008, Edward Lewis wrote: >I went looking for: > >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-06.txt > >and discovered it to have expired on May 22. > >It's not listed in the WG charter page. (I had thought that even >expired drafts remained in the list. Maybe I was wrong, maybe the >new system changed, dunno.) >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-571-434-5468 >NeuStar > >Never confuse activity with progress. Activity pays 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: > -- to unsubscribe send a message to namedroppers-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 Jun 11 05:59:40 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FBD83A6950; Wed, 11 Jun 2008 05:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.972 X-Spam-Level: X-Spam-Status: No, score=-0.972 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LA0b2K+OBUt; Wed, 11 Jun 2008 05:59:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4306B3A68FD; Wed, 11 Jun 2008 05:59:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6PsV-000352-2Z for namedroppers-data@psg.com; Wed, 11 Jun 2008 12:56:39 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6PsN-00033m-1t for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 12:56:32 +0000 Received: from commandprompt.com (227-54-222-209.mycybernet.net [209.222.54.227]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m5BCw4oh029979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Jun 2008 05:58:07 -0700 Date: Wed, 11 Jun 2008 08:56:25 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: expired draft Message-ID: <20080611125625.GB710@commandprompt.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Wed, 11 Jun 2008 05:58:08 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 11, 2008 at 08:21:11AM -0400, Edward Lewis wrote: > I went looking for: > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-06.txt > > and discovered it to have expired on May 22. Yes. I've recently dinged the editors about that. > It's not listed in the WG charter page. (I had thought that even expired > drafts remained in the list. Maybe I was wrong, maybe the new system > changed, dunno.) No, it's listed under "recently expired" instead of "expired". A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- to unsubscribe send a message to namedroppers-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 Jun 11 06:01:48 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005E43A68E6; Wed, 11 Jun 2008 06:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgLlhlXoeL7T; Wed, 11 Jun 2008 06:01:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E61703A6957; Wed, 11 Jun 2008 06:01:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Ptn-0003Iy-T2 for namedroppers-data@psg.com; Wed, 11 Jun 2008 12:57:59 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Pti-0003ID-P5 for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 12:57:57 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5BCveNG008750; Wed, 11 Jun 2008 08:57:40 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200806111024.m5BAO7Yx003903@drugs.dv.isc.org> References: <200806111024.m5BAO7Yx003903@drugs.dv.isc.org> Date: Wed, 11 Jun 2008 08:55:30 -0400 To: Mark Andrews From: Edward Lewis Subject: Re: Confusion about trust anchors and DS records from the parent? Cc: Edward Lewis , IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 20:24 +1000 6/11/08, Mark Andrews wrote: > I'm the zone admin. I know what my trust anchor is. I've > configured it into named.conf. I don't want named trusting > anything that doesn't verify against the trust anchor that > I have in my config. The fact that I also have a trust anchor > for higher up the tree does not change say that I want to accept > answers that don't validate against my trust anchor. The trust > anchor for higher up in the tree is for my neibours, not for > my own zone. DNSSEC is not about protecting the zone admin, it's about protecting the recipient of the response. The verifier, operating under local policy, is an agent of the (relying party's) resolver, not the (responding) server. There is certainly confusion apparent in this answer. Divide the world into the responding servers and subdivide into the authority servers and the cache servers. Yeah, we have servers that do both. The other major segment of the divide is the (stub) resolvers. When "I'm the zone admin" is said, I put my mind into someone managing an authoritative server. There is no trust anchor involved. There is a "secure entry point" that I publish to interested parties, there is a key that is the seed for a DS record I expect to be put into my parent zone. I don't do any verification. I might have an expectation that verifiers will validate my zone's responses in a particular way. But this it the Internet, the "clients" are not subservient to the "servers." As the zone admin, I can present data, I can't determine how a recipient will use it, if at all. I can't say "use only verified data from me" for instance. The notion that the server is not in control is more evident in routing, where the origin of a route advertisement has only limited control of how a remote end will transit networks to get to the origin. When "I know what my trust anchor is" my mind shifts to the point of view of the relying party, the one that operates the verifier. This is a different position, even if the functions of zone admin and relying party are lumped into the same corporate seat. The job here is to accept data that is not part of an illicit attempt to provide false information, more or less. What makes me furrow my brow in trying to understand Mark's point is "the trust anchor for higher up the tree is for my neighbors, not for my own zone." If you are consulting a trust anchor, you aren't functioning as someone with "my own zone." What I think is the issue here is whether you will accept an answers where there is a conflict between verification paths. I.e., if a record set validates against the parent trust anchor/RRSIG+DS/RRSIG+DNSKEY/RRSIG+data and not against the child trust anchor/RRSIG+data - or vice versa. A relying party could accept this data or it could drop this data. Either reaction is appropriate, one reaction is right (but that is impossible to know), and one reaction is preferred. Which is preferred will depend on the relying party, not the zone admin, and the way in which they operate the network. Without saying that a policy of using "only" the closest trust anchor is the preferred mode of operation, a policy of using "any" trust anchor is workable and appropriate at times, maybe even the majority of times. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Jun 11 06:05:57 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42ABD3A685D; Wed, 11 Jun 2008 06:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wuPb3IzE6A9; Wed, 11 Jun 2008 06:05:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDF183A68E7; Wed, 11 Jun 2008 06:05:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6PwT-0003iG-0S for namedroppers-data@psg.com; Wed, 11 Jun 2008 13:00:45 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6PwL-0003gj-PE for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 13:00:42 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5BD0Sbs008792; Wed, 11 Jun 2008 09:00:29 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080611120403.GB13231@vacation.karoshi.com.> References: <43009.1212805787@sa.vix.com> <7AAEA0F6-22C7-4902-B1D1-A6AB5AC3BF04@verisign.com> <20080610130303.GA22418@vacation.karoshi.com.> <20080610224833.GA27668@vacation.karoshi.com.> <20080611013928.GB28799@vacation.karoshi.com.> <20080611120403.GB13231@vacation.karoshi.com.> Date: Wed, 11 Jun 2008 08:58:23 -0400 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: Confusion about trust anchors and DS records from the parent? Cc: Edward Lewis , bmanning@vacation.karoshi.com, IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 12:04 +0000 6/11/08, bmanning@vacation.karoshi.com wrote: > regardless, since the resolver itself still is stuck using > the QUERY opcode, it will still take the first arrival (the > freshest - by definition), fold up the socket and pass on the > result. I don't buy that. A resolver can listen to the socket for as long as it likes. I don't believe that QUERY says "grab one and only one response" although that is how implementations choose (me making a sweeping statement there, I haven't looked at all implementations) to do it. > the DISCOVER opcode gets multiple replies (if any) and passes > them on for "additional processing". the resolver itself does > not care - the application cares - and in this case, the application > is the DNS. And with DISCOVER you get cash back! (Oh, wait, that's from an advertisement somewhere.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Jun 11 06:10:14 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCC283A6A22; Wed, 11 Jun 2008 06:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.445 X-Spam-Level: X-Spam-Status: No, score=-4.445 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKoRO5V4pxPC; Wed, 11 Jun 2008 06:10:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F4AB3A6986; Wed, 11 Jun 2008 06:10:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Q2C-0004gb-Hl for namedroppers-data@psg.com; Wed, 11 Jun 2008 13:06:40 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Q27-0004fp-TS for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 13:06:37 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m5BD5UxG014573; Wed, 11 Jun 2008 13:05:30 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m5BD5Ua8014572; Wed, 11 Jun 2008 13:05:30 GMT Date: Wed, 11 Jun 2008 13:05:30 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: bmanning@vacation.karoshi.com, IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080611130530.GA14540@vacation.karoshi.com.> References: <7AAEA0F6-22C7-4902-B1D1-A6AB5AC3BF04@verisign.com> <20080610130303.GA22418@vacation.karoshi.com.> <20080610224833.GA27668@vacation.karoshi.com.> <20080611013928.GB28799@vacation.karoshi.com.> <20080611120403.GB13231@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 11, 2008 at 08:58:23AM -0400, Edward Lewis wrote: > At 12:04 +0000 6/11/08, bmanning@vacation.karoshi.com wrote: > > > regardless, since the resolver itself still is stuck using > > the QUERY opcode, it will still take the first arrival (the > > freshest - by definition), fold up the socket and pass on the > > result. > > I don't buy that. A resolver can listen to the socket for as long as > it likes. I don't believe that QUERY says "grab one and only one > response" although that is how implementations choose (me making a > sweeping statement there, I haven't looked at all implementations) to > do it. perhaps you can re-read QUERY and educate me. the implementations i looked at all do the "grab one and only one response" and the way i read the spec seems to support that view. > > the DISCOVER opcode gets multiple replies (if any) and passes > > them on for "additional processing". the resolver itself does > > not care - the application cares - and in this case, the application > > is the DNS. no cash back.. :) --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 Jun 11 06:32:03 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068AF3A68C9; Wed, 11 Jun 2008 06:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.007 X-Spam-Level: X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZq-WifY3yE4; Wed, 11 Jun 2008 06:32:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 658123A689D; Wed, 11 Jun 2008 06:32:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6QLt-0007mW-Nr for namedroppers-data@psg.com; Wed, 11 Jun 2008 13:27:01 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6QLk-0007lB-Sg for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 13:26:59 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5BDQk1Z009175; Wed, 11 Jun 2008 09:26:47 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200806111251.m5BCpsg3008670@ogud.com> References: <200806111251.m5BCpsg3008670@ogud.com> Date: Wed, 11 Jun 2008 09:21:10 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: expired draft Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 8:51 -0400 6/11/08, =D3lafur Gu=F0mundsson /DNSEXT chair wrote: >Moral http://tools.ietf.org/wg/dnsext/ is a MUCH better place to search for >things. Quibbling with the secretariat then, the charter=20 page is the URL I'd hand to folks that are not=20 regular IETF participants. Perhaps all is appropriate though, expired drafts=20 are expired. It's just that I thought we kept=20 the carcasses around - like the the milestones. (If tools is so important, why doesn't it have a=20 real URL, like, you know, www-something?) BTW, on the topic of milestones upcoming - unless=20 we get some more WG activity on this, AXFR=20 clarify won't be ready for IESG in July. (I've=20 tried to hunt down the implementers, but they are=20 a wiggly group.) -- -=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 Never confuse activity with progress. Activity pays 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 Jun 11 06:43:17 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0DAF3A6838; Wed, 11 Jun 2008 06:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R87FxdiNg-px; Wed, 11 Jun 2008 06:43:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF1443A68D2; Wed, 11 Jun 2008 06:43:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6QYA-0009qi-Ny for namedroppers-data@psg.com; Wed, 11 Jun 2008 13:39:42 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6QY2-0009pb-Eq for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 13:39:37 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id DAEC3114050 for ; Wed, 11 Jun 2008 13:39:28 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 030D2E601A for ; Wed, 11 Jun 2008 13:39: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.14.2/8.14.2) with ESMTP id m5BDckvn006031; Wed, 11 Jun 2008 23:39:02 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806111339.m5BDckvn006031@drugs.dv.isc.org> To: Shane Kerr Cc: IETF DNSEXT WG From: Mark Andrews Subject: Re: Confusion about trust anchors and DS records from the parent? In-reply-to: Your message of "Wed, 11 Jun 2008 13:38:56 +0200." <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> Date: Wed, 11 Jun 2008 23:38:46 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Mark, > > On Jun 11, 2008, at 12:24 +0200, Mark Andrews wrote: > > > > I'm the zone admin. I know what my trust anchor is. I've > > configured it into named.conf. I don't want named trusting > > anything that doesn't verify against the trust anchor that > > I have in my config. The fact that I also have a trust anchor > > for higher up the tree does not change say that I want to accept > > answers that don't validate against my trust anchor. The trust > > anchor for higher up in the tree is for my neibours, not for > > my own zone. > > If you're the zone administrator, why didn't you send your DS record > to your parent zone? The above assumes that the parent has been given the DS records for my zone. Just because that have it doesn't mean I trust them not to make a mistake or to be conned. Both of these events happen regularly today and I see no evidence that they won't happen once DS records are being accepted. > Or did your parent somehow publish a DS record without your permission? > > In either case, why do you trust your parent to publish NS records > (not authoritative I know, but resolvers have no way to find your > servers without them), but not DS records? NS record in the parents are HINTS. I want to know when they have been compromised and to not trust compromised records. > To be honest, I think it is perfectly acceptable for software to > implement this if for some reason an administrator actually wants this > behavior. > > But the general case will be for someone (not the zone administrator) > to forget they configured a trust anchor locally and suffer some > period of breakage until they figure out why DNS stops working when > going to a specific domain, after the administrators of that zone > publish DS records in their parent and they stop maintaining a > separate trust anchor. Firstly "what seperate trust anchor"? Secondly once you start publishing a trust anchor you took on the obligation for maintaining it and also notifiying the users of that trust anchor that it is going away when that happens. > DNSSEC should tend towards not breaking, if at > all possible, especially considering the state of the debugging tools > right now. :-/ The debugging tools we have today will handle broken trust anchors. "dig +cd" is all you need to debug this. > So, is there any objection to making the default a logical-OR of all > trust chains, but allowing local configuration to override that? (I > think this is what Olaf was suggesting.) I very much object to the default being the logical OR. That is the exceptional condition especially as is breaks existing practice. What is now secure would become less secure. Mark > -- > Shane -- 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 Jun 11 07:02:32 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE633A67ED; Wed, 11 Jun 2008 07:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5feRGRSPhW0V; Wed, 11 Jun 2008 07:02:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9BBC43A683C; Wed, 11 Jun 2008 07:02:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Qnn-000CBN-OI for namedroppers-data@psg.com; Wed, 11 Jun 2008 13:55:51 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Qnc-000C9o-Jw for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 13:55:49 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id E21E111408A for ; Wed, 11 Jun 2008 13:55:32 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 3CB28E6023 for ; Wed, 11 Jun 2008 13:55: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.14.2/8.14.2) with ESMTP id m5BDt9xh006338; Wed, 11 Jun 2008 23:55:11 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806111355.m5BDt9xh006338@drugs.dv.isc.org> To: Edward Lewis Cc: IETF DNSEXT WG From: Mark Andrews Subject: Re: Confusion about trust anchors and DS records from the parent? In-reply-to: Your message of "Wed, 11 Jun 2008 08:55:30 -0400." Date: Wed, 11 Jun 2008 23:55:09 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > At 20:24 +1000 6/11/08, Mark Andrews wrote: > > > I'm the zone admin. I know what my trust anchor is. I've > > configured it into named.conf. I don't want named trusting > > anything that doesn't verify against the trust anchor that > > I have in my config. The fact that I also have a trust anchor > > for higher up the tree does not change say that I want to accept > > answers that don't validate against my trust anchor. The trust > > anchor for higher up in the tree is for my neibours, not for > > my own zone. > > DNSSEC is not about protecting the zone admin, it's about protecting > the recipient of the response. The verifier, operating under local > policy, is an agent of the (relying party's) resolver, not the > (responding) server. It is protecting the recipient. The trust anchor is configured into the validator. As a admin I can be both a originator and a consumer. Also being the admin I have complete trust in myself to keep the trust anchors I have configured up to date and correct in my validators. You can be a admin of multiple machines and multiple processes. Mark -- 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 Jun 11 07:37:19 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD6C93A6878; Wed, 11 Jun 2008 07:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPtL0S3vRgJR; Wed, 11 Jun 2008 07:37:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A47583A6812; Wed, 11 Jun 2008 07:37:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6RHu-000GjC-IX for namedroppers-data@psg.com; Wed, 11 Jun 2008 14:26:58 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6RHl-000Gi0-0o for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 14:26:51 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id 140E59588D; Wed, 11 Jun 2008 11:26:47 -0300 (BRT) Date: Wed, 11 Jun 2008 11:26:47 -0300 From: Frederico A C Neves To: IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080611142647.GQ7724@registro.br> Mail-Followup-To: Frederico A C Neves , IETF DNSEXT WG References: <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> <200806111339.m5BDckvn006031@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806111339.m5BDckvn006031@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark, On Wed, Jun 11, 2008 at 11:38:46PM +1000, Mark Andrews wrote: ... > > To be honest, I think it is perfectly acceptable for software to > > implement this if for some reason an administrator actually wants this > > behavior. > > > > But the general case will be for someone (not the zone administrator) > > to forget they configured a trust anchor locally and suffer some > > period of breakage until they figure out why DNS stops working when > > going to a specific domain, after the administrators of that zone > > publish DS records in their parent and they stop maintaining a > > separate trust anchor. > > Firstly "what seperate trust anchor"? Secondly once you > start publishing a trust anchor you took on the obligation > for maintaining it and also notifiying the users of that > trust anchor that it is going away when that happens. Agreed, this is the current burden of early deployers. All this discussion is based on the goal of making this a little bit easier. > > DNSSEC should tend towards not breaking, if at > > all possible, especially considering the state of the debugging tools > > right now. :-/ > > The debugging tools we have today will handle broken trust > anchors. "dig +cd" is all you need to debug this. > > > So, is there any objection to making the default a logical-OR of all > > trust chains, but allowing local configuration to override that? (I > > think this is what Olaf was suggesting.) > > I very much object to the default being the logical OR. > That is the exceptional condition especially as is breaks > existing practice. What is now secure would become less > secure. This puzzles me.... please define what do you mean by less secure. In what scenario a RRSIG that could be validated through a DS chained over an upper TA and can't be validated through another "closer" TA is less secure ? You have the crypto proof that the RRSIG is valid, you only don't want to "see it" by not using the logical OR. Better, please show a scenario that the use of the logical OR would reduce the security. AFAIK the logical OR put us definitely in a more stable situation. > Mark Fred ps. Please let's stop arguing that you don't trust you parent.... you trust. The DNS namespace in hierarchical get over it or move to the keywords business :-) -- to unsubscribe send a message to namedroppers-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 Jun 11 08:15:24 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8272F3A6911; Wed, 11 Jun 2008 08:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.25 X-Spam-Level: **** X-Spam-Status: No, score=4.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Abntv3iWREJ7; Wed, 11 Jun 2008 08:15:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 788523A6812; Wed, 11 Jun 2008 08:15:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Rtq-000M70-H3 for namedroppers-data@psg.com; Wed, 11 Jun 2008 15:06:10 +0000 Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Rtb-000M4C-Pp for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 15:06:03 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA087856712; Wed, 11 Jun 2008 17:05:12 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA21996; Wed, 11 Jun 2008 17:05:06 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200806111505.RAA21996@TR-Sys.de> Subject: Re: Confusion about trust anchors and DS records from the parent? To: Mark_Andrews@isc.org, namedroppers@ops.ietf.org Date: Wed, 11 Jun 2008 17:05:06 +0200 (MESZ) In-Reply-To: <200806111339.m5BDckvn006031@drugs.dv.isc.org> from Mark Andrews at Jun "11," 2008 "11:38:46" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >> So, is there any objection to making the default a logical-OR of all >> trust chains, but allowing local configuration to override that? (I >> think this is what Olaf was suggesting.) That "logical-OR" *is* the core of the protocol. > > I very much object to the default being the logical OR. > That is the exceptional condition especially as is breaks > existing practice. What is now secure would become less > secure. > > Mark Sorry Mark, you want a new protocol! DNSSEC still makes use of classical (binary) logic a.k.a. set theory. It does *not* use Fuzzy Logic. (For non-initiated readers [overly simplified]: Fuzzy Logic replaces binary truth values by probability measures.) 'OR' is the *only* solution that makes sense. There's no such thing as '15% trust' or '99% trust' in DNSSEC. There's only trust present or not. As noted by someone other, the former is for humans, the latter is for algorithms (in DNS and DNSSEC). DNSSEC deals with only *finding* a chain of trust from a trust anchor. For efficiency and speed (that's what DNS seems to suffer from most seriously anyway today, perhaps due to cache inefficiency caused by needlessly short TTL values), all has been designed to look for and stop after finding a verifyable chain of trust. There's no way to pass back a *degree of trust* from a DNSSEC aware resolver to a (classical) stub resolver. The DNS user needs a binary decision; either an RRset matching the query (perhaps empty), or an error indication; and all that as fast as possible. If you really want to introduce and properly handle degrees of trust you'd have to always perform search-in-breadth and establish much more complex algorithms for the evaluation of the results than ever envisioned for DNSSEC. Not even X.50*, CMS, S/MIME, PKIX etc. manage to properly deal with similar complexity. Do not make DNSSEC even more complicated! Leave all these Fuzzy ideas out of DNSSEC! It would be overkill, and perhaps definitely kill DNSSEC deployment at large; you'd have to wait for well-discussed and stable algorithms capable of dealing with these Fuzzy ideas. AFAICS, to specifically protect your local zones for local users, only taking a local trust anchor into account, it is possible to configure DNS 'forwarding' for those local zones, and operate those (local) resolvers in "island mode" without recursive service. >> -- >> Shane > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ -- to unsubscribe send a message to namedroppers-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 Jun 11 14:18:15 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78923A6813; Wed, 11 Jun 2008 14:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8afziO78-Xi; Wed, 11 Jun 2008 14:18:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DD703A6800; Wed, 11 Jun 2008 14:18:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Xc7-000Mps-Jc for namedroppers-data@psg.com; Wed, 11 Jun 2008 21:12:15 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Xby-000Mon-PL for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 21:12:13 +0000 Received: from commandprompt.com (227-54-222-209.mycybernet.net [209.222.54.227]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m5BLDemP015993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Jun 2008 14:13:44 -0700 Date: Wed, 11 Jun 2008 17:12:01 -0400 From: Andrew Sullivan/dnsext co-chair To: namedroppers@ops.ietf.org Subject: Clarification questions for trust anchor handling Message-ID: <20080611211201.GF1364@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Wed, 11 Jun 2008 14:13:44 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, Given that it is apparent different people have different impressions of the requirements for handling locally-configured trust anchors as compared to chains of trust followed from somewhere up the tree, we need clarifying text. We propose that this clarifying text should go in draft-ietf-dnsext-dnssec-bis-updates. In order to allow the editors of that document to propose text, we would like the members of the working group to answer the following questions. A. MAY validating resolvers use a local policy to enforce certain validation methods, e.g. by using only locally-configured trust anchors even when there is a valid chain of trust available? B. If the answer to (A) is, "Yes," what should the default policy be? C. Should the following text from RFC 4035 be read as extending to trust anchors? Please note section 4.2 of the (expired) draft-ietf-dnsext-dnssec-bis-updates-06 and suggest alteration as appropriate. > 5.1. Special Considerations for Islands of Security > Islands of security (see [RFC4033]) are signed zones for which it is > not possible to construct an authentication chain to the zone from > its parent. Validating signatures within an island of security > requires that the validator have some other means of obtaining an > initial authenticated zone key for the island. If a validator cannot > obtain such a key, it SHOULD switch to operating as if the zones in > the island of security are unsigned. > All the normal processes for validating responses apply to islands of > security. The only difference between normal validation and > validation within an island of security is in how the validator > obtains a trust anchor for the authentication chain. [. . .] > 5.3.1. Checking the RRSIG RR Validity [. . .] > It is possible for more than one DNSKEY RR to match the conditions > above. In this case, the validator cannot predetermine which DNSKEY > RR to use to authenticate the signature, and it MUST try each > matching DNSKEY RR until either the signature is validated or the > validator has run out of matching public keys to try. > Note that this authentication process is only meaningful if the > validator authenticates the DNSKEY RR before using it to validate > signatures. The matching DNSKEY RR is considered to be authentic if: > o the apex DNSKEY RRset containing the DNSKEY RR is considered > authentic; or > o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, > and the DNSKEY RR either matches an authenticated DS RR from the > parent zone or matches a trust anchor. Olafur & Andrew -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- to unsubscribe send a message to namedroppers-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 Jun 11 14:48:20 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8243A6800; Wed, 11 Jun 2008 14:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.047 X-Spam-Level: X-Spam-Status: No, score=-4.047 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tI8dVc7VQVTl; Wed, 11 Jun 2008 14:48:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E29893A65A5; Wed, 11 Jun 2008 14:48:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Y48-0000rO-3T for namedroppers-data@psg.com; Wed, 11 Jun 2008 21:41:12 +0000 Received: from [216.82.250.131] (helo=mail128.messagelabs.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Y3u-0000pY-4O for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 21:41:06 +0000 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1213220456!4919355!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 8106 invoked from network); 11 Jun 2008 21:40:56 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 11 Jun 2008 21:40:56 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m5BLep8T020289 for ; Wed, 11 Jun 2008 14:40:56 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m5BLeoch024034 for ; Wed, 11 Jun 2008 16:40:50 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m5BLeopf024025 for ; Wed, 11 Jun 2008 16:40:50 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Confusion about trust anchors and DS records from the parent? Date: Wed, 11 Jun 2008 17:40:48 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979003E0DB3E@de01exm64.ds.mot.com> In-Reply-To: <20080611142647.GQ7724@registro.br> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confusion about trust anchors and DS records from the parent? Thread-Index: AcjL0wq0BlMCYJy0Rsqz1yyvCaCFYAANdGbA References: <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> <200806111339.m5BDckvn006031@drugs.dv.isc.org> <20080611142647.GQ7724@registro.br> From: "Eastlake III Donald-LDE008" To: "IETF DNSEXT WG" X-CFilter-Loop: Reflected Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: So you work for organization Example which cares about security. They own your computer and configure it with a trust anchor for, say, Example.com. When you are on the general Internet they are going to want an RR set in *.example.com that is not signed by that configure TA or a path traceable to that TA to be rejected. No matter what the standard says, they will demand this feature in your resolver. Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Frederico A C Neves Sent: Wednesday, June 11, 2008 10:27 AM To: IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? Mark, >=20 > I very much object to the default being the logical OR. > That is the exceptional condition especially as is breaks > existing practice. What is now secure would become less > secure. This puzzles me.... please define what do you mean by less secure. In what scenario a RRSIG that could be validated through a DS chained over an upper TA and can't be validated through another "closer" TA is less secure ? You have the crypto proof that the RRSIG is valid, you only don't want to "see it" by not using the logical OR. Better, please show a scenario that the use of the logical OR would reduce the security. AFAIK the logical OR put us definitely in a more stable situation. > Mark Fred -- to unsubscribe send a message to namedroppers-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 Jun 11 15:48:54 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03AF03A681F; Wed, 11 Jun 2008 15:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9QvL56xNRsN; Wed, 11 Jun 2008 15:48:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E0D9F3A68C5; Wed, 11 Jun 2008 15:48:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Z2P-000ApG-Iu for namedroppers-data@psg.com; Wed, 11 Jun 2008 22:43:29 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6Z2L-000Aob-KL for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 22:43:27 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id 82B8195871; Wed, 11 Jun 2008 19:43:24 -0300 (BRT) Date: Wed, 11 Jun 2008 19:43:24 -0300 From: Frederico A C Neves To: Eastlake III Donald-LDE008 Cc: IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080611224324.GV7724@registro.br> Mail-Followup-To: Frederico A C Neves , Eastlake III Donald-LDE008 , IETF DNSEXT WG References: <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> <200806111339.m5BDckvn006031@drugs.dv.isc.org> <20080611142647.GQ7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DB3E@de01exm64.ds.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3870C46029D1F945B1472F170D2D979003E0DB3E@de01exm64.ds.mot.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 11, 2008 at 05:40:48PM -0400, Eastlake III Donald-LDE008 wrote: > So you work for organization Example which cares about security. They > own your computer and configure it with a trust anchor for, say, > Example.com. When you are on the general Internet they are going to want > an RR set in *.example.com that is not signed by that configure TA or a > path traceable to that TA to be rejected. Let me try to understand, if you are the holder of example.com you definitely control how do you sign and hand to your parent what they accept. At the validators you control, supposing you are doing the right thing, they'll be correctly configured. If in this situation you get something not signed, definitely, drop it, because it is valid as a 3 dollar bill. We are not talking about NOT having another security path available. All this thread is about when you have more than one path and at least one of then validate. > Donald Fred -- to unsubscribe send a message to namedroppers-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 Jun 11 16:10:11 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DDDC3A685C; Wed, 11 Jun 2008 16:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9yz4n1kEoQ0; Wed, 11 Jun 2008 16:10:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 664C23A68C5; Wed, 11 Jun 2008 16:10:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6ZO8-000DVc-Dh for namedroppers-data@psg.com; Wed, 11 Jun 2008 23:05:56 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6ZNh-000DSy-BC for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 23:05:42 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Cc:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=qTaPuLs6cgkxSHJHDHiKCEIaMmx9aAznZiYtfV5bvPUof+vyA9v5t7MA b7/t9xupKtUknG7T3M5PD1ILar8V3B023fBWC8hqte2F+t8ZmyMw0s0eq lwU6OTmz7ia6oxW; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1213225529; x=1244761529; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20roy@nominet.org.uk|Subject:=20Re:=20Clarificatio n=20questions=20for=20trust=20anchor=20handling|Date:=20T hu,=2012=20Jun=202008=2000:05:25=20+0100|Message-ID:=20|To:=20Andrew=20Sullivan/dnsext=20co-chair =20|Cc:=20namedroppers@ops.ietf.or g|MIME-Version:=201.0|In-Reply-To:=20<20080611211201.GF13 64@commandprompt.com>; bh=qWssajYP2hHHsAulblJAdDBX+I3v2gmgnEmXxd7EKcY=; b=YIVQuYsx5I4GZWFEJZCiqBxMVj36UZopu+qohKqNXP5j3WozgjqDe6VJ z4pbXn+wq0e3wUWoqLsVVpA/dVdd6Wo7L0CuWLEnTQdA1XZAS1fR7VkQa pADal2r4A0WzMpj; X-IronPort-AV: E=Sophos;i="4.27,626,1204502400"; d="scan'208";a="2476649" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 12 Jun 2008 00:05:27 +0100 In-Reply-To: <20080611211201.GF1364@commandprompt.com> To: Andrew Sullivan/dnsext co-chair Cc: namedroppers@ops.ietf.org Subject: Re: Clarification questions for trust anchor handling MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: roy@nominet.org.uk Date: Thu, 12 Jun 2008 00:05:25 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 12/06/2008 12:05:26 AM, Serialize complete at 12/06/2008 12:05:26 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew Sullivan wrote on 06/11/2008 10:12:01 PM: > Dear colleagues, > > Given that it is apparent different people have different impressions > of the requirements for handling locally-configured trust anchors as > compared to chains of trust followed from somewhere up the tree, we > need clarifying text. We propose that this clarifying text should go > in draft-ietf-dnsext-dnssec-bis-updates. > > In order to allow the editors of that document to propose text, we > would like the members of the working group to answer the following > questions. > > A. MAY validating resolvers use a local policy to enforce certain > validation methods, e.g. by using only locally-configured trust > anchors even when there is a valid chain of trust available? Yes. > B. If the answer to (A) is, "Yes," what should the default policy be? Logical OR. At least one of the available chains of trust must validate. When ALL the available chains of trust do NOT result in a correctly validated signature, the validated RRSet is bogus. > C. Should the following text from RFC 4035 be read as extending to > trust anchors? Please note section 4.2 of the (expired) > draft-ietf-dnsext-dnssec-bis-updates-06 and suggest alteration as > appropriate. > > > 5.1. Special Considerations for Islands of Security > > > Islands of security (see [RFC4033]) are signed zones for which it is > > not possible to construct an authentication chain to the zone from > > its parent. Validating signatures within an island of security > > requires that the validator have some other means of obtaining an > > initial authenticated zone key for the island. If a validator cannot > > obtain such a key, it SHOULD switch to operating as if the zones in > > the island of security are unsigned. > > > All the normal processes for validating responses apply to islands of > > security. The only difference between normal validation and > > validation within an island of security is in how the validator > > obtains a trust anchor for the authentication chain. > [. . .] > > 5.3.1. Checking the RRSIG RR Validity > [. . .] > > It is possible for more than one DNSKEY RR to match the conditions > > above. In this case, the validator cannot predetermine which DNSKEY > > RR to use to authenticate the signature, and it MUST try each > > matching DNSKEY RR until either the signature is validated or the > > validator has run out of matching public keys to try. > > > Note that this authentication process is only meaningful if the > > validator authenticates the DNSKEY RR before using it to validate > > signatures. The matching DNSKEY RR is considered to be authentic if: > > > o the apex DNSKEY RRset containing the DNSKEY RR is considered > > authentic; or > > > o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, > > and the DNSKEY RR either matches an authenticated DS RR from the > > parent zone or matches a trust anchor. Yes. Roy Arends 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 Wed Jun 11 16:16:47 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703FE3A6890; Wed, 11 Jun 2008 16:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhcSND4lj1OR; Wed, 11 Jun 2008 16:16:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C1803A684E; Wed, 11 Jun 2008 16:16:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6ZV8-000ESF-DM for namedroppers-data@psg.com; Wed, 11 Jun 2008 23:13:10 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6ZUv-000EQP-1k for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 23:13:03 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id B29E595870; Wed, 11 Jun 2008 20:12:55 -0300 (BRT) Date: Wed, 11 Jun 2008 20:12:55 -0300 From: Frederico A C Neves To: Andrew Sullivan/dnsext co-chair Cc: namedroppers@ops.ietf.org Subject: Re: Clarification questions for trust anchor handling Message-ID: <20080611231255.GW7724@registro.br> Mail-Followup-To: Frederico A C Neves , Andrew Sullivan/dnsext co-chair , namedroppers@ops.ietf.org References: <20080611211201.GF1364@commandprompt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080611211201.GF1364@commandprompt.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 11, 2008 at 05:12:01PM -0400, Andrew Sullivan/dnsext co-chair wrote: > Dear colleagues, > > Given that it is apparent different people have different impressions > of the requirements for handling locally-configured trust anchors as > compared to chains of trust followed from somewhere up the tree, we > need clarifying text. We propose that this clarifying text should go > in draft-ietf-dnsext-dnssec-bis-updates. > > In order to allow the editors of that document to propose text, we > would like the members of the working group to answer the following > questions. > > A. MAY validating resolvers use a local policy to enforce certain > validation methods, e.g. by using only locally-configured trust > anchors even when there is a valid chain of trust available? Yes. But I think the sample the way it's stated it's ambiguous, because both TA are locally-configured. You'll have two or more TA at different levels of the tree. e.g. by using only the more specific trust anchor even when there is a valid chain of trust available from another trust anchor upper in the tree. > B. If the answer to (A) is, "Yes," what should the default policy be? Default policy should be that all chains of trust available must be tested and the default test order should be from the less specifict to the more specific. > C. Should the following text from RFC 4035 be read as extending to > trust anchors? Please note section 4.2 of the (expired) > draft-ietf-dnsext-dnssec-bis-updates-06 and suggest alteration as > appropriate. Yes. > > 5.1. Special Considerations for Islands of Security > > > Islands of security (see [RFC4033]) are signed zones for which it is > > not possible to construct an authentication chain to the zone from > > its parent. Validating signatures within an island of security > > requires that the validator have some other means of obtaining an > > initial authenticated zone key for the island. If a validator cannot > > obtain such a key, it SHOULD switch to operating as if the zones in > > the island of security are unsigned. > > > All the normal processes for validating responses apply to islands of > > security. The only difference between normal validation and > > validation within an island of security is in how the validator > > obtains a trust anchor for the authentication chain. > [. . .] > > 5.3.1. Checking the RRSIG RR Validity > [. . .] > > It is possible for more than one DNSKEY RR to match the conditions > > above. In this case, the validator cannot predetermine which DNSKEY > > RR to use to authenticate the signature, and it MUST try each > > matching DNSKEY RR until either the signature is validated or the > > validator has run out of matching public keys to try. > > > Note that this authentication process is only meaningful if the > > validator authenticates the DNSKEY RR before using it to validate > > signatures. The matching DNSKEY RR is considered to be authentic if: > > > o the apex DNSKEY RRset containing the DNSKEY RR is considered > > authentic; or > > > o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, > > and the DNSKEY RR either matches an authenticated DS RR from the > > parent zone or matches a trust anchor. > > Olafur & Andrew > > -- > Andrew Sullivan Fred -- to unsubscribe send a message to namedroppers-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 Jun 11 16:56:32 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838A93A67A6; Wed, 11 Jun 2008 16:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pQQ2+9Pei91; Wed, 11 Jun 2008 16:56:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B14DC3A67DA; Wed, 11 Jun 2008 16:56:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6a5X-000JFh-I3 for namedroppers-data@psg.com; Wed, 11 Jun 2008 23:50:47 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6a5P-000JEU-DM for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 23:50:45 +0000 Received: from [128.107.30.64] ([128.107.30.64]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m5BNoQ74083652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Jun 2008 01:50:28 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Cc: Andrew Sullivan/dnsext co-chair , namedroppers@ops.ietf.org Message-Id: <62E72A7A-E62C-4A5C-AF0C-73FA21447F69@NLnetLabs.nl> From: Olaf Kolkman To: Frederico A C Neves In-Reply-To: <20080611231255.GW7724@registro.br> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-845288806" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: Clarification questions for trust anchor handling Date: Wed, 11 Jun 2008 16:50:06 -0700 References: <20080611211201.GF1364@commandprompt.com> <20080611231255.GW7724@registro.br> X-Pgp-Agent: GPGMail d52 (v52, Leopard) X-Mailer: Apple Mail (2.924) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Thu, 12 Jun 2008 01:50:30 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-845288806 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 11, 2008, at 4:12 PM, Frederico A C Neves wrote: >> B. If the answer to (A) is, "Yes," what should the default policy be? > > Default policy should be that all chains of trust available must be > tested and the default test order should be from the less specifict to > the more specific. What do you do when one fails? If you continue on failure until you find a validating change then this is similar to the "OR" that Ray just suggested.. (correct?) --Olaf --Apple-Mail-1-845288806 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: This message is locally signed. iEYEARECAAYFAkhQZK4ACgkQtN/ca3YJIocpOQCgrvHRP5q7M/svKMH8bEvZLSnO efQAoJ+sSnUraJp2c8Ouu//vuisHo16M =9rN8 -----END PGP SIGNATURE----- --Apple-Mail-1-845288806-- -- to unsubscribe send a message to namedroppers-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 Jun 11 17:02:51 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3FF3A67DA; Wed, 11 Jun 2008 17:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 380ob2ltpzsS; Wed, 11 Jun 2008 17:02:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BEBA03A67A4; Wed, 11 Jun 2008 17:02:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6aBD-000K1a-3Q for namedroppers-data@psg.com; Wed, 11 Jun 2008 23:56:39 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6aB4-000Jya-OX for namedroppers@ops.ietf.org; Wed, 11 Jun 2008 23:56:36 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id 5ABA495860; Wed, 11 Jun 2008 20:56:29 -0300 (BRT) Date: Wed, 11 Jun 2008 20:56:29 -0300 From: Frederico A C Neves To: Olaf Kolkman Cc: Andrew Sullivan/dnsext co-chair , namedroppers@ops.ietf.org Subject: Re: Clarification questions for trust anchor handling Message-ID: <20080611235629.GX7724@registro.br> Mail-Followup-To: Frederico A C Neves , Olaf Kolkman , Andrew Sullivan/dnsext co-chair , namedroppers@ops.ietf.org References: <20080611211201.GF1364@commandprompt.com> <20080611231255.GW7724@registro.br> <62E72A7A-E62C-4A5C-AF0C-73FA21447F69@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62E72A7A-E62C-4A5C-AF0C-73FA21447F69@NLnetLabs.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 11, 2008 at 04:50:06PM -0700, Olaf Kolkman wrote: > > On Jun 11, 2008, at 4:12 PM, Frederico A C Neves wrote: > > >>B. If the answer to (A) is, "Yes," what should the default policy be? > > > >Default policy should be that all chains of trust available must be > >tested and the default test order should be from the less specifict to > >the more specific. > > What do you do when one fails? Continue with another one more specific until all of them fails. > If you continue on failure until you find a validating change then > this is similar to the "OR" that Ray just suggested.. (correct?) Yes, it's the OR proposal with a explicit test order. > --Olaf Fred -- to unsubscribe send a message to namedroppers-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 Jun 11 17:27:05 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE933A67A4; Wed, 11 Jun 2008 17:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv-JRAP0pN8l; Wed, 11 Jun 2008 17:27:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 326343A6783; Wed, 11 Jun 2008 17:27:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6aYy-000N93-50 for namedroppers-data@psg.com; Thu, 12 Jun 2008 00:21:12 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6aYW-000N50-QY for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 00:20:58 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Cc:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=qsbq0tUjwjNG3uL/jivyzEsLtmE3AqTu7ztKOtF+aP1F4ZLO4uFp1RUI QeJK+LbYmZl1ZCkZDq/GUtk+UUZEiMFpCigE9RfsOEvb04Hyzy1T7z0zI APwz5MO5QOKQnKS; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1213230044; x=1244766044; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20roy@nominet.org.uk|Subject:=20Re:=20Clarificatio n=20questions=20for=20trust=20anchor=20handling|Date:=20T hu,=2012=20Jun=202008=2001:20:41=20+0100|Message-ID:=20|To:=20Frederico=20A=20C=20Neves=20|Cc:=20Andrew=20Sullivan/dnsext=20co-chair =20,=0D=0A=09namedroppers@ops.ietf .org,=0D=0A=09Olaf=20Kolkman=20 |MIME-Version:=201.0|In-Reply-To:=20<20080611235629.GX772 4@registro.br>; bh=IX9jn0onkoF0ldXVH5TIKjQUHgR1c8cMTHRPLnwf4/4=; b=h20KFxaomFQlVKKpfVE71DWFFPY2Np0UQKwRD1969L3J/HRwoqBpW9X9 /z58cf7fcUyYPLGiFK4rlOF4U9xN1bBdSmz617QBoZq2nUnMDPf+PRLmg QbDq560TyCHwG8b; X-IronPort-AV: E=Sophos;i="4.27,627,1204502400"; d="scan'208";a="1864699" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 12 Jun 2008 01:20:43 +0100 In-Reply-To: <20080611235629.GX7724@registro.br> To: Frederico A C Neves Cc: Andrew Sullivan/dnsext co-chair , namedroppers@ops.ietf.org, Olaf Kolkman Subject: Re: Clarification questions for trust anchor handling MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: roy@nominet.org.uk Date: Thu, 12 Jun 2008 01:20:41 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 12/06/2008 01:20:42 AM, Serialize complete at 12/06/2008 01:20:42 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Frederico A C Neves wrote on 06/12/2008 12:56:29 AM: > On Wed, Jun 11, 2008 at 04:50:06PM -0700, Olaf Kolkman wrote: > > > > On Jun 11, 2008, at 4:12 PM, Frederico A C Neves wrote: > > > > >>B. If the answer to (A) is, "Yes," what should the default policy be? > > > > > >Default policy should be that all chains of trust available must be > > >tested and the default test order should be from the less specifict to > > >the more specific. > > > > What do you do when one fails? > > Continue with another one more specific until all of them fails. > > > If you continue on failure until you find a validating change then > > this is similar to the "OR" that Ray just suggested.. (correct?) > > Yes, it's the OR proposal with a explicit test order. Why is the order significant? 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 Jun 11 18:21:06 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410B23A68FE; Wed, 11 Jun 2008 18:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.547 X-Spam-Level: X-Spam-Status: No, score=-4.547 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4pCOt6EBEm6; Wed, 11 Jun 2008 18:21:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6DD073A68FC; Wed, 11 Jun 2008 18:21:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6bPj-0003l6-Qv for namedroppers-data@psg.com; Thu, 12 Jun 2008 01:15:43 +0000 Received: from [216.82.250.131] (helo=mail128.messagelabs.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6bPa-0003k2-TV for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 01:15:41 +0000 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1213233333!2460478!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 1791 invoked from network); 12 Jun 2008 01:15:33 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-7.tower-128.messagelabs.com with SMTP; 12 Jun 2008 01:15:33 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m5C1FX7V020318 for ; Wed, 11 Jun 2008 18:15:33 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id m5C1FWDf014824 for ; Wed, 11 Jun 2008 20:15:32 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id m5C1FVjX014808 for ; Wed, 11 Jun 2008 20:15:31 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Confusion about trust anchors and DS records from the parent? Date: Wed, 11 Jun 2008 21:15:29 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979003E0DBAB@de01exm64.ds.mot.com> In-Reply-To: <20080611224324.GV7724@registro.br> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confusion about trust anchors and DS records from the parent? Thread-Index: AcjMFJPgpieUaOf1QkWRvKd0XhiEKgAD92TQ References: <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> <200806111339.m5BDckvn006031@drugs.dv.isc.org> <20080611142647.GQ7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DB3E@de01exm64.ds.mot.com> <20080611224324.GV7724@registro.br> From: "Eastlake III Donald-LDE008" To: "Frederico A C Neves" Cc: "IETF DNSEXT WG" X-CFilter-Loop: Reflected Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Doesn't matter how many paths there are or whether or not you are the "true" holder of the zone in the sense that people get to your data if they start at root. If you really care about security, you want your machines to never believe any RR sets in/under what YOU believe to be your zone unless they are signed YOUR keys. That's it. The fact that some RR set purporting to be in what you believe to be your zone has some signatures that can be validly traced back to a TLD or root or something doesn't matter for your policy. Your machines should assume such stuff is bad. And it doesn't matter if there is a second path back to your configured TA that fails. It's pretty easy to forge signatures that don't validate and that's something an attacker could add to the bad data they are feeding you. Just how paranoid a user organization would have to be to want such a policy is an interesting question. But eventually, if you assume widespread deployment of DNSSEC, why would you bother to configure a TA other than at root if you didn't have such a policy? Donald -----Original Message----- From: Frederico A C Neves [mailto:fneves@registro.br]=20 Sent: Wednesday, June 11, 2008 6:43 PM To: Eastlake III Donald-LDE008 Cc: IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? On Wed, Jun 11, 2008 at 05:40:48PM -0400, Eastlake III Donald-LDE008 wrote: > So you work for organization Example which cares about security. They > own your computer and configure it with a trust anchor for, say, > Example.com. When you are on the general Internet they are going to want > an RR set in *.example.com that is not signed by that configure TA or a > path traceable to that TA to be rejected.=20 Let me try to understand, if you are the holder of example.com you definitely control how do you sign and hand to your parent what they accept. At the validators you control, supposing you are doing the right thing, they'll be correctly configured. If in this situation you get something not signed, definitely, drop it, because it is valid as a 3 dollar bill. We are not talking about NOT having another security path available. All this thread is about when you have more than one path and at least one of then validate. > Donald Fred -- to unsubscribe send a message to namedroppers-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 Jun 11 18:41:05 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ADF83A67CF; Wed, 11 Jun 2008 18:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49a3yocfKqeK; Wed, 11 Jun 2008 18:41:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4EE073A6774; Wed, 11 Jun 2008 18:41:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6bhZ-0006At-RC for namedroppers-data@psg.com; Thu, 12 Jun 2008 01:34:09 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6bhO-00069O-AG for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 01:34:04 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0K2B00M01T7TK000@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 02:33:56 +0100 (IST) Received: from [10.0.1.189] ([83.141.81.52]) by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPSA id <0K2B006EWTOFDL20@cali.ucd.ie> for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 02:33:56 +0100 (IST) Date: Thu, 12 Jun 2008 02:33:57 +0100 From: Niall O'Reilly Subject: Re: Clarification questions for trust anchor handling In-reply-to: To: Namedroppers WG Cc: Niall O'Reilly Message-id: <34D088AB-DCCB-4F71-9431-CE32BF736F0A@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.753) Content-type: multipart/signed; boundary=Apple-Mail-77-851520525; micalg=pgp-sha1; protocol="application/pgp-signature" Content-transfer-encoding: 7BIT X-Pgp-Agent: GPGMail 1.1.2 (Tiger) References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-77-851520525 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 12 Jun 2008, at 00:05, roy@nominet.org.uk wrote: > When ALL the available chains of trust do NOT result in a correctly > validated signature, the validated RRSet is bogus. I see ambiguity here, and suggest instead "When NONE of the available chains of trust results in a correctly validated signature, the validated RRSET is bogus". Unless I've completely misunderstood. /Niall --Apple-Mail-77-851520525 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFIUH0QeYfkja6ZXtkRAl4CAKCatxzTZyPR59RAz3ja+FOpQRKU4wCfeusg BSqEqte2Xeq8eo3ljv0x+Cw= =i1Al -----END PGP SIGNATURE----- --Apple-Mail-77-851520525-- -- to unsubscribe send a message to namedroppers-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 Jun 11 21:22:34 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1F0D3A67CF; Wed, 11 Jun 2008 21:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.589 X-Spam-Level: X-Spam-Status: No, score=-4.589 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgTjZ3d025yI; Wed, 11 Jun 2008 21:22:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C2E53A6774; Wed, 11 Jun 2008 21:22:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6eD9-000OlY-SX for namedroppers-data@psg.com; Thu, 12 Jun 2008 04:14:55 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6eD2-000Oke-3y for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 04:14:54 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m5C4DgxG013177; Thu, 12 Jun 2008 04:13:42 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m5C4DdJd013171; Thu, 12 Jun 2008 04:13:39 GMT Date: Thu, 12 Jun 2008 04:13:39 +0000 From: bmanning@vacation.karoshi.com To: "Niall O'Reilly" Cc: Namedroppers WG Subject: Re: Clarification questions for trust anchor handling Message-ID: <20080612041339.GA12948@vacation.karoshi.com.> References: <34D088AB-DCCB-4F71-9431-CE32BF736F0A@ucd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34D088AB-DCCB-4F71-9431-CE32BF736F0A@ucd.ie> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 12, 2008 at 02:33:57AM +0100, Niall O'Reilly wrote: > > On 12 Jun 2008, at 00:05, roy@nominet.org.uk wrote: > > >When ALL the available chains of trust do NOT result in a correctly > >validated signature, the validated RRSet is bogus. > > I see ambiguity here, and suggest instead "When NONE of the > available chains of trust results in a correctly validated > signature, the validated RRSET is bogus". a question for you... you state - "the validated RRSET is bogus" - apparently quoting from others. This seems a bit incongrus in the context... I posit that "When NONE of the available chains reach a configured TA, that the RRSET can not be validated. An RRSET that can not be validated can not be presumed to be either intact or authentic." > > Unless I've completely misunderstood. > > /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 Thu Jun 12 01:35:54 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BEED3A6878; Thu, 12 Jun 2008 01:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWLVZntmFNds; Thu, 12 Jun 2008 01:35:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D9933A6824; Thu, 12 Jun 2008 01:35:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6i9x-0003sR-Uf for namedroppers-data@psg.com; Thu, 12 Jun 2008 08:27:53 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6i9t-0003rO-Vg for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 08:27:51 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0K2C00K01CMX5W00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 09:27:46 +0100 (IST) Received: from [10.0.1.189] ([83.141.81.52]) by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPSA id <0K2C004XHCU9IH70@cali.ucd.ie> for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 09:27:46 +0100 (IST) Date: Thu, 12 Jun 2008 09:27:59 +0100 From: Niall O'Reilly Subject: Re: Clarification questions for trust anchor handling In-reply-to: <20080612041339.GA12948@vacation.karoshi.com> To: Namedroppers WG Cc: Niall O'Reilly Message-id: <6D7D5465-1E87-4793-AF14-AB551E90B017@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.753) Content-type: multipart/signed; boundary=Apple-Mail-79-876362158; micalg=pgp-sha1; protocol="application/pgp-signature" Content-transfer-encoding: 7BIT X-Pgp-Agent: GPGMail 1.1.2 (Tiger) References: <34D088AB-DCCB-4F71-9431-CE32BF736F0A@ucd.ie> <20080612041339.GA12948@vacation.karoshi.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-79-876362158 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 12 Jun 2008, at 05:13, bmanning@vacation.karoshi.com wrote: > a question for you... you state - "the validated RRSET is > bogus" - apparently quoting from others. This seems a bit > incongrus in the context... Indeed. At that hour of the morning, my focus tends to be narrow. 8-) > I posit that "When NONE of the available chains reach a > configured TA, that the RRSET can not be validated. An > RRSET that can not be validated can not be presumed to be > either intact or authentic." Applying 's/TA, that the/TA, the/' would make that (!) easier for me to parse. [ Rat-hole alert! ] Over here, we write "cannot" without a space in the middle. IIRC, another Irishman said something about "... two great nations, divided by a common language." 8-) /Niall --Apple-Mail-79-876362158 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFIUN4UeYfkja6ZXtkRAvnfAJ4tOawjqxMc4XwW3DmhXAFPTIL5IgCgjxd4 qp2FGIJLBrGXqvcx3Y8pph8= =3LNL -----END PGP SIGNATURE----- --Apple-Mail-79-876362158-- -- to unsubscribe send a message to namedroppers-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 Jun 12 02:58:55 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8340D3A69EC; Thu, 12 Jun 2008 02:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmGFFzYYDf+C; Thu, 12 Jun 2008 02:58:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4CB243A69E4; Thu, 12 Jun 2008 02:58:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6jTa-000ELc-RG for namedroppers-data@psg.com; Thu, 12 Jun 2008 09:52:14 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6jTR-000EKF-W1 for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 09:52:08 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 1E84311407E for ; Thu, 12 Jun 2008 09:52:04 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 40782E6022 for ; Thu, 12 Jun 2008 09:52:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m5BMBiOD009475; Thu, 12 Jun 2008 08:11:46 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806112211.m5BMBiOD009475@drugs.dv.isc.org> To: Frederico A C Neves , IETF DNSEXT WG From: Mark Andrews Mail-Followup-To: Frederico A C Neves , IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? In-reply-to: Your message of "Wed, 11 Jun 2008 11:26:47 -0300." <20080611142647.GQ7724@registro.br> Date: Thu, 12 Jun 2008 08:11:44 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Mark, > > On Wed, Jun 11, 2008 at 11:38:46PM +1000, Mark Andrews wrote: > ... > > > To be honest, I think it is perfectly acceptable for software to > > > implement this if for some reason an administrator actually wants this > > > behavior. > > > > > > But the general case will be for someone (not the zone administrator) > > > to forget they configured a trust anchor locally and suffer some > > > period of breakage until they figure out why DNS stops working when > > > going to a specific domain, after the administrators of that zone > > > publish DS records in their parent and they stop maintaining a > > > separate trust anchor. > > > > Firstly "what seperate trust anchor"? Secondly once you > > start publishing a trust anchor you took on the obligation > > for maintaining it and also notifiying the users of that > > trust anchor that it is going away when that happens. > > Agreed, this is the current burden of early deployers. All this > discussion is based on the goal of making this a little bit easier. > > > > DNSSEC should tend towards not breaking, if at > > > all possible, especially considering the state of the debugging tools > > > right now. :-/ > > > > The debugging tools we have today will handle broken trust > > anchors. "dig +cd" is all you need to debug this. > > > > > So, is there any objection to making the default a logical-OR of all > > > trust chains, but allowing local configuration to override that? (I > > > think this is what Olaf was suggesting.) > > > > I very much object to the default being the logical OR. > > That is the exceptional condition especially as is breaks > > existing practice. What is now secure would become less > > secure. > > This puzzles me.... please define what do you mean by less secure. I have exactly 1 path today. I can get things wrong by not updating a trust anchor but I can't compromise myself (accept bad data) as things currently are. If I go to a OR I get two paths. One I totally control. The other I don't control. > In what scenario a RRSIG that could be validated through a DS chained > over an upper TA and can't be validated through another "closer" TA is > less secure ? You have the crypto proof that the RRSIG is valid, you > only don't want to "see it" by not using the logical OR. Think about what happened to Comcast the other day and add changed DS records to the changed NS records. Mistakes happen. People get conned. > Better, please show a scenario that the use of the logical OR would > reduce the security. > > AFAIK the logical OR put us definitely in a more stable situation. > > > Mark > > Fred > > ps. Please let's stop arguing that you don't trust you parent.... you > trust. The DNS namespace in hierarchical get over it or move to the > keywords business :-) I trust the parent to TRY to do the right thing. I do NOT trust the parent to SUCCEED in doing the right thing. Mark -- 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 Jun 12 05:52:47 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527793A695C; Thu, 12 Jun 2008 05:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsYh45S4iILq; Thu, 12 Jun 2008 05:52:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7EB3C3A67B7; Thu, 12 Jun 2008 05:52:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6mBe-000CEl-Vv for namedroppers-data@psg.com; Thu, 12 Jun 2008 12:45:54 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6mBX-000CDk-8Y for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 12:45:52 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id D4E9C95870; Thu, 12 Jun 2008 09:45:45 -0300 (BRT) Date: Thu, 12 Jun 2008 09:45:45 -0300 From: Frederico A C Neves To: namedroppers@ops.ietf.org Subject: Re: Clarification questions for trust anchor handling Message-ID: <20080612124545.GY7724@registro.br> Mail-Followup-To: Frederico A C Neves , namedroppers@ops.ietf.org References: <20080611235629.GX7724@registro.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 12, 2008 at 01:20:41AM +0100, roy@nominet.org.uk wrote: > Frederico A C Neves wrote on 06/12/2008 12:56:29 AM: ... > > Continue with another one more specific until all of them fails. > > > > > If you continue on failure until you find a validating change then > > > this is similar to the "OR" that Ray just suggested.. (correct?) > > > > Yes, it's the OR proposal with a explicit test order. > > Why is the order significant? It's not, and this is not a tentative of optimization of the process, depending on the scenario the selected order could be the anti-optimization. The idea is just to put determinism in the validation behavior. > Roy Fred -- to unsubscribe send a message to namedroppers-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 Jun 12 06:09:18 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C5B3A6AC1; Thu, 12 Jun 2008 06:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.442 X-Spam-Level: X-Spam-Status: No, score=-5.442 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT-+raRsC6bj; Thu, 12 Jun 2008 06:09:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 50D863A6A5E; Thu, 12 Jun 2008 06:09:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6mQ3-000ETA-Qd for namedroppers-data@psg.com; Thu, 12 Jun 2008 13:00:47 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6mPw-000ERr-0d for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 13:00:42 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 2EE7E1C0172; Thu, 12 Jun 2008 15:00:37 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 29B8D1C0160; Thu, 12 Jun 2008 15:00:37 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 2637B58EB9B; Thu, 12 Jun 2008 15:00:37 +0200 (CEST) Date: Thu, 12 Jun 2008 15:00:37 +0200 From: Stephane Bortzmeyer To: Suresh Krishnaswamy Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-hayatnagarkar-dnsext-validator-api-06.txt Message-ID: <20080612130037.GA12786@nic.fr> References: <20080527181502.55C973A6C19@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080527181502.55C973A6C19@core3.amsl.com> X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, May 27, 2008 at 11:15:01AM -0700, Internet-Drafts@ietf.org wrote a message of 56 lines which said: > Title : DNSSEC Validator API > Author(s) : A. Hayatnagarkar, S. Krishnaswamy Long time I've not been reading I-Ds about the DNSSEC API. So, feel free to file my concerns in the "Already discussed" folder, if necessary. Pointers to FAQ are also welcome :-) I am sure that most applications would not want to adapt to DNSSEC (just look at the time it took to adapt them to the multi-protocol - IPv4 and IPv6 - paradigm). In most cases, the resolver should do the work and just send back a SERVFAIL to the application (RFC 4035, 5.5). But, for the applications that want to do DNSSEC (for instance a SSH client implementing RFC 4255), the lack of a standard API is clearly a big problem. So, I welcome this work and appreciate the amount of work it is. Now, for my concerns. I do not see much usefulness in val_gethostbyname, section 3.1. These gethostby* routines are obsolete for a very long time (RFC 2292, ten years ago) and, if an application still use them, its maintainers will not want to switch to DNSSEC either. I suggest to drop these routines completely. In 3.2, val_getaddrinfo et al., it is not clear if the possible status code list is exhaustive or not. For instance, VAL_BOGUS is not mentioned in the list but seems to be a reasonable possible result. For the val_status_t of section 7.1, I do not find an obvious code for "validated by a non-DNSSEC mechanism", for instance because I used LDAP with a TLS connection. Is it VAL_LOCAL_ANSWER despite the fact that LDAP is not local? I do not find much guidance for the future implementors of this draft. For example, if I write a library implementing the val_* functions, should I always set the CD bit in the requests to the resolver? (It seems so but I'm not sure.) -- to unsubscribe send a message to namedroppers-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 Jun 12 06:11:36 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E24628C104; Thu, 12 Jun 2008 06:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nneqY5Yl4ZsD; Thu, 12 Jun 2008 06:11:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7779A3A6ACF; Thu, 12 Jun 2008 06:11:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6mXE-000Ff3-P9 for namedroppers-data@psg.com; Thu, 12 Jun 2008 13:08:12 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6mX7-000Fdz-R7 for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 13:08:10 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id E04D7958AB; Thu, 12 Jun 2008 10:08:04 -0300 (BRT) Date: Thu, 12 Jun 2008 10:08:04 -0300 From: Frederico A C Neves To: IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080612130804.GZ7724@registro.br> Mail-Followup-To: Frederico A C Neves , IETF DNSEXT WG References: <20080611142647.GQ7724@registro.br> <200806112211.m5BMBiOD009475@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806112211.m5BMBiOD009475@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark, On Thu, Jun 12, 2008 at 08:11:44AM +1000, Mark Andrews wrote: ... > > > I very much object to the default being the logical OR. > > > That is the exceptional condition especially as is breaks > > > existing practice. What is now secure would become less > > > secure. > > > > This puzzles me.... please define what do you mean by less secure. > > I have exactly 1 path today. I can get things wrong by not > updating a trust anchor but I can't compromise myself (accept > bad data) as things currently are. If I go to a OR I get > two paths. One I totally control. The other I don't > control. Being the child owner You are the one that control the NS and the DS at your parent, and finally and most important You are the one that control the DNSKEY set at the apex of your zone. If the key is not there it'll not validate, but if it is there and there is an upper TA that could validate it it's just being disruptive to not validate it. The scenario we are plotting is the one that You the validating resolver owner is not the owner of any of the 2 or more TA's configured at it that starts covering the name but at different levels. I could see value on the current behavior but only in very specific scenarios, I'm not arguing on for this to be outlawed, just to be put as an option. The proposed behavior is the best one when you have the root being signed after large TLD deployments already in place. > > In what scenario a RRSIG that could be validated through a DS chained > > over an upper TA and can't be validated through another "closer" TA is > > less secure ? You have the crypto proof that the RRSIG is valid, you > > only don't want to "see it" by not using the logical OR. > > Think about what happened to Comcast the other day and add > changed DS records to the changed NS records. Mistakes > happen. People get conned. DNSSEC is not designed to solve administrative security problems. If you have a bad registry/registrar or you are a lazy admin is not DNSSEC that will save you. > > Better, please show a scenario that the use of the logical OR would > > reduce the security. > > > > AFAIK the logical OR put us definitely in a more stable situation. > > > > > Mark > > > > Fred > > > > ps. Please let's stop arguing that you don't trust you parent.... you > > trust. The DNS namespace in hierarchical get over it or move to the > > keywords business :-) > > I trust the parent to TRY to do the right thing. I do NOT > trust the parent to SUCCEED in doing the right thing. So your argument is in the line that the current DNSSEC resolution behavior will save you from a bad parent ? > Mark Fred -- to unsubscribe send a message to namedroppers-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 Jun 12 06:23:27 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832863A6939; Thu, 12 Jun 2008 06:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lke-NShj37sX; Thu, 12 Jun 2008 06:23:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 59EB83A6915; Thu, 12 Jun 2008 06:23:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6mhu-000H8V-O6 for namedroppers-data@psg.com; Thu, 12 Jun 2008 13:19:14 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6mhm-000H78-NJ for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 13:19:09 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id C47FA9586D; Thu, 12 Jun 2008 10:19:05 -0300 (BRT) Date: Thu, 12 Jun 2008 10:19:05 -0300 From: Frederico A C Neves To: IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080612131905.GA7724@registro.br> Mail-Followup-To: Frederico A C Neves , IETF DNSEXT WG References: <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> <200806111339.m5BDckvn006031@drugs.dv.isc.org> <20080611142647.GQ7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DB3E@de01exm64.ds.mot.com> <20080611224324.GV7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DBAB@de01exm64.ds.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3870C46029D1F945B1472F170D2D979003E0DBAB@de01exm64.ds.mot.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 11, 2008 at 09:15:29PM -0400, Eastlake III Donald-LDE008 wrote: > Doesn't matter how many paths there are or whether or not you are the > "true" holder of the zone in the sense that people get to your data if > they start at root. If you really care about security, you want your > machines to never believe any RR sets in/under what YOU believe to be > your zone unless they are signed YOUR keys. That's it. > > The fact that some RR set purporting to be in what you believe to be > your zone has some signatures that can be validly traced back to a TLD > or root or something doesn't matter for your policy. Your machines > should assume such stuff is bad. And it doesn't matter if there is a > second path back to your configured TA that fails. It's pretty easy to > forge signatures that don't validate and that's something an attacker > could add to the bad data they are feeding you. > > Just how paranoid a user organization would have to be to want such a > policy is an interesting question. But eventually, if you assume > widespread deployment of DNSSEC, why would you bother to configure a TA > other than at root if you didn't have such a policy? Because the deployment scenario that is in our horizon is showing large TLDs deploying DNSSEC and the root is not signed and latter it will get signed and at that time the OR behavior will make the transition more stable. We are not talking about private zones trusted by private entities, we are talking about widespread deployment of DNSSEC on large zones that are trusted by a large amount of resolvers. I'm not against the current behavior as long as it's optional and could be signaled administratively for each TA. > Donald Fred -- to unsubscribe send a message to namedroppers-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 Jun 12 10:21:34 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 355E63A68EB; Thu, 12 Jun 2008 10:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3WlLWqHduwm; Thu, 12 Jun 2008 10:21:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B7473A68AD; Thu, 12 Jun 2008 10:21:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6qL5-000ON5-O1 for namedroppers-data@psg.com; Thu, 12 Jun 2008 17:11:55 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6qKn-000OKi-MS for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 17:11:46 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CHBZes013480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Jun 2008 10:11:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <3870C46029D1F945B1472F170D2D979003E0DBAB@de01exm64.ds.mot.com> References: <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> <200806111339.m5BDckvn006031@drugs.dv.isc.org> <20080611142647.GQ7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DB3E@de01exm64.ds.mot.com> <20080611224324.GV7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DBAB@de01exm64.ds.mot.com> Date: Thu, 12 Jun 2008 10:11:34 -0700 To: "IETF DNSEXT WG" From: Paul Hoffman Subject: RE: Confusion about trust anchors and DS records from the parent? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 9:15 PM -0400 6/11/08, Eastlake III Donald-LDE008 wrote: >But eventually, if you assume >widespread deployment of DNSSEC, why would you bother to configure a TA >other than at root if you didn't have such a policy? There are many potential reasons. Remember that operations for DNSSEC are still at a very early stage. - You install a TA for .org, and later the root is signed. You add the the TA for the root, not knowing if .org has sent its DS to the root, so you leave the TA for .org in your pile. You then forget it is there after .org has a chain from the root. - You install a TA for .yourzone.com because you do not trust that .com will be competent about keeping its children up to date. - You didn't understand the whole hierarchy thing and you thought "more TAs are good" because that is what you have been taught by a decade of using web browsers. And so on. It is a bad idea to assume that every resolver admin will understand which TAs to install, and when to install them, and when to remove some of them. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 12 14:41:53 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25B73A68C6; Thu, 12 Jun 2008 14:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.127 X-Spam-Level: X-Spam-Status: No, score=-1.127 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaLeSSNzyMyr; Thu, 12 Jun 2008 14:41:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 77E7A3A67C0; Thu, 12 Jun 2008 14:41:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6uDn-000CoI-Jj for namedroppers-data@psg.com; Thu, 12 Jun 2008 21:20:39 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6uDb-000Cm1-3Q for namedroppers@ops.ietf.org; Thu, 12 Jun 2008 21:20:34 +0000 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5CLKHPn026460 for ; Thu, 12 Jun 2008 17:20:17 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200806122120.m5CLKHPn026460@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Jun 2008 17:19:59 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Editors change dnssec-bis-update Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: For the last 3+ years Sam and Rob have maintained this document, but due to personal reasons have asked the chairs to find a replacement that can be more proactive in editing the document and lead discussions. After considering the requests the chairs approached David Blacka if he was willing to take the task on, and he agreed. We want to thank Rob and Sam for the good work they have done on this document. Olafur & Andrew -- to unsubscribe send a message to namedroppers-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 Jun 13 06:52:23 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A013A68EC; Fri, 13 Jun 2008 06:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.53 X-Spam-Level: X-Spam-Status: No, score=-4.53 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLR3+QjNSm4N; Fri, 13 Jun 2008 06:52:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB3C43A68D9; Fri, 13 Jun 2008 06:52:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K79VK-000GVU-Oi for namedroppers-data@psg.com; Fri, 13 Jun 2008 13:39:46 +0000 Received: from [216.82.245.51] (helo=mail119.messagelabs.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K79V8-000GU6-2u for namedroppers@ops.ietf.org; Fri, 13 Jun 2008 13:39:36 +0000 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1213364369!22643819!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 17374 invoked from network); 13 Jun 2008 13:39:29 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-7.tower-119.messagelabs.com with SMTP; 13 Jun 2008 13:39:29 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m5DDdMtv000545 for ; Fri, 13 Jun 2008 06:39:28 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m5DDdLLD017020 for ; Fri, 13 Jun 2008 08:39:21 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m5DDdKlg017012 for ; Fri, 13 Jun 2008 08:39:20 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Confusion about trust anchors and DS records from the parent? Date: Fri, 13 Jun 2008 09:39:15 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979003E4411C@de01exm64.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confusion about trust anchors and DS records from the parent? Thread-Index: AcjMswl9I1Nj3ThJTkm7FE+edntYgAAp5Brw References: <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> <200806111339.m5BDckvn006031@drugs.dv.isc.org> <20080611142647.GQ7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DB3E@de01exm64.ds.mot.com> <20080611224324.GV7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DBAB@de01exm64.ds.mot.com> From: "Eastlake III Donald-LDE008" To: "Paul Hoffman" Cc: "IETF DNSEXT WG" X-CFilter-Loop: Reflected Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Some or your reasons are reasons that OR would be good. Some of them are reasons that OR would be fatal. It just shows that this must be local policy and practical products will have to provide choice. OR is clearly less secure. Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Paul Hoffman Sent: Thursday, June 12, 2008 1:12 PM To: IETF DNSEXT WG Subject: RE: Confusion about trust anchors and DS records from the parent? At 9:15 PM -0400 6/11/08, Eastlake III Donald-LDE008 wrote: >But eventually, if you assume >widespread deployment of DNSSEC, why would you bother to configure a TA >other than at root if you didn't have such a policy? There are many potential reasons. Remember that operations for DNSSEC=20 are still at a very early stage. - You install a TA for .org, and later the root is signed. You add=20 the the TA for the root, not knowing if .org has sent its DS to the=20 root, so you leave the TA for .org in your pile. You then forget it=20 is there after .org has a chain from the root. - You install a TA for .yourzone.com because you do not trust that=20 .com will be competent about keeping its children up to date. - You didn't understand the whole hierarchy thing and you thought=20 "more TAs are good" because that is what you have been taught by a=20 decade of using web browsers. And so on. It is a bad idea to assume that every resolver admin will=20 understand which TAs to install, and when to install them, and when=20 to remove some of them. --Paul Hoffman, Director --VPN Consortium -- to 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 Fri Jun 13 07:02:10 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5982B3A68AF; Fri, 13 Jun 2008 07:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LN7CatAgUb3; Fri, 13 Jun 2008 07:02:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7DFF63A682E; Fri, 13 Jun 2008 07:02:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K79if-000I6X-Eg for namedroppers-data@psg.com; Fri, 13 Jun 2008 13:53:33 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K79iX-000I5R-Rr for namedroppers@ops.ietf.org; Fri, 13 Jun 2008 13:53:28 +0000 Received: from Puki.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5DDrEFG033470 for ; Fri, 13 Jun 2008 09:53:14 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200806131353.m5DDrEFG033470@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Jun 2008 09:52:29 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Re: Editors change dnssec-bis-update In-Reply-To: <200806122120.m5CLKHPn026460@ogud.com> References: <200806122120.m5CLKHPn026460@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I hate sending the wrong version of a message out. Only Rob is retiring from editing the document, sorry Sam for the confusion. The new editors of the document are: David Blacka and Sam Weiler. Olafur At 08:21 13/06/2008, =D3lafur Gu=F0mundsson /DNSEXT wrote: >For the last 3+ years Sam and Rob have maintained this document, but >due to personal reasons have asked the chairs to find a replacement that >can be more proactive in editing the document and lead discussions. > >After considering the requests the chairs approached David Blacka if >he was willing to take the task on, and he agreed. > >We want to thank Rob and Sam for the good work they have done on this >document. > > Olafur & Andrew -- to unsubscribe send a message to namedroppers-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 Jun 13 07:21:10 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F5F3A6804; Fri, 13 Jun 2008 07:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3xLfx555b5i; Fri, 13 Jun 2008 07:21:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B90A93A68EC; Fri, 13 Jun 2008 07:21:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7A4p-000LIl-L2 for namedroppers-data@psg.com; Fri, 13 Jun 2008 14:16:27 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7A4i-000LI5-8P for namedroppers@ops.ietf.org; Fri, 13 Jun 2008 14:16:22 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EEE5411436; Fri, 13 Jun 2008 14:16:19 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "Eastlake III Donald-LDE008" cc: "Paul Hoffman" , "IETF DNSEXT WG" Subject: Re: Confusion about trust anchors and DS records from the parent? In-Reply-To: Your message of "Fri, 13 Jun 2008 09:39:15 -0400." <3870C46029D1F945B1472F170D2D979003E4411C@de01exm64.ds.mot.com> References: <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> <200806111339.m5BDckvn006031@drugs.dv.isc.org> <20080611142647.GQ7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DB3E@de01exm64.ds.mot.com> <20080611224324.GV7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DBAB@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003E4411C@de01exm64.ds.mot.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 13 Jun 2008 14:16:19 +0000 Message-ID: <46944.1213366579@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Some or your reasons are reasons that OR would be good. Some of them are > reasons that OR would be fatal. It just shows that this must be local > policy and practical products will have to provide choice. OR is clearly > less secure. hopefully noone has suggested that this not be overridable in local policy. some (including me) have argued that OR is no less secure, and one argument is that with multiple DS RRs, the expected policy is OR, since some can be past, some can be future, some can be reserve. (the difference between no DNSKEY matching an available DS RR, vs. one that claims the same keyid but does not match, is meaningless in the context of cryptovalidation.) what we're looking for here is an "expected policy". i think the expected policy, the "default configuration" if you will, ought to be OR. anyone who wants AND or who wants ONLY should be able to specify that as a local policy. please do not follow up to this note unless you disagree that the default ought to be OR and the local policy ought to be settable to something else like AND or ONLY; if you do follow up, please state reasons why this specific default ought not be available to other people, since if it's available to you then you can't really complain about its unavailability to you. -- to unsubscribe send a message to namedroppers-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 Jun 13 07:25:34 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E233A68AF; Fri, 13 Jun 2008 07:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klJ0f8egc-6A; Fri, 13 Jun 2008 07:25:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D25993A67E3; Fri, 13 Jun 2008 07:25:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7A9b-000M3Y-SR for namedroppers-data@psg.com; Fri, 13 Jun 2008 14:21:23 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7A9R-000LyI-HX for namedroppers@ops.ietf.org; Fri, 13 Jun 2008 14:21:17 +0000 Received: from [0.0.0.0] (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5DEL6ss033802; Fri, 13 Jun 2008 10:21:06 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <3870C46029D1F945B1472F170D2D979003E4411C@de01exm64.ds.mot.com> References: <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> <200806111339.m5BDckvn006031@drugs.dv.isc.org> <20080611142647.GQ7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DB3E@de01exm64.ds.mot.com> <20080611224324.GV7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DBAB@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003E4411C@de01exm64.ds.mot.com> Date: Fri, 13 Jun 2008 10:21:04 -0400 To: "IETF DNSEXT WG" From: Edward Lewis Subject: RE: Confusion about trust anchors and DS records from the parent? Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 9:39 -0400 6/13/08, Eastlake III Donald-LDE008 wrote: >Some or your reasons are reasons that OR would be good. Some of them are >reasons that OR would be fatal. It just shows that this must be local >policy and practical products will have to provide choice. OR is clearly >less secure. What's more relevant is "what is needed for interoperability?" Count me as someone that believes "OR is *not* less secure" (than AND). The reason lies in the definition of "secure." Having a foot in the operations world, I firmly believe the "OR" case is more secure in the sense that you will not be denied access by someone slipping in a bad signature of failing to have a current/correct value configured somewhere alone the way - to cause one chain or another to choke. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Fri Jun 13 07:58:17 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9118C3A6829; Fri, 13 Jun 2008 07:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOCO4pboNinQ; Fri, 13 Jun 2008 07:58:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 807913A6825; Fri, 13 Jun 2008 07:58:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7Adt-0000Th-7J for namedroppers-data@psg.com; Fri, 13 Jun 2008 14:52:41 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7Adm-0000RU-9K for namedroppers@ops.ietf.org; Fri, 13 Jun 2008 14:52:39 +0000 Received: from commandprompt.com (227-54-222-209.mycybernet.net [209.222.54.227]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m5DErwdn001486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Jun 2008 07:54:02 -0700 Date: Fri, 13 Jun 2008 10:52:17 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Agenda for IETF 72 Message-ID: <20080613145217.GD12690@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Fri, 13 Jun 2008 07:54:02 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, The draft agenda for IETF 72 has been posted at https://datatracker.ietf.org/meeting/72/agenda.html. We are tentatively scheduled for Thursday afternoon, from 13:00-15:00 local time. Please remember that the IETF meeting agenda is still subject to change, so it's still possible that our meeting slot will move. I gather that there isn't a lot of room in the agenda this time (there are very few slots still open). I have no idea whether that means a timetable change is more or less likely than it might otherwise be. The final agenda is to be published on 2008-07-07. If you have agenda items for our meeting, please send them to me along with an estimate of how long you will need for each of your items. The sooner you send them, the better. In any case, please send them by 2008-07-14 12:00:00+00, or they may not make it onto the WG meeting agenda. Thanks, and best regards, Andrew (for Olafur & Andrew) -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- to unsubscribe send a message to namedroppers-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 Jun 13 08:46:59 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5826F3A68CE; Fri, 13 Jun 2008 08:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LpEUq0ZmOTU; Fri, 13 Jun 2008 08:46:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3AAAB3A67A4; Fri, 13 Jun 2008 08:46:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7BOu-0006jZ-UX for namedroppers-data@psg.com; Fri, 13 Jun 2008 15:41:16 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7BOi-0006hW-T8 for namedroppers@ops.ietf.org; Fri, 13 Jun 2008 15:41:11 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DFf29G099212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Jun 2008 08:41:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <3870C46029D1F945B1472F170D2D979003E4411C@de01exm64.ds.mot.com> References: <64D54A00-1AF6-4ECC-9B2C-73B439250C7D@ca.afilias.info> <200806111339.m5BDckvn006031@drugs.dv.isc.org> <20080611142647.GQ7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DB3E@de01exm64.ds.mot.com> <20080611224324.GV7724@registro.br> <3870C46029D1F945B1472F170D2D979003E0DBAB@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003E4411C@de01exm64.ds.mot.com> Date: Fri, 13 Jun 2008 08:40:55 -0700 To: "IETF DNSEXT WG" From: Paul Hoffman Subject: RE: Confusion about trust anchors and DS records from the parent? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 9:39 AM -0400 6/13/08, Eastlake III Donald-LDE008 wrote: >Some or your reasons are reasons that OR would be good. Some of them are >reasons that OR would be fatal. It just shows that this must be local >policy and practical products will have to provide choice. Fully agree. >OR is clearly >less secure. One definition of "secure" in this context is "allows authentication of a message if and only if the signature on that message chains to an installed trust anchor". With such a definition, OR is required. A different definition is "allows authentication of a message if and only if the signature on that message chains to an installed trust anchor, where the chain checking is done by arranging all valid chains in order of length, and validation is done only using chains of the single shortest length". The former definition is probably more sensible as a default definition. It prevents what could be a typical misconfiguration (an expired TLD TA and a properly-configured root TA) from making whole zones going bogus when those zones are, in fact, properly signed. The latter definition might be appropriate for a small number of advanced and careful administrators in situations where they know that they will always be diligent and timely about their TA maintenance, and the admin explicitly want zones to go bogus if the admin is not diligent and timely. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 13 09:35:40 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152FA3A6804; Fri, 13 Jun 2008 09:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1srD9zrfjJn; Fri, 13 Jun 2008 09:35:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE3B73A68CE; Fri, 13 Jun 2008 09:35:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7C9d-000D4J-0f for namedroppers-data@psg.com; Fri, 13 Jun 2008 16:29:33 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7C9V-000D3U-MC for namedroppers@ops.ietf.org; Fri, 13 Jun 2008 16:29:30 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DGTMDd008131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Jun 2008 09:29:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080611211201.GF1364@commandprompt.com> References: <20080611211201.GF1364@commandprompt.com> Date: Fri, 13 Jun 2008 09:28:30 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: Clarification questions for trust anchor handling Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 5:12 PM -0400 6/11/08, Andrew Sullivan/dnsext co-chair wrote: >A. MAY validating resolvers use a local policy to enforce certain >validation methods, e.g. by using only locally-configured trust >anchors even when there is a valid chain of trust available? Yes, > >B. If the answer to (A) is, "Yes," what should the default policy be? All chains of trust are tested and treated as equal. >C. Should the following text from RFC 4035 be read as extending to >trust anchors? Yes. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 13 10:00:59 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A37D3A68CE; Fri, 13 Jun 2008 10:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAL70+uL8Z+d; Fri, 13 Jun 2008 10:00:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F51E3A682D; Fri, 13 Jun 2008 10:00:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7CYY-000Gkz-MV for namedroppers-data@psg.com; Fri, 13 Jun 2008 16:55:18 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7CYQ-000GhN-FI for namedroppers@ops.ietf.org; Fri, 13 Jun 2008 16:55:16 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5DGsvbu035221; Fri, 13 Jun 2008 12:54:58 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200806111910.VAA22263@TR-Sys.de> References: <200806111910.VAA22263@TR-Sys.de> Date: Fri, 13 Jun 2008 12:50:23 -0400 To: Alfred =?hp-roman8?B?SM5uZXM=?= From: Edward Lewis Subject: Re: review of draft-ietf-dnsext-axfr-clarify-08 Cc: ed.lewis@neustar.biz, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Before committing the recommendations, here are some responses to the discussion points. At 21:10 +0200 6/11/08, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >Below are my findings during another attempt to closely read >the latest revision of the AXFR-clarify draft, > draft-ietf-dnsext-axfr-clarify-08. > >The items below mostly follow a linear walk-through of the draft, >and they are interspersed with DISCUSS items that came into my >mind during preparing of this review. > > >(0) General > >As already discussed, after a few revision cycles, the draft >now should warrant transformation to the usual I-D format. > >NOTE: > Below, to visually better distinguish running text from excerpts > from the draft, the latter have been indented by 3 columns and > re-adjusted to 72 columns according to the common I-D formating > guidelines. I don't understand this comment. The draft as submitted was clipped to 72 characters. I have never seen any requirement for indenting by 3 columns. The only id-nit noted was that I don't have pagination in there. (And that waits until the text is down to word and spelling problems.) >(3) Section 2.1.5 >FOR DISCUSSION: > Which AXFR features can reasonably be expected from deployed > AXFR server implementations also supporting EDNS0 ? A twist on the question. Does anyone use EDNS0 over TCP? EDNS0 is more than just a means to extend the permitted message length, so I would think that EDNS0 is in play. For AXFR, maybe not in current form but in the future it is possible that an option might be directed at AXFR responses. So I think it is prudent to anticipate that it might be there. >(4b) 3rd paragraph + subsequent 'editorial note' > >[ question mark missing after that note ? ] > >Near the end of the paragraph, please s/in to/into/ . > >I support the "MAY" you have solicited comments on, and I recommend >an additional note that doing so (repeating the query in subsequent >response messages) is bandwidth inefficient. > >FOR DISCUSSION: > If the AXFR server consistently echoes the ID from the query in > all of its response messages, the AXFR client can easily correlate > all these response messages with the original query, and the copy > of the Query Section into subsequent response messages seems to > have no benefit, even in the case the server admits interleaving > of the ongoing AXFR transaction with other transactions on the > same TCP connection. > > Therefore, as a follow-up to the above DISCUSS: > Can we sensibly specify now than an EDNS0 capable AXFR server > servicing an EDNS0 client (i.e. after having sent an EDNS OPT RR > in the Additional Section of its first AXFR response message), > SHOULD refrain from repeating the Query Section from the AXFR > query in its subsequent response messages, if it consistently > echoes the query ID in all response messages ? Something I'd like to hear from those with implementation experience - is it worth the parsing time to save the bandwidth? Would this be an over-optimization? >(4c) 4th + 5th paragraph > >The draft seems to be ambiguous in its provisions for error >responses. It is reasonable to allow an AXFR server to 'abort' >a multi-message response at any time with a response message >containing a non-zero RCODE. Apparently, other parts of the >draft seem to support this position, but the text here doesn't >fully: > > An AXFR response that is indicating an error MUST consist of a > single DNS message with the return code set to the appropriate > value for the condition encountered - once the error condition is > detected. Such a message MUST copy the AXFR query Query Section > into its Query Section. > >With regard of the 1st paragraph of 2.2 stating ... > > The AXFR response will consist of 0 or more messages. > >.... the above text might be understood as nor supporting this >'late error' scenario. I guess that has not been intended, and >the subsequent (5th) paragraph strongly supports this interpretation. > >To rectify the issue, I propose to perform a slight amandment to the >3rd paragraph, rephrasing ... > > [...]. In such a series, the first message MUST begin with the SOA > resource record of the zone, the last message MUST conclude with the > same SOA resource record. [...] > >.... to state: > > [...]. In such a series, the first message MUST begin with the SOA > resource record of the zone, the last message MUST conclude with the > same SOA resource record, unless the response is prematurely aborted > by the server with an error message; see the discussion below. > [...] > >.... and to modify the 4th paragraph to say: > > An AXFR response that is indicating an error SHOULD consist of a > single DNS message with the return code set to the appropriate > value for the condition encountered. Under exceptional conditions, > e.g., a resource bottleneck or administrative intervention, a server > MAY prematurely abort a multi-message AXFR response in progress by > sending a response message with a non-zero RCODE. Any such error > message MUST copy the original AXFR query Query Section into its > Query Section. I don't think that that is acceptable, not from what I've heard in comments. First, the points are that a positive transfer begins and ends with SOA's. A transfer that encounters an error will send a single error response and terminate. Finally, although it is not a blessed action, it is possible that a server may decide not to respond at all for some reason. Even if such a server is considered to be non-compliant, a compliant client has to be prepared for such a possibility. The problem is that we hear from a wide range of religious views on this. We have folks that take the hard-line view that this is a client-server/query-response protocol and all actions deserve a reaction. It is hard to reconcile this against populists that say the world is broken and we need to account for not always pairing actions and reactions. The issue for me is that the divide is caused by implementers who are external to this process and aren't present to help hammer out some compromise by defending the rationale for "0 message" answers. The debate is not a head-butting-head situation, it's two off-kilter blows as is true in many long running sociological debates. Still, I can try to re-word this topic. There's not going to be anything that will keep all the different fundamentalist niches happy through. Do I sound cynical? >Once this modification has been adopted, the 5th paragraph can be >simplified: > > An AXFR client might receive a number of AXFR response messages > free of an error condition before the message indicating the error > is received. But once an error is reported, the AXFR client can > assume this the reporting message is the last. >--- > The AXFR client can savely assume that an error reporting message > (with non-zero RCODE) is the last response message for its query. > >Otherwise, s/this the/that this/ in the last line. > >(5b) Note 2.2.1.b > >Please improve the language. ... I'm sorry, I can't fix "English." ;) Sorry, couldn't resist. >(5c) Note 2.2.1.c, 2nd paragraph >DISCUSS: Promote SHOULD NOT to MUST NOT ? Or demote "SHOULD NOT" to "ought not"? >DISCUSS: > > Need to clarify whether SIG(0) / TSIG have to be applied > a) per message (in multi-message responses) or > b) per response (i.e., last message of multi-message responses) ? Per DNS message, that's what they are defined to cover, right? Yes, it seems this has been over looked in the TCP session cases. But knowing what was discussed back then that did not make it into text was the assumption that a response refers to a single message and not the session in the TSIG/SIG(0) definitions. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Fri Jun 13 13:24:24 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5FD3A690F; Fri, 13 Jun 2008 13:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.442 X-Spam-Level: **** X-Spam-Status: No, score=4.442 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUztFauImUl5; Fri, 13 Jun 2008 13:24:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A2DA83A688F; Fri, 13 Jun 2008 13:24:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7Fg2-000HSH-TU for namedroppers-data@psg.com; Fri, 13 Jun 2008 20:15:14 +0000 Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7Ffx-000HPi-0P for namedroppers@ops.ietf.org; Fri, 13 Jun 2008 20:15:12 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA108878063; Fri, 13 Jun 2008 22:14:23 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA26736; Fri, 13 Jun 2008 22:14:22 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200806132014.WAA26736@TR-Sys.de> Subject: Re: review of draft-ietf-dnsext-axfr-clarify-08 To: Ed.Lewis@neustar.biz Date: Fri, 13 Jun 2008 22:14:21 +0200 (MESZ) Cc: namedroppers@ops.ietf.org In-Reply-To: from Edward Lewis at Jun "13," 2008 "12:50:23" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Edward, thanks for your response to my review. However, I suspect having been misunderstood a bit regarding the error response issue. > Before committing the recommendations, here are some responses to the > discussion points. > > At 21:10 +0200 6/11/08, Alfred HÎnes wrote: >> ... >> >> (4) Section 2.2 >> ... >> (4c) 4th + 5th paragraph >> >> The draft seems to be ambiguous in its provisions for error >> responses. It is reasonable to allow an AXFR server to 'abort' >> a multi-message response at any time with a response message >> containing a non-zero RCODE. Apparently, other parts of the >> draft seem to support this position, but the text here doesn't >> fully: >> >> An AXFR response that is indicating an error MUST consist of a >> single DNS message with the return code set to the appropriate >> value for the condition encountered - once the error condition is >> detected. Such a message MUST copy the AXFR query Query Section >> into its Query Section. >> >> With regard of the 1st paragraph of 2.2 stating ... >> >> The AXFR response will consist of 0 or more messages. >> >> .... the above text might be understood as not supporting this >> 'late error' scenario. I guess that has not been intended, and >> the subsequent (5th) paragraph strongly supports this interpretation. >> >> To rectify the issue, I propose to perform a slight amendment to the >> 3rd paragraph, rephrasing ... >> >> [...]. In such a series, the first message MUST begin with the SOA >> resource record of the zone, the last message MUST conclude with the >> same SOA resource record. [...] >> >> .... to state: >> >> [...]. In such a series, the first message MUST begin with the SOA >> resource record of the zone, the last message MUST conclude with the >> same SOA resource record, unless the response is prematurely aborted >> by the server with an error message; see the discussion below. >> [...] >> >> .... and to modify the 4th paragraph to say: >> >> An AXFR response that is indicating an error SHOULD consist of a >> single DNS message with the return code set to the appropriate >> value for the condition encountered. Under exceptional conditions, >> e.g., a resource bottleneck or administrative intervention, a server >> MAY prematurely abort a multi-message AXFR response in progress by >> sending a response message with a non-zero RCODE. Any such error >> message MUST copy the original AXFR query Query Section into its >> Query Section. > > I don't think that that is acceptable, not from what I've heard in > comments. First, the points are that a positive transfer begins and > ends with SOA's. A transfer that encounters an error will send a > single error response and terminate. Finally, although it is not a > blessed action, it is possible that a server may decide not to > respond at all for some reason. Even if such a server is considered > to be non-compliant, a compliant client has to be prepared for such a > possibility. > > The problem is that we hear from a wide range of religious views on > this. We have folks that take the hard-line view that this is a > client-server/query-response protocol and all actions deserve a > reaction. It is hard to reconcile this against populists that say > the world is broken and we need to account for not always pairing > actions and reactions. The issue for me is that the divide is caused > by implementers who are external to this process and aren't present > to help hammer out some compromise by defending the rationale for "0 > message" answers. The debate is not a head-butting-head situation, > it's two off-kilter blows as is true in many long running > sociological debates. > > Still, I can try to re-word this topic. There's not going to be > anything that will keep all the different fundamentalist niches happy > through. > > Do I sound cynical? I purposely had avoided to touch the zero-message "response" case. [ Nevertheless and BTW, as you have asked for, here is my opinion on that topic as well: Yes, you sound cynical. But that's ok, because the legitimate user more and more suffering under such blackholing behavior perceives that as being treated cynically as well. Such behaviour IMHO is one of the most frequent sources of bad and annoying user experience. Applications having to go through long chains of DNS timeouts also effectively cause more (retry) traffic to the non- responding servers because negative caching is made impossible. Fallback to "zero-message response" should only be admitted if the server has clear indications of being under attack. Furthermore, in the case of TCP, receiving an error response allows the client to orderly and quickly close the connection, which in turn allows the server to reclaim connection resources faster, while still conforming to the TCP RFCs. ] The starting point, as quoted above, has been the sentence in the draft: An AXFR response that is indicating an error MUST consist of a single DNS message with the return code set to the appropriate value for the condition encountered - once the error condition is detected. [...] What if the error condition is detected after sending, say, fifty response messages? (E.g. the server being signalled to reload updated zone data during an already long running AXFR session.) Literally following the first part of the text above is impossible then, but the subsequent "once the error condition is detected" points out just that possible scenario, discussion of which apparently is continued in subsequent draft text (e.g. the 5th paragraph of that section - see quote below). My change proposals have purposely been crafted to always being conditional on *sending* an error message (at all), to avoid that sad battle. The whole discussion in my original notes only were concerned with the case that the server *does* send a response; if it doesn't, the circumstances under which to prematurely abort a running multi-message response will never arise. Sending the 'trailing' SOA in the abort case, after incomplete zone data, seems to be a bad idea, since 'old' clients possibly not expecting such error (and not testing for RCODE) might be misguided to take that matching SOA as an indication of a successful, *complete* zone transfer. >> Once this modification has been adopted, the 5th paragraph can be >> simplified: >> >> An AXFR client might receive a number of AXFR response messages >> free of an error condition before the message indicating the error >> is received. But once an error is reported, the AXFR client can >> assume this the reporting message is the last. >> --- >> The AXFR client can savely assume that an error reporting message >> (with non-zero RCODE) is the last response message for its query. >> >> ... >> DISCUSS: >> >> Need to clarify whether SIG(0) / TSIG have to be applied >> a) per message (in multi-message responses) or >> b) per response (i.e., last message of multi-message responses) ? > > Per DNS message, that's what they are defined to cover, right? Unfortunately, the TSIG/SIG(0) RFCs are ambiguous and disagree, as I had explained; the latter says 'message', the former says 'response'. > Yes, it seems this has been over looked in the TCP session cases. > But knowing what was discussed back then that did not make it into > text was the assumption that a response refers to a single message > and not the session in the TSIG/SIG(0) definitions. This confirms that a clarification is needed -- either in axfr-carify or in upcoming (?) 'bis' documents for TSIG and SIG(0). [ BTW: SIG(0) needs a self-contained specification anyway, after SIG / RFC 2535 which it is based upon has been obsoleted by DNSSEC-bis ! ] Since we are doing axfr-clarify now, we should do it there. Arguably, signing the whole transaction (concatenation of all messages) is what many other protocols do, and that choice would reduce the bandwidth needed and offload the server from crypto processing during a protected AXFR session. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ -- to unsubscribe send a message to namedroppers-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 Jun 13 13:24:43 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1413A682E; Fri, 13 Jun 2008 13:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYTt7z4vHrOr; Fri, 13 Jun 2008 13:24:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D78F83A688F; Fri, 13 Jun 2008 13:24:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7Ffw-000HQ2-PV for namedroppers-data@psg.com; Fri, 13 Jun 2008 20:15:08 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7Ffs-000HP6-NU for namedroppers@ops.ietf.org; Fri, 13 Jun 2008 20:15:06 +0000 Received: from [0.0.0.0] (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5DKEv6D036794; Fri, 13 Jun 2008 16:14:57 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Fri, 13 Jun 2008 16:05:53 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: AXFR open question Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: While contemplating the specter of "0 message responses" I thought about the situation in which a client sends an AXFR query and the server kills the connection before any response. The connection could "die" because of any number of reasons. Maybe the server shutdown its end or maybe some lower layer in the client decided the connection was unhealthy and closed its own end. Should an AXFR client assume that any outstanding queries will never be answered? Should the query ID's be recycled after some long period of time (even if the connection is brought back up)? We talk of an AXFR session, which consists of query and responses. A TCP connection is the transport supporting it. A session can be defined to use multiple transports, in parallel and consecutively (wrt time). Or do we want say that an AXFR session cannot "survive" the transport connection servicing it? And, in the face of a transport going away, is that to be taken as a temporary condition and call for a new attempt or say that the client ought to take that as something (umm, "more") fatal and not attempt a retry? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Fri Jun 13 18:29:41 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F6A3A6A15; Fri, 13 Jun 2008 18:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-hcsKdQaYUE; Fri, 13 Jun 2008 18:29:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C58553A69F7; Fri, 13 Jun 2008 18:29:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7KRV-00055o-Td for namedroppers-data@psg.com; Sat, 14 Jun 2008 01:20:33 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7KRR-00055O-Hq for namedroppers@ops.ietf.org; Sat, 14 Jun 2008 01:20:31 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id A7F02114021 for ; Sat, 14 Jun 2008 01:20:25 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id A9DE3E6029 for ; Sat, 14 Jun 2008 01:20:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m5CN59pI015145; Fri, 13 Jun 2008 09:05:10 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806122305.m5CN59pI015145@drugs.dv.isc.org> To: Frederico A C Neves , IETF DNSEXT WG From: Mark Andrews Mail-Followup-To: Frederico A C Neves , IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? In-reply-to: Your message of "Thu, 12 Jun 2008 10:19:05 -0300." <20080612131905.GA7724@registro.br> Date: Fri, 13 Jun 2008 09:05:09 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > On Wed, Jun 11, 2008 at 09:15:29PM -0400, Eastlake III Donald-LDE008 wrote: > > Doesn't matter how many paths there are or whether or not you are the > > "true" holder of the zone in the sense that people get to your data if > > they start at root. If you really care about security, you want your > > machines to never believe any RR sets in/under what YOU believe to be > > your zone unless they are signed YOUR keys. That's it. > > > > The fact that some RR set purporting to be in what you believe to be > > your zone has some signatures that can be validly traced back to a TLD > > or root or something doesn't matter for your policy. Your machines > > should assume such stuff is bad. And it doesn't matter if there is a > > second path back to your configured TA that fails. It's pretty easy to > > forge signatures that don't validate and that's something an attacker > > could add to the bad data they are feeding you. > > > > Just how paranoid a user organization would have to be to want such a > > policy is an interesting question. But eventually, if you assume > > widespread deployment of DNSSEC, why would you bother to configure a TA > > other than at root if you didn't have such a policy? > > Because the deployment scenario that is in our horizon is showing > large TLDs deploying DNSSEC and the root is not signed and latter it > will get signed and at that time the OR behavior will make the > transition more stable. Large TLD will have to continue TA management for there zones for the foreseeable future. They also have the resources and should have the expertise to do this forever. > We are not talking about private zones trusted by private entities, we > are talking about widespread deployment of DNSSEC on large zones that > are trusted by a large amount of resolvers. I think Donald and I are quite aware of what you are thinking about. However we are looking at the safe default from a security perspective. If you want to weaken your security we can't prevent you but we can atleast make you aware that you are doing something dangerous by making you do more work than the minimum of just adding a TA. > I'm not against the current behavior as long as it's optional and > could be signaled administratively for each TA. Which is the *wrong* default from a security perpective. Ease of admin shouldn't trump security. That's what you are asking for. > > Donald > > Fred > Mark -- 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 Jun 13 18:29:49 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E1063A6A15; Fri, 13 Jun 2008 18:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4yQsU+n2Apa; Fri, 13 Jun 2008 18:29:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A12393A69F7; Fri, 13 Jun 2008 18:29:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7KRi-000574-RF for namedroppers-data@psg.com; Sat, 14 Jun 2008 01:20:46 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7KRY-000569-6u for namedroppers@ops.ietf.org; Sat, 14 Jun 2008 01:20:44 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 8F5C4114085 for ; Sat, 14 Jun 2008 01:20:34 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 0254CE6023 for ; Sat, 14 Jun 2008 01:20:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m5CMmNwD015053; Fri, 13 Jun 2008 08:48:25 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806122248.m5CMmNwD015053@drugs.dv.isc.org> To: Paul Hoffman Cc: "IETF DNSEXT WG" From: Mark Andrews Subject: Re: Confusion about trust anchors and DS records from the parent? In-reply-to: Your message of "Thu, 12 Jun 2008 10:11:34 MST." Date: Fri, 13 Jun 2008 08:48:23 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > - You install a TA for .yourzone.com because you do not trust that > .com will be competent about keeping its children up to date. So for that TA to be useful you have also had to have made a mistake in your key management. You shouldn't be removing the old key before the new DS show up in the parent zone. Now please list the other threats that adding that TA can prevent. Mark -- 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 Jun 13 18:32:34 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46DA13A68F0; Fri, 13 Jun 2008 18:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElvlClF4vbWV; Fri, 13 Jun 2008 18:32:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 573513A67DB; Fri, 13 Jun 2008 18:32:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7KRZ-00056F-Ba for namedroppers-data@psg.com; Sat, 14 Jun 2008 01:20:37 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7KRU-00055a-9L for namedroppers@ops.ietf.org; Sat, 14 Jun 2008 01:20:34 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id E2D4F11407E for ; Sat, 14 Jun 2008 01:20:29 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 235C0E6027 for ; Sat, 14 Jun 2008 01:20:28 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m5CMggjv015026 for ; Fri, 13 Jun 2008 08:42:47 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806122242.m5CMggjv015026@drugs.dv.isc.org> To: "IETF DNSEXT WG" From: Mark Andrews Subject: Re: Confusion about trust anchors and DS records from the parent? In-reply-to: Your message of "Thu, 12 Jun 2008 10:11:34 MST." Date: Fri, 13 Jun 2008 08:42:42 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: OR is *not* a reasonable default. The reason for that is that when, not if, a bogus DS record is inserted into the chain of trust from the upper TA to your zone, your own validators will start accepting bogus data. Accepting bogus data is *much* worse than not accepting good data because you have failed to correctly keep your TA's up to date. The later can be corrected by updating the configuration to have a current TA or by removal of the deeper TA. I can accept that people might want to also accept a higher TA but that *has* to be a explicit decision that they make. This is only good security practice. Remember we can't compare to the web as all root certs are equal. DNS TA's have a heirarchical relationship to the data they are protecting. All DNS TA's are not equal and never have been equal. Having data go stale and good data not validate is one of the risks we accepeted to prevent bad data reaching us. This is independent of whether it is a TA, DS or RRSIG which is stale. Mark -- 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 Jun 13 19:20:58 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA8B3A699E; Fri, 13 Jun 2008 19:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZutmclyVyyX; Fri, 13 Jun 2008 19:20:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F1913A68F0; Fri, 13 Jun 2008 19:20:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7LHq-000BYW-HS for namedroppers-data@psg.com; Sat, 14 Jun 2008 02:14:38 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7LHm-000BXZ-Ew for namedroppers@ops.ietf.org; Sat, 14 Jun 2008 02:14:36 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6E8301143D for ; Sat, 14 Jun 2008 02:14:24 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "IETF DNSEXT WG" Subject: Re: Confusion about trust anchors and DS records from the parent? In-Reply-To: Your message of "Fri, 13 Jun 2008 08:42:42 +1000." <200806122242.m5CMggjv015026@drugs.dv.isc.org> References: <200806122242.m5CMggjv015026@drugs.dv.isc.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 14 Jun 2008 02:14:24 +0000 Message-ID: <71508.1213409664@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Mark Andrews > Date: Fri, 13 Jun 2008 08:42:42 +1000 > > OR is *not* a reasonable default. The reason for that is that > when, not if, a bogus DS record is inserted into the chain of > trust from the upper TA to your zone, your own validators will > start accepting bogus data. one of the several reasons why i'm having trouble finding a way to agree with this is that many validators will be inside networks which do not also secure any of their own zones. so the purpose which leads to the desire you're arguing against is different from the purpose which leads to the desire several of us are arguing for. as a concrete example, consider a wireless isp who enables validation in their caching/recursive dns servers. they might install a trust anchor for .SE and .ORG, and they might turn on trust anchor auto-tracking, but they might or might not sign their own "wireless-isp.net" zone. none of us wants these potentially-someday-stale trust anchors for .SE or .ORG to get in the way of DS RRs from the root zone. the alternative in which "wireless-isp.net" is signed, and because .NET is not signed there is a local trust anchor for "wireless-isp.net", and some day .NET becomes signed and has a potentially-bogus DS RR for the "wireless-isp.net" zone, is not what most people here are worrying about. it's not a concern for three reasons: first, because bogus DS RRs from a parent will be very rare; second, because a validator operator is very likely to *know* when a parent of one of its own zones becomes secure; and third, because if the default of OR is worrisome, they can override. > I can accept that people might want to also accept a higher > TA but that *has* to be a explicit decision that they make. > This is only good security practice. in terms of customer service costs, i can't accept nor recommend a default that will cause my phone to ring when things fail for no apparent reason. it's about a ten million times more likely that someone will fail to remove a stale trust anchor than that a bogus DS RR will cause them to believe in bogus data about their own zone. and also, you're wrong about what is a good security practice. any seasoned security professional will tell you that the strongest lock in the world won't protect you if you don't use it, and the harder that lock is to use, the less likely that it will be used. > Remember we can't compare to the web as all root certs are > equal. DNS TA's have a heirarchical relationship to the > data they are protecting. All DNS TA's are not equal and > never have been equal. i didn't forget that. i'd like the validation algorythm changed to say, explicitly, that local trust anchors whether static or RFC5011-tracked ought only to be used when one runs out of links on a chain of trust; in other words, as a last resort, when the in-band chain of trust ends. we should not even notice local TA's that would allow us to terminate early, until we've gone as far up the in-band hierarchy as we can, and then we should come back down searching for local TA's in least-enclosing order. > Having data go stale and good data not validate is one of > the risks we accepeted to prevent bad data reaching us. > This is independent of whether it is a TA, DS or RRSIG which > is stale. i see no reason to accept that risk. it's just not necessary. i think that if 4034/4035 fail to describe TA applicability then they are remiss, and if they are amended to describe it, then it must be a default of "OR" with a recommendation that "AND" or "ONLY" be specifiable local policies. -- to unsubscribe send a message to namedroppers-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 Jun 14 16:57:22 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CCE3A68F2; Sat, 14 Jun 2008 16:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.579 X-Spam-Level: X-Spam-Status: No, score=-4.579 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHzwC+sn3cL6; Sat, 14 Jun 2008 16:57:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA7613A682E; Sat, 14 Jun 2008 16:57:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7fP6-000Hml-5U for namedroppers-data@psg.com; Sat, 14 Jun 2008 23:43:28 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7fP0-000Hls-0j for namedroppers@ops.ietf.org; Sat, 14 Jun 2008 23:43:26 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m5ENgExG015255; Sat, 14 Jun 2008 23:42:16 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m5ENfx8B015246; Sat, 14 Jun 2008 23:41:59 GMT Date: Sat, 14 Jun 2008 23:41:59 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? Message-ID: <20080614234159.GA15225@vacation.karoshi.com.> References: <200806122242.m5CMggjv015026@drugs.dv.isc.org> <71508.1213409664@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71508.1213409664@sa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > i didn't forget that. i'd like the validation algorythm changed to say, > explicitly, that local trust anchors whether static or RFC5011-tracked > ought only to be used when one runs out of links on a chain of trust; in > other words, as a last resort, when the in-band chain of trust ends. we > should not even notice local TA's that would allow us to terminate early, > until we've gone as far up the in-band hierarchy as we can, and then we > should come back down searching for local TA's in least-enclosing order. > here you and I disagree. I beleive (and I -think- I heard others state) that the local trust anchor, whether static or RFC5011-tracked ought to be used -FIRST-. if one -always- starts at the root and works down, the concerns previously expressed wrt bw & cycles are more valid. starting w/ the closest/least enclosing order puts you -much- closer to local support ... reducing the opex on third parties. --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 Sun Jun 15 00:34:32 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91383A688A; Sun, 15 Jun 2008 00:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzl+DT4Rb-Ll; Sun, 15 Jun 2008 00:34:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81A7C3A63C9; Sun, 15 Jun 2008 00:34:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7mYq-000GEe-BN for namedroppers-data@psg.com; Sun, 15 Jun 2008 07:22:00 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7mYY-000GCr-Kn for namedroppers@ops.ietf.org; Sun, 15 Jun 2008 07:21:51 +0000 X-IronPort-AV: E=Sophos;i="4.27,647,1204498800"; d="scan'208";a="11696848" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2008 09:21:34 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5F7LY5k029681; Sun, 15 Jun 2008 09:21:34 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5F7LYwQ000888; Sun, 15 Jun 2008 07:21:34 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jun 2008 09:21:34 +0200 Received: from [192.165.72.13] ([10.61.80.144]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jun 2008 09:21:34 +0200 Cc: "IETF DNSEXT WG" Message-Id: <2AE0CB37-DA5D-4693-A43D-A8A41B733964@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Mark Andrews In-Reply-To: <200806122242.m5CMggjv015026@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: Confusion about trust anchors and DS records from the parent? Date: Sun, 15 Jun 2008 09:21:33 +0200 References: <200806122242.m5CMggjv015026@drugs.dv.isc.org> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 15 Jun 2008 07:21:34.0076 (UTC) FILETIME=[70BC6BC0:01C8CEB8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=684; t=1213514494; x=1214378494; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20Confusion=20about=20trust=20anchors=20a nd=20DS=20records=20from=20the=20parent?=20 |Sender:=20; bh=fYAGFApeNQje5WOKejmplzxEFu4Adffbn1UcepxCaa4=; b=EoAbdrBFWMzy9W6c6sHBge+mebKA3z73xGGLWp4KXbgNK1zD6295+YL0Aw kkTy9ZnP3wQg5F6v1J2mQNxS+rEV9s+3SnadFND685YMr6tpfepZyuEbYBng zIYl7cQrl9; Authentication-Results: ams-dkim-1; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 13 jun 2008, at 00.42, Mark Andrews wrote: > OR is *not* a reasonable default. The reason for that is that > when, not if, a bogus DS record is inserted into the chain of > trust from the upper TA to your zone, your own validators will > start accepting bogus data. I do not buy this argument at all. If bogus data (like NS or glue) are inserted in some parent of your zone, you are fried anyway. On the other hand, if you have a TA configured, and then you add a DS (but keep the TA during the deployment time), and then forget to remove your TA at the first key rollover, then you must allow the DS that is ok to say things are ok. Patrik -- to unsubscribe send a message to namedroppers-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 Jun 15 09:01:26 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0A13A6978; Sun, 15 Jun 2008 09:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpUaZ5Rjd9wq; Sun, 15 Jun 2008 09:01:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF35F3A68DA; Sun, 15 Jun 2008 09:01:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7uWn-0000af-Rr for namedroppers-data@psg.com; Sun, 15 Jun 2008 15:52:25 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7uWk-0000a0-7z for namedroppers@ops.ietf.org; Sun, 15 Jun 2008 15:52:23 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id BA1A111434 for ; Sun, 15 Jun 2008 15:52:16 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? In-Reply-To: Your message of "Sat, 14 Jun 2008 23:41:59 GMT." <20080614234159.GA15225@vacation.karoshi.com.> References: <200806122242.m5CMggjv015026@drugs.dv.isc.org> <71508.1213409664@sa.vix.com> <20080614234159.GA15225@vacation.karoshi.com.> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 15 Jun 2008 15:52:16 +0000 Message-ID: <40704.1213545136@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > i didn't forget that. i'd like the validation algorythm changed to say, > > explicitly, that local trust anchors whether static or RFC5011-tracked > > ought only to be used when one runs out of links on a chain of trust; in > > other words, as a last resort, when the in-band chain of trust ends. we > > should not even notice local TA's that would allow us to terminate early, > > until we've gone as far up the in-band hierarchy as we can, and then we > > should come back down searching for local TA's in least-enclosing order. > > here you and I disagree. I beleive (and I -think- I heard others > state) that the local trust anchor, whether static or RFC5011-tracked > ought to be used -FIRST-. > > if one -always- starts at the root and works down, the concerns > previously expressed wrt bw & cycles are more valid. starting w/ the > closest/least enclosing order puts you -much- closer to local support > ... reducing the opex on third parties. closest is most enclosing. i think you meant "closest/most" here. it's still OR, bill. no amount of "failure to validate", from any direction, will cause validation to fail in the above proposal, if there is so much as one good trust path. DNS is an internet subsystem, and as such, local TA's are bootstrapping aids, like root hints or /etc/hosts files. the bw & cycles needed to track upward as far as possible before searching back down for TA's is already going to be spent on validation of things that need & have no TA's. however, if this proposal is made controversial by the top-down TA search, then i'd support the following inferior alternative: "TA's whether static or RFC5011-tracked ought to be used only if they cause validation to terminate successfully, unless an explicit local policy is configured such that a TA must correctly validate when a chain of trust passes through the TA's domain." -- to unsubscribe send a message to namedroppers-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 Jun 15 16:37:29 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA9C3A689B; Sun, 15 Jun 2008 16:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEp1RpzlRPZP; Sun, 15 Jun 2008 16:37:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 25C5E3A67EF; Sun, 15 Jun 2008 16:37:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K81eL-000P97-TP for namedroppers-data@psg.com; Sun, 15 Jun 2008 23:28:41 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K81eH-000P8X-If for namedroppers@ops.ietf.org; Sun, 15 Jun 2008 23:28:39 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m5FNSULk014486; Mon, 16 Jun 2008 09:28:31 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806152328.m5FNSULk014486@drugs.dv.isc.org> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: "IETF DNSEXT WG" From: Mark Andrews Subject: Re: Confusion about trust anchors and DS records from the parent? In-reply-to: Your message of "Sun, 15 Jun 2008 09:21:33 +0200." <2AE0CB37-DA5D-4693-A43D-A8A41B733964@cisco.com> Date: Mon, 16 Jun 2008 09:28:30 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > On 13 jun 2008, at 00.42, Mark Andrews wrote: > > > OR is *not* a reasonable default. The reason for that is that > > when, not if, a bogus DS record is inserted into the chain of > > trust from the upper TA to your zone, your own validators will > > start accepting bogus data. > > I do not buy this argument at all. > > If bogus data (like NS or glue) are inserted in some parent of your > zone, you are fried anyway. So you don't believe that their will be configurations like this? zone mycompany.com { type stub; masters { .... }; file "mycompany.com.stub"; }; trusted-keys { mycompany.com ....; }; > On the other hand, if you have a TA configured, and then you add a DS > (but keep the TA during the deployment time), and then forget to > remove your TA at the first key rollover, then you must allow the DS > that is ok to say things are ok. No one is saying your senario won't happen. What we are saying is that the worst result with ONLY is not getting a answer. The worst result with OR is failing to detect deliberately bogus data. This is the main design goal of DNSSEC (detect and reject bad data) and you want to throw it out the window. > Patrik > -- 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 Jun 15 20:23:23 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E60C3A6A46; Sun, 15 Jun 2008 20:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnZIf5ohFm-I; Sun, 15 Jun 2008 20:23:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 454AD3A6A4B; Sun, 15 Jun 2008 20:23:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K85Be-000LIU-1K for namedroppers-data@psg.com; Mon, 16 Jun 2008 03:15:18 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K85BY-000LHv-Sv for namedroppers@ops.ietf.org; Mon, 16 Jun 2008 03:15:15 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m5G3F2dh016116; Mon, 16 Jun 2008 13:15:02 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806160315.m5G3F2dh016116@drugs.dv.isc.org> To: Paul Vixie Cc: "IETF DNSEXT WG" From: Mark Andrews Subject: Re: Confusion about trust anchors and DS records from the parent? In-reply-to: Your message of "Sat, 14 Jun 2008 02:14:24 GMT." <71508.1213409664@sa.vix.com> Date: Mon, 16 Jun 2008 13:15:02 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > From: Mark Andrews > > Date: Fri, 13 Jun 2008 08:42:42 +1000 > > > > OR is *not* a reasonable default. The reason for that is that > > when, not if, a bogus DS record is inserted into the chain of > > trust from the upper TA to your zone, your own validators will > > start accepting bogus data. > > one of the several reasons why i'm having trouble finding a way to agree > with this is that many validators will be inside networks which do not > also secure any of their own zones. so the purpose which leads to the > desire you're arguing against is different from the purpose which leads > to the desire several of us are arguing for. Paul no one is arguing that OR should not be a option. It should just not be the default option. It is a *bad* default. If a site wants to secure its own zones it should be as simple as adding a trust anchor for its own zones. It should not be add a trust anchor and by the way we need to remember to set this flag which says that this is a "ONLY" trust anchor otherwise we are leaving ourselves open for a attack via the registry system. Such attacks have succeeded in the past and they will succeed in the future. > as a concrete example, consider a wireless isp who enables validation in > their caching/recursive dns servers. they might install a trust anchor > for .SE and .ORG, and they might turn on trust anchor auto-tracking, but > they might or might not sign their own "wireless-isp.net" zone. none of > us wants these potentially-someday-stale trust anchors for .SE or .ORG > to get in the way of DS RRs from the root zone. This all reminds me of the BIND 4 days where named would "load" a zone despite errors in the master file. Errors in configuration files NEED TO BE FIXED not GLOSSED OVER. In the end they will come back to bite the operator. Everytime we have done this it has resulted in problems that would have been avoided if the software had just made the failure visible in addition to logging the problem. We know from experience that logs only get read when there is a visible problem. > the alternative in which "wireless-isp.net" is signed, and because .NET > is not signed there is a local trust anchor for "wireless-isp.net", and > some day .NET becomes signed and has a potentially-bogus DS RR for the > "wireless-isp.net" zone, is not what most people here are worrying about. > it's not a concern for three reasons: first, because bogus DS RRs from a > parent will be very rare; second, because a validator operator is very > likely to *know* when a parent of one of its own zones becomes secure; > and third, because if the default of OR is worrisome, they can override. > > > I can accept that people might want to also accept a higher > > TA but that *has* to be a explicit decision that they make. > > This is only good security practice. > > in terms of customer service costs, i can't accept nor recommend a default > that will cause my phone to ring when things fail for no apparent reason. You mean to say "configured trust anchor is stale" is not a apparent reason. I'm much more worried about what happens when we fail to stop a attack because the defaults were insecure. What is so difficult about something like: trusted-keys { "se" accept-parent-ds 257 3 5 "..."; or "se" accept-higher-trusted-keys 257 3 5 "..."; }; Also do you really want "dlv.isc.org" to validate back to a trust achor for ".", by default, when there is a explicit trust anchor for "dlv.isc.org"? I'm sure "." and "org" will attempt to do the right thing but the registration for "isc.org" will become a inviting target if the default is changed. Similarly for any other dlv tree. > it's about a ten million times more likely that someone will fail to remove > a stale trust anchor than that a bogus DS RR will cause them to believe in > bogus data about their own zone. and also, you're wrong about what is a > good security practice. any seasoned security professional will tell you > that the strongest lock in the world won't protect you if you don't use it, > and the harder that lock is to use, the less likely that it will be used. What's hard about adding a extra mode flag when you configure a trust anchor? > > Remember we can't compare to the web as all root certs are > > equal. DNS TA's have a heirarchical relationship to the > > data they are protecting. All DNS TA's are not equal and > > never have been equal. > > i didn't forget that. i'd like the validation algorythm changed to say, > explicitly, that local trust anchors whether static or RFC5011-tracked > ought only to be used when one runs out of links on a chain of trust; in > other words, as a last resort, when the in-band chain of trust ends. we > should not even notice local TA's that would allow us to terminate early, > until we've gone as far up the in-band hierarchy as we can, and then we > should come back down searching for local TA's in least-enclosing order. > > > Having data go stale and good data not validate is one of > > the risks we accepeted to prevent bad data reaching us. > > This is independent of whether it is a TA, DS or RRSIG which > > is stale. > > i see no reason to accept that risk. it's just not necessary. i think > that if 4034/4035 fail to describe TA applicability then they are remiss, > and if they are amended to describe it, then it must be a default of "OR" > with a recommendation that "AND" or "ONLY" be specifiable local policies. I strongly disagree. -- 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 Jun 15 20:57:41 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6A63A6A4E; Sun, 15 Jun 2008 20:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-RhvqsALLJ5; Sun, 15 Jun 2008 20:57:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D0163A6A4C; Sun, 15 Jun 2008 20:57:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K85mT-000PKI-Nx for namedroppers-data@psg.com; Mon, 16 Jun 2008 03:53:21 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K85mC-000PHh-1v for namedroppers@ops.ietf.org; Mon, 16 Jun 2008 03:53:13 +0000 X-IronPort-AV: E=Sophos;i="4.27,650,1204498800"; d="scan'208";a="11723573" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2008 05:52:56 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5G3que4022040; Mon, 16 Jun 2008 05:52:56 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5G3quLg010322; Mon, 16 Jun 2008 03:52:56 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 05:52:56 +0200 Received: from [192.165.72.13] ([10.61.80.144]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 05:52:54 +0200 Cc: Paul Vixie , "IETF DNSEXT WG" Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Mark Andrews In-Reply-To: <200806160315.m5G3F2dh016116@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: Confusion about trust anchors and DS records from the parent? Date: Mon, 16 Jun 2008 05:52:54 +0200 References: <200806160315.m5G3F2dh016116@drugs.dv.isc.org> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 16 Jun 2008 03:52:55.0228 (UTC) FILETIME=[75558FC0:01C8CF64] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1216; t=1213588376; x=1214452376; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20Confusion=20about=20trust=20anchors=20a nd=20DS=20records=20from=20the=20parent?=20 |Sender:=20; bh=kqA+yJclbbEw33qiCojfr0s3WtjQYI0CfIP/fwDU8Nw=; b=NI8MrlOfBIqTP8VwgmFK5X4ggxSzJvgZqdgVCRXQ8QRJqtQPpK7k95r2UH XJhoIcxlzNpmBavM/GsLmLBbg8UWCk0TEohnAbKN1k1nJYvvziSNNnyKk4D5 dxC6fw+V2k; Authentication-Results: ams-dkim-1; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 16 jun 2008, at 05.15, Mark Andrews wrote: > Paul no one is arguing that OR should not be a option. It > should just not be the default option. It is a *bad* > default. > > If a site wants to secure its own zones it should be as > simple as adding a trust anchor for its own zones. It > should not be add a trust anchor and by the way we need to > remember to set this flag which says that this is a "ONLY" > trust anchor otherwise we are leaving ourselves open for a > attack via the registry system. Such attacks have succeeded > in the past and they will succeed in the future. And this is where we disagree, and I do not think we will come much further in this discussion. I think, as you know by now, that it will be much more common to sign the DNS from leaf towards the root. This implies TA will be added first, and then DS later. Default operation will because of that be to "turn on DNSSEC" which will be to include a TA. And then forget it. A much more rare operation will be to add a TA that is to explicitly override data in parent zone. If you do so, then I definitely think one have to add the TA _AND_ turn on the ONLY setting. Patrik -- to unsubscribe send a message to namedroppers-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 Jun 15 21:35:28 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C2173A692B; Sun, 15 Jun 2008 21:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.904 X-Spam-Level: X-Spam-Status: No, score=-4.904 tagged_above=-999 required=5 tests=[AWL=-1.304, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 729M8LRbTJOe; Sun, 15 Jun 2008 21:35:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E8003A6876; Sun, 15 Jun 2008 21:35:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K86M1-0002yt-Qh for namedroppers-data@psg.com; Mon, 16 Jun 2008 04:30:05 +0000 Received: from [207.219.45.62] (helo=mx4.ca.afilias.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K86Lw-0002xw-QY for namedroppers@ops.ietf.org; Mon, 16 Jun 2008 04:30:02 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1K86Lw-0000BQ-7O; Mon, 16 Jun 2008 00:30:00 -0400 Message-ID: <4855EC43.2060702@ca.afilias.info> Date: Mon, 16 Jun 2008 00:29:55 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Mark Andrews CC: Paul Vixie , IETF DNSEXT WG Subject: Re: Confusion about trust anchors and DS records from the parent? References: <200806160315.m5G3F2dh016116@drugs.dv.isc.org> In-Reply-To: <200806160315.m5G3F2dh016116@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark Andrews wrote: > Paul no one is arguing that OR should not be a option. It > should just not be the default option. It is a *bad* > default. > > If a site wants to secure its own zones it should be as > simple as adding a trust anchor for its own zones. It > should not be add a trust anchor and by the way we need to > remember to set this flag which says that this is a "ONLY" > trust anchor otherwise we are leaving ourselves open for a > attack via the registry system. Such attacks have succeeded > in the past and they will succeed in the future. > It seems to me, and please tell me if I'm wrong, that there are two situations which the current things available, can't readily distinguish: (1) A stale TA, where the originator of the TA-signed data has rolled keys, or otherwise published new TA or DS for authenticators to use, and a valid thing to authenticate that validates per the "other" TA (e.g. signed root and proper delegations via DS) (2) A non-stale TA, and the TA-signed data is still valid and validated, with a rogue DS injected somewhere which hijacks a portion of the DNS below it that would also validate based on the rogue DS. What seems to be missing, is a way for a validator to be advised via signed-with-the-old-TA data that effectively marks the TA as stale. The question is, how long would such a record need to exist and be provided along with SOA data for a given zone? Consider two scenarios: (1) the root eventually gets signed (by eventually, meaning in a not-unreasonable length of time, as measured in political intervals - 2-5 years). (2) the root never gets signed In case 1, the typical need for TA distribution for zones is likely relatively rare, with a small number of key-rollover events. In case 2, TA distribution and key rollover is a big deal, and likely to occur, if not often, at least a number of times. If case 1 is likely, then "for a long time" or "forever" is reasonable for publishing revoked-TA records (signed with the TA itself). If case 2 is likely, then there is more of a reasonable requirement for anyone managing TAs to be aware of their existence and to handle failures properly. Does the idea of TA-revocation help disambiguate these cases? If so, then perhaps "OR" is not actually needed, and Mark's assertions are correct, but also lacking in the mechanism for properly identifying stale TAs in such a way as to be securely and validly be bypassed *only* if the zone admin for the TA publishes data to that effect - something that the zone admin not doing would enable simple TA set-up, and with doing, enabling sane default behavior for everyone whose view is more liberal on security than Mark's. (No offense to anyone involved in the discussion is intended, even by accident.) I can see both sides of the argument, and agree with both of them. It is in fact a paradox caused by the ambiguity of the fact that both a TA and a DS can be used to sign a zone, with no way of knowing *why* one works and the other doesn't, if they don't both validate. Brian -- to unsubscribe send a message to namedroppers-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 Jun 15 22:43:54 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8174A3A67D8; Sun, 15 Jun 2008 22:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQj1Sz6XNLIC; Sun, 15 Jun 2008 22:43:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C2A13A67D4; Sun, 15 Jun 2008 22:43:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K87QL-000APF-TG for namedroppers-data@psg.com; Mon, 16 Jun 2008 05:38:37 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K87QH-000AON-RG for namedroppers@ops.ietf.org; Mon, 16 Jun 2008 05:38:35 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7AA9D11432 for ; Mon, 16 Jun 2008 05:38:26 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "IETF DNSEXT WG" Subject: Re: Confusion about trust anchors and DS records from the parent? In-Reply-To: Your message of "Mon, 16 Jun 2008 13:15:02 +1000." <200806160315.m5G3F2dh016116@drugs.dv.isc.org> References: <200806160315.m5G3F2dh016116@drugs.dv.isc.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 16 Jun 2008 05:38:26 +0000 Message-ID: <66747.1213594706@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > in terms of customer service costs, i can't accept nor recommend a default > > that will cause my phone to ring when things fail for no apparent reason. > > You mean to say "configured trust anchor is stale" is not a > apparent reason. yes. because i do not expect validator operators to configure trust anchors at all, just like they don't configure stub zones at all, they will find their own zones via the registry system's NS RRs and they will decide whether or not to trust the keys used to sign those zones via the registry system's DS RRs. it's possible that rdns' ought to always configure stub zones for all "local" zones, in case the registry system is ever unreachable or corrupt. and it's similarly possible that vrdns' ought to do RFC5011 tracking of the trust anchors for "local" zones, for the same reasons. but since many rdns or vrdns don't have any "local" zones, and those that do, add and drop them over time, and there is no clear definition of what "local" means, and no widespread automation of any of this, i'm expecting vrdns and secure authoritative dns servers to be like ships in the night. in the common case, no trust anchors. in the uncommon case where a trust anchor is known, it's either because the registry system did not have the ability to convey DS RRs at the time a vrdns wanted to validate something, or because of operator conservatism along the lines you're describing ("maybe the registry will become corrupt somehow, and i'll start believing bad data about my own zones"). i believe that in this uncommon case where a trust anchor is known for something other than a TLD or for the root, the conservative operators will be the ones who know to set the ONLY option, and that the ahead-of-the-registry operators will be the ones most likely to never deconfigure a trust anchor after the registry starts spewing DS RRs. since usability is one of the major remaining problems in DNSSEC deployment (the other two being: lack of motivation, and lack of political will to sign the root and the TLDs), i have heightened sensitivity as to things that make DNSSEC even harder to use, and even more likely to fail, and fail silently, with no local expertise as to what's probably gone wrong, time and money lost, BIND taking the blame for it, and so on. > What's hard about adding a extra mode flag when you configure a > trust anchor? i was going to ask you the same. above, i explained why the onus ought to be on the conservative operators rather than on the early-adopting operators. > > i see no reason to accept that risk. it's just not necessary. i think > > that if 4034/4035 fail to describe TA applicability then they are remiss, > > and if they are amended to describe it, then it must be a default of "OR" > > with a recommendation that "AND" or "ONLY" be specifiable local policies. > > I strongly disagree. i suggest that if IETF thinks this is a local policy issue, unfit for mention in a dnssec updates document, that ISC punt it to the BIND Forum to decide. i would prefer that there be an explicit IETF standard so that BIND could just follow that. implementors must never "legislate from the bench." i think we have each made our case strongly, and if IETF can't discover a position based on what they've heard on this topic, each implementor should seek the counsel of its own user community. -- to unsubscribe send a message to namedroppers-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 Jun 16 03:55:42 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D163A6A96; Mon, 16 Jun 2008 03:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6mUVcfhp79e; Mon, 16 Jun 2008 03:55:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 12D383A683B; Mon, 16 Jun 2008 03:55:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8CDZ-000J7E-8L for namedroppers-data@psg.com; Mon, 16 Jun 2008 10:45:45 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8CDN-000J6E-LL for namedroppers@ops.ietf.org; Mon, 16 Jun 2008 10:45:39 +0000 Received: from guava.gson.org (a91-152-88-177.elisa-laajakaista.fi [91.152.88.177]) by gurgel.gson.org (Postfix) with ESMTP id A07517C8D7; Mon, 16 Jun 2008 10:45:27 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id DAFC0761A8; Mon, 16 Jun 2008 13:45:26 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18518.17478.887082.851140@guava.gson.org> Date: Mon, 16 Jun 2008 13:45:26 +0300 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: AXFR open question In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Edward Lewis wrote: > While contemplating the specter of "0 message responses" I thought > about the situation in which a client sends an AXFR query and the > server kills the connection before any response. > > The connection could "die" because of any number of reasons. Maybe > the server shutdown its end or maybe some lower layer in the client > decided the connection was unhealthy and closed its own end. > > Should an AXFR client assume that any outstanding queries will never > be answered? Yes. > Should the query ID's be recycled after some long > period of time (even if the connection is brought back up)? The query IDs can be recycled immediately, as they are only meaningful within the context of a given TCP connection (assuming they are used at all). > We talk of an AXFR session, which consists of query and responses. A > TCP connection is the transport supporting it. A session can be > defined to use multiple transports, in parallel and consecutively > (wrt time). No, not in the case of AXFR. > Or do we want say that an AXFR session cannot "survive" > the transport connection servicing it? Yes, this is what we should say. > And, in the face of a transport going away, is that to be taken as a > temporary condition and call for a new attempt or say that the client > ought to take that as something (umm, "more") fatal and not attempt a > retry? This, or any other AXFR error, should cause a retry after the zone's RETRY interval has passed. I believe the above reflects the behavior of the three AXFR implementations I have written as well as one I have read. -- 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 Mon Jun 16 04:27:10 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A753528C0F0; Mon, 16 Jun 2008 04:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rlm-M8RHl-1i; Mon, 16 Jun 2008 04:27:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 36F3E3A6A91; Mon, 16 Jun 2008 04:27:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8Cm1-000Moc-Dh for namedroppers-data@psg.com; Mon, 16 Jun 2008 11:21:21 +0000 Received: from [202.28.99.196] (helo=jade.coe.psu.ac.th) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8Clt-000Mnh-TE for namedroppers@ops.ietf.org; Mon, 16 Jun 2008 11:21:16 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m5GBIJKe024994; Mon, 16 Jun 2008 18:18:19 +0700 (ICT) Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by epsilon.noi.kre.to (8.14.2/8.14.2) with ESMTP id m5GBHt3H009506; Mon, 16 Jun 2008 18:17:55 +0700 (ICT) From: Robert Elz To: Mark Andrews cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "IETF DNSEXT WG" Subject: Re: Confusion about trust anchors and DS records from the parent? In-Reply-To: <200806152328.m5FNSULk014486@drugs.dv.isc.org> References: <200806152328.m5FNSULk014486@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Jun 2008 18:17:55 +0700 Message-ID: <1717.1213615075@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Date: Mon, 16 Jun 2008 09:28:30 +1000 From: Mark Andrews Message-ID: <200806152328.m5FNSULk014486@drugs.dv.isc.org> | No one is saying your senario won't happen. What we are | saying is that the worst result with ONLY is not getting a | answer. That is, the network doesn't work. I cannot imagine a much worse situation. Either I cannot use the net (which by the time DNSSEC is used by anyone who matters is likely to be used for all communications of all kinds in the world) to report the issue, to ask what to do about it, or if I manage to get my message out, no-one can find my DNS (because of some mis-configuration) to reply to me. | The worst result with OR is failing to detect | deliberately bogus data. Tell me how I do it? Note, I am not your parent, or anyone up your tree of delegations, I'm just some clown wanting to attack you. Assuming you have "or" configured, and I know that, what is the mechanism I use to cause a problem, and who is affected? If your answer starts with "trick your parent to ..." then I continue that with "delete your delegation completely" or "assign your delegation to me", after which you no longer exist in the first case, or I am now you in the second, and what I put about your domain is correct by DNS definition (it may not be what you wanted, but in the DNS, authority flows from the top, if a domain is delegated to me, it is mine, at least until it is moved again.) So, please avoid scenarios where I cause someone to alter your NS or DS records in the delegation zone, if I can manage to do that, DNSSEC won't help in any way at all (and nor should it.) You can however assume that I manage to find an accidentally misconfigured parent zone, or similar - given that, tell me how I go about introducing bogus data (or denying the existence of data that should exist). You also, of course, need to assume that dnssec is deployed and working correctly, in all aspects except some mis-config over which I, the attacker, have no control. (You can assume I can control my own data, and delegations to it, of course, if that somehow helps the attack.) If you can show a plausible scenario where an attack would work, then perhaps people might be more willing to listen, but so far all you're alluding to is accidental mis-config by parents (I'm not even sure what they could do that would have any of the problems you seem to be worried about, but that's not important right now). | This is the main design goal of | DNSSEC (detect and reject bad data) and you want to throw | it out the window. I agree with something Paul said a few messages back - I'll say it again in other words (I don't think I am misstating the position). The biggest enemy we have to any kind of security on the internet is the people who keep insisting that the security be perfect. It can never be, and continually looking for ways to make it perfect both delays the introduction of anything real, and causes the eventual "solution" (if one ever appears) to be so complex as to be unusable. All we need is to make things a bit more difficult than it is worth attacking for the benefits to be achieved from the attack. Or in this situation, if I can detect most easily introduced bad data (or make it too difficult for most people to try to introduce any) then we have succeeded. That it remains possible in some difficult to achieve manner to occasionally introduce some bad data that might be able to fool some people is not necessarily a huge defect - the various costs all need to be examined and trade-offs made. For most people, this is equivalent to using a $5 lock with a $2 chain to secure your bicycle - it won't necessarily stop everyone who might be determined to steal the thing, but it's enough to defer most casual thieves. It's also cheap enough, and easy enough to use, that people (many, or even most) are willing to actually implement it. What we don't want is $5000 multi-key locks, and $1000 toughened tungsten chains with extra capacity to lock down the wheels as well as the frame, all of which weighs too much to carry, takes half an hour to attach, all to protect something worth less than the cost of the protection. Nor do we want something whose idea of protection is to blow up the bicycle if someone attempts to make off with it - that certainly would prevent it being stolen, but to me, the end result would be the same. Protection that causes things to fail is worse than no protection at all. Of course, if you have something worthy of special protection, then you can take extra steps - those people may want the very high grade bicycle lock, or the "only my trust anchor" configuration - but they're far and away the minority. The default configuration should be for the ordinary user, with nothing very special worth protecting (or attacking) in any case, and no need for excessive security levels - but who do want things to keep on working, if at all possible. Almost finally, all your concerns seem to be about people attacking things so you can no longer believe your own data. For local use, if that's even remotely possible, why would you consider using the DNS for your own names at all? Use something safer instead. I do on some of my systems, not because of huge security concerns (what I use instead is probably less secure) but for robustness - I don't need DNS servers running in order to operate, and to me (for some things) that's important. But I always thought DNSSEC was mostly intended to allow me to verify data about your names, not so much about my own. How does any or your planned configuration allow me to more accurately determine which is your correct data and which is not, given I neither have, nor ever will have, anything special configured about your zone? That's the kind of thing DNSSEC is really trying to make secure - to allow me to determine which answer you authorised, and which you did not. Lastly, do remember, all this multi trust anchor stuff is happening only because of the difficulties getting anything rational done at the root (and other similar kinds of zones.) If it weren't for that, and DNSSEC deployment came top down, we would have had only one trust anchor, at the root, and everything else would have flowed from there. All this other nonsense is simply caused by people trying to live with the realities, ad yet still get whatever benefit they can out of dnssec. Practically that's needed, but it shouldn't be driving the security model. kre -- to unsubscribe send a message to namedroppers-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 Jun 16 07:05:53 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84CB23A67A2; Mon, 16 Jun 2008 07:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oJGVmR66Gxf; Mon, 16 Jun 2008 07:05:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 86A043A6810; Mon, 16 Jun 2008 07:05:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8FCu-000GeQ-UY for namedroppers-data@psg.com; Mon, 16 Jun 2008 13:57:16 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8FCa-000GZi-NG for namedroppers@ops.ietf.org; Mon, 16 Jun 2008 13:57:08 +0000 Received: from [0.0.0.0] (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5GDulkF067415; Mon, 16 Jun 2008 09:56:47 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200806152328.m5FNSULk014486@drugs.dv.isc.org> References: <200806152328.m5FNSULk014486@drugs.dv.isc.org> Date: Mon, 16 Jun 2008 09:52:08 -0400 To: "IETF DNSEXT WG" From: Edward Lewis Subject: Re: Confusion about trust anchors and DS records from the parent? Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 9:28 +1000 6/16/08, Mark Andrews wrote: > So you don't believe that their will be configurations like this? > > zone mycompany.com { > type stub; > masters { .... }; > file "mycompany.com.stub"; > }; > > trusted-keys { > mycompany.com ....; > }; > From my experience, there are a few things wrong with that. My internal infrastructure will see the inside split-DNS version of my zone, which I won't be bothering to sign because both the authority and iterative servers will behind the same security wall - the firewall(s) I have, or even within the same VPN. If I bothered to tighten up all of the internal infrastructure my opex costs would be prohibitive and I couldn't make use of ActiveDirectory. If I bothered to sign my external split-DNS zone, I certainly would not want that "leaked" back inside to my infrastructure. I mean, signed or not I don't want leaks. (I've seen situations at past places where there the value in the A record HAD TO BE different inside and outside.) But instead of being happier to see signed records, I would be sadder. Now, it might be that it seems like my design falls because I'm hardening the shell and not the insides. But that is the way many sites operate. The reason is, if the shell cracks, you have problems but you also know where to fix it. If you secure up the inside, it's often so complex you don't know if there's a compromise in the thickets. If there is a non-DOS attack, it's probably trying to get into my sensitive database. I'd rather be able to fight that without having getting tangled in all the other security reactions. I think I asked for this quite a while ago - a null key I could put in my zone apex so that if an iterator came down from a (signed) root, (signed) TLD, and saw that there was an external split-DNS zone I could get it to accept an unsigned internal split DNS zone. This comes to mind because I never could understand what the rationale was for signing the inside split-DNS zone. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Mon Jun 16 12:02:46 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8541F28C10B; Mon, 16 Jun 2008 12:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.685 X-Spam-Level: X-Spam-Status: No, score=-0.685 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHsTVMmUecMO; Mon, 16 Jun 2008 12:02:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 914CD28C0CF; Mon, 16 Jun 2008 12:02:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8JpB-000P8c-BR for namedroppers-data@psg.com; Mon, 16 Jun 2008 18:53:05 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8Jp4-000P6k-Ha for namedroppers@ops.ietf.org; Mon, 16 Jun 2008 18:53:03 +0000 Received: from [0.0.0.0] (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5GIqpo1070121; Mon, 16 Jun 2008 14:52:52 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Mon, 16 Jun 2008 14:52:49 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: another open question on AXFR clarify Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: What happens if a client has an open connection to an old style server (one that does not fill in the query ID or the answer section) and issues a first axfr request. Before the response finished, the client sends a second axfr request. How do these old style servers react? Do they ignore the request? Do they answer in a confusing manner (that is mashing the two responses together)? Or are they so single threaded that the second query isn't processed at all before finishing the first? I'm asking for as I am rewriting the sections on query ID. As in, when does a client know it is talking to a new AXFR server (one that can manage to not mangle responses). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Mon Jun 16 13:10:39 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F92E3A6B30; Mon, 16 Jun 2008 13:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBNeqjsv9ads; Mon, 16 Jun 2008 13:10:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5AE003A687A; Mon, 16 Jun 2008 13:10:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8KvQ-0007JJ-Lv for namedroppers-data@psg.com; Mon, 16 Jun 2008 20:03:36 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8KvM-0007GV-3t for namedroppers@ops.ietf.org; Mon, 16 Jun 2008 20:03:34 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5GK2xl4070672; Mon, 16 Jun 2008 16:03:01 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200806111910.VAA22263@TR-Sys.de> References: <200806111910.VAA22263@TR-Sys.de> Date: Mon, 16 Jun 2008 16:02:57 -0400 To: Alfred =?hp-roman8?B?SM5uZXM=?= From: Edward Lewis Subject: suggestion 5e Re: review of draft-ietf-dnsext-axfr-clarify-08 Cc: ed.lewis@neustar.biz, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I'm working my way through edits, reworking a lot of things in some places. Good comments and if I didn't make the specific change I made major edits to accommodate the spirit. But this one I am not inclined to make for two reasons. One is that I purposefully undid your suggestion, whereby I created the list of DNSSEC documents in the second paragraph. The reason was that I thought 3 reference links was too long a break for my short attention span. So I decided to just postpone the individual references. Also, I have grown tired of documents that do not repeat the full title of the RFC because in all of our jargon-filled tirades we sometimes lose the real meaning of the documents. Secondly, the reference to "the implementation" is in the context of this being a response field. Hence the "set to" has to be by the server and "upon receipt" is what happens at the client. Note that the distinction is whether the implementation does DNSSEC (hence conforms to RFC 4033-4035) or not. It's not that I disagree with your suggestion, it's that I had made a choice to go the other way here. I think both can work, but from my experience with RFCs, I think what's there now might be easier to swallow for an implementer. (Oh, so tempted to make an implementer's-reading-ability joke here.) At 21:10 +0200 6/11/08, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >(5e) Note 2.2.1.e > >I suggest to make the references to the DNSSEC specifications less >verbose. This *note* is not intended to become an introduction to >DNSSEC :-) >Furthermore, the 2nd sentence in 2.2.1.e seems to be too unspecific; >it does not properly address the possible cases of >DNSSEC-aware vs. -unaware AXFR cleints/servers. > >Here is my attempt to improve the text (further enhancements >solicited!): > > Note 2.2.1.e If the implementation supports the DNS Security Extensions > (see below) then this value MUST be set according to the rules in RFC > 4035, section 3.1.6, "The AD and CD Bits in an Authoritative Response". > If the implementation does not support the DNS Security Extensions, > then this value MUST be set to 0 and MUST be ignored upon receipt. > > The DNS Security Extensions (DNSSEC) is defined in these base > documents: > - "DNS Security Introduction and Requirements" [RFC4033] > - "Resource Records for the DNS Security Extensions" [RFC4034] > - "Protocol Modifications for the DNS Security Extensions" [RFC4035] >--- >|Note 2.2.1.e >| >| If the server implementation supports the DNS Security Extensions >| [RFC4033] [RFC4034] [RFC4035], then these bits MUST be set according >| to the rules in RFC 4035, section 3.1.6, "The AD and CD Bits in an >| Authoritative Response". If the AXFR server implementation does not >| support DNSSEC, then these bits MUST be set to 0. If the AXFR client >| does not support DNSSEC, or if it is aware of the fact that the >| server does not support DNSSEC (e.g., by configuration, by the lack >| of an EDNS0 OPT RR in the Additional Section of the first response >| message, or by other out-of-band mechanisms), it MUST ignore these >| bits. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Mon Jun 16 13:58:50 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD02328C159; Mon, 16 Jun 2008 13:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.658 X-Spam-Level: X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emaecvAppkD7; Mon, 16 Jun 2008 13:58:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA50E28C157; Mon, 16 Jun 2008 13:58:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8LhQ-000CRG-Bb for namedroppers-data@psg.com; Mon, 16 Jun 2008 20:53:12 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8LhM-000CQz-Q9 for namedroppers@ops.ietf.org; Mon, 16 Jun 2008 20:53:10 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5GKr1Wr070959; Mon, 16 Jun 2008 16:53:02 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <18518.17478.887082.851140@guava.gson.org> References: <18518.17478.887082.851140@guava.gson.org> Date: Mon, 16 Jun 2008 16:36:50 -0400 To: gson@araneus.fi (Andreas Gustafsson) From: Edward Lewis Subject: Re: AXFR open question Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Thanks for the info. At 13:45 +0300 6/16/08, Andreas Gustafsson wrote: ...and so on... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Mon Jun 16 14:00:35 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB6128C159; Mon, 16 Jun 2008 14:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7tMkMvWLlMs; Mon, 16 Jun 2008 14:00:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1EC2B3A68BD; Mon, 16 Jun 2008 14:00:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8LhW-000CSD-RF for namedroppers-data@psg.com; Mon, 16 Jun 2008 20:53:18 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8LhT-000CRd-0x for namedroppers@ops.ietf.org; Mon, 16 Jun 2008 20:53:17 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5GKr1Wt070959; Mon, 16 Jun 2008 16:53:06 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200806111910.VAA22263@TR-Sys.de> References: <200806111910.VAA22263@TR-Sys.de> Date: Mon, 16 Jun 2008 16:52:58 -0400 To: Alfred =?hp-roman8?B?SM5uZXM=?= From: Edward Lewis Subject: more "reactions" Re: review of draft-ietf-dnsext-axfr-clarify-08 Cc: ed.lewis@neustar.biz, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In the spirit of letting you know why some changes weren't (yet) made... At 21:10 +0200 6/11/08, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >(7) Section 3.1, 2nd paragraph >To clarify these exceptional cases, I suggest to amend the second >sentence of this paragraph, e.g. (for clarity, I recommend >splittin the paragraph into 3 parts): I decided to just remove the section - the section should just talk about the contents and not the ordering. >(8) Section 3.2 ff. > >There are a couple of instances where the draft does not use >'rational quotation' (treating quotes around terms or short phrases >as text enhancements like the [impossible] underlining, subject to >evident rules for pairing/nesting). I'm going to leave this to the RFC Editor. My learnin' says differently, if there was a book on grammar and stuff that convinced me I was wrong I'd change my ways. >(9) Section 3.2, reason 4) and subsequent 'Editorial Note' > >IMO, this discussion is out of scope. It should be deferred to a >future IXFR-bis draft. Still there because I hope the commentor can fill in the blanks I have. >(10b) last paragraph > >I suggest to improve the wording of the very last sentence: > > [...]. This document leaves AXFR over UDP undefined, > with the issue to be discussed and possibly appear in a separate >| definition. >---^^^^^^ > [...]. This document leaves AXFR over UDP undefined, > with the issue to be discussed and possibly appearing in a separate >| specification. > ^^^^^^^^^ ^^^ I was going to not do this, but decide to lop off the last two lines completely. "Possibly appear" vs. "Possibly appearing" - to me the former has a subtle hint that this is less likely than the latter. As in "if it'll happen it's possibly appear after I retire" versus "when it comes out it will be possibly appearing in a document by John." Yeah, maybe the latter grammer is poor, but that's way you might hear someone say it (not write it). In either case, no one has revived a discussion on AXFR/UDP since the IETF in, well, where ever, so I'm not going to promote it anymore. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Mon Jun 16 15:05:45 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D473A6B45; Mon, 16 Jun 2008 15:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBS+PqilyTag; Mon, 16 Jun 2008 15:05:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D04AC3A6B35; Mon, 16 Jun 2008 15:05:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8Mi1-000Jch-1J for namedroppers-data@psg.com; Mon, 16 Jun 2008 21:57:53 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8Mhx-000JZn-DU for namedroppers@ops.ietf.org; Mon, 16 Jun 2008 21:57:51 +0000 Received: from commandprompt.com (227-54-222-209.mycybernet.net [209.222.54.227]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m5GLxSc4010122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Jun 2008 14:59:31 -0700 Date: Mon, 16 Jun 2008 17:57:42 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Issue for discussion in draft-ietf-dnsext-dnssec-rsasha256 Message-ID: <20080616215742.GA66314@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Mon, 16 Jun 2008 14:59:32 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, Jelte Jansen (the current editor of draft-ietf-dnsext-dnssec-rsasha256) was going on vacation, but he asked me to raise the following issue on the list so that he could attempt to deal with it when he returns. Please comment. Anything unclear about the outline below is undoubtedly my fault, and not Jelte's. In draft-ietf-dnsext-dnssec-rsasha256-04, we have at present the following text in section 5.1: If both RSA/SHA-2 and RSA/SHA-1 RRSIG resource records are available for a certain RRset, with a secure path to their keys, the validator SHOULD ignore the SHA-1 signature. If the RSA/SHA-2 signature does not verify the data, and the RSA/SHA-1 signature does, the validator SHOULD mark the data with the security status from the RSA/SHA-2 signature. The text may be inconsistent with the current text in RFC 4035, section 5.3.1. This is a variant of the issue we've been discussing lately with respect to Trust Anchors. The current I-D text entails behaviour that might surprise some administrators. Suppose that a validator knows about SHA-2 signatures, and receives an RRset with both SHA-1 and SHA-2 RRSIG resource records. If for some innocent reason the validator cannot at that moment validate the SHA-2 signature but _could_ validate the SHA-1 signature, the validator would nevertheless have to treat the RRset as bogus by virtue of the SHA-2 failure. Since the DNSKEY has to have been verified anyway, one could argue that there is no problem to solve here, and the text could be removed. Others might argue that the presence of the two signatures could be a sign of a downgrade attack. That is the reasoning behind including this text in the first place. It appears there are three options: 1. Remove the text. It's not needed. 2. Keep the text, and mark the current document as updating RFC4035, because it is changing the rules of section 5.3.1 of RFC4035. 3. Keep the text, and don't do anything else. This text is not changing the meaning of RFC4035, and there's nothing in RFC4035 or any of the other DNSSEC RFCs to require validators to follow the trust chain using every available algorithm they support. The editor tells me he'd appreciate comments to the list about this issue. Best regards, Andrew -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- to unsubscribe send a message to namedroppers-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 Jun 16 17:55:14 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46AF43A6884; Mon, 16 Jun 2008 17:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHBTQS-AfroV; Mon, 16 Jun 2008 17:55:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C3FA3A6803; Mon, 16 Jun 2008 17:55:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8PNk-000CtZ-A0 for namedroppers-data@psg.com; Tue, 17 Jun 2008 00:49:08 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8PNf-000Css-P3 for namedroppers@ops.ietf.org; Tue, 17 Jun 2008 00:49:06 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m5H0mqGP048462; Tue, 17 Jun 2008 10:48:53 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806170048.m5H0mqGP048462@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: another open question on AXFR clarify In-reply-to: Your message of "Mon, 16 Jun 2008 14:52:49 -0400." Date: Tue, 17 Jun 2008 10:48:52 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > What happens if a client has an open connection to an old style > server (one that does not fill in the query ID or the answer section) > and issues a first axfr request. Before the response finished, the > client sends a second axfr request. Remember old style servers just have a implementation bug in that they failed to set the ID on all messages in the response stream. We clearly saw it as a bug when it was pointed out. The fact that it wasn't picked up earlier was due to another bug (lack of checking of ID on the client side). Basic DNS design has the response id match the request id. This clearly was not happening so it was a bug. > How do these old style servers react? > Do they ignore the request? Some will. Some versions of named forked to return AXFR so they only accepted one AXFR request as they couldn't be sure the server hadn't been updated. > Do they answer in a confusing manner (that is mashing the two > responses together)? Could happen if they are not aware they have the bug and they process multiple axfr requests on the one socket. named does not fall into this category. > Or are they so single threaded that the second > query isn't processed at all before finishing the first? Some will. > I'm asking for as I am rewriting the sections on query ID. As in, > when does a client know it is talking to a new AXFR server (one that > can manage to not mangle responses). > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Never confuse activity with progress. Activity pays 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: -- 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 Mon Jun 16 20:16:10 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5C73A691C; Mon, 16 Jun 2008 20:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGK9lA5tnwgr; Mon, 16 Jun 2008 20:16:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B0A683A692D; Mon, 16 Jun 2008 20:16:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8RZQ-00039r-Ht for namedroppers-data@psg.com; Tue, 17 Jun 2008 03:09:20 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8RZM-00038R-8Z for namedroppers@ops.ietf.org; Tue, 17 Jun 2008 03:09:18 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5H39BoA092706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 20:09:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080616215742.GA66314@commandprompt.com> References: <20080616215742.GA66314@commandprompt.com> Date: Mon, 16 Jun 2008 20:08:48 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: Issue for discussion in draft-ietf-dnsext-dnssec-rsasha256 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 5:57 PM -0400 6/16/08, Andrew Sullivan wrote: >In draft-ietf-dnsext-dnssec-rsasha256-04, we have at present the >following text in section 5.1: > > If both RSA/SHA-2 and RSA/SHA-1 RRSIG resource records are available > for a certain RRset, with a secure path to their keys, the validator > SHOULD ignore the SHA-1 signature. If the RSA/SHA-2 signature does > not verify the data, and the RSA/SHA-1 signature does, the validator > SHOULD mark the data with the security status from the RSA/SHA-2 > signature. > >The text may be inconsistent with the current text in RFC 4035, >section 5.3.1. It is also inconsistent with itself. Let's say I have two RRSIG resource records, one RSA/SHA-2 and one base on RSA/SHA-1. According to the first sentence, I really have just one to consider, the former one. Therefore, in the second sentence, "and the RSA/SHA-1 signature does" can never be true because I have already ignored that signature. >Others might argue that the presence of the two signatures could be a >sign of a downgrade attack. Quite true. The presence of two signatures that have different security properties *always* could be a sign of a downgrade attack. For example, I have two RRSIG resource records, one RSA-1024/SHA-2 and one base on RSA-2048/SHA-2. This could be a downgrade attack because Mallory has broken RSA-1024. Or, RSA-2048-KEYA/SHA-2 and RSA-2048-KEYB/SHA-2; Mallory could have social engineered getting the private part of KEYB. Or ECDSA-256/SHA-2 and RSA-2048/SHA-2. Or ... Either cover all the crypto downgrade cases, or cover none. It is impossible to cover them all. In specific, even though many people believe that SHA-2 is stronger than SHA-1 for preimage attacks (the ones we care about), no one has even a shred of proof of that. Something in SHA-2 could actually make preimage attacks easier than for SHA-1 and we won't know it for ten years. That's unlikely, but possible. If we bake in "ignore RSA/SHA-1 if there is an RSA/SHA-2" with no firm proof, we can things worse, not better. The alternative is to rely on the community to hear if there is ever a preimage attack on SHA-1 that affects signatures, and to then move rapidly to SHA-2. Ditto for RSA-1024. And so on. Put another way, if there is a good* preimage attack on SHA-1, DNSSEC is low on the list of our worries. As long as we have a transition mechanism *in place* for SHA-2, the attack can be thwarted in a short period of time. >1. Remove the text. It's not needed. Plus, strongly encourage adoption of the document. Test often. Publicly wag fingers at implementations that cannot support RSA/SHA-2 within a year of the standard being published. Every few years, consider deprecating RSA/SHA-1 to a SHOULD and promoting RSA/SHA-2 to a MUST for DNSSEC (yes, it's grandstanding, but it helps). (* "Good" means "reduces the effective strength from 160 to 80 or less". An attack that reduces it from 160 to 110, for example, is really impressive academically but doesn't help Mallory in the slightest because he cannot do 2^110 operations during the lifetime of the key (or the solar system...).) --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 17 04:41:39 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B933A6A74; Tue, 17 Jun 2008 04:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.637 X-Spam-Level: X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ab+2K2IopfmK; Tue, 17 Jun 2008 04:41:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF05C3A6A1D; Tue, 17 Jun 2008 04:41:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8ZS2-000CCN-TJ for namedroppers-data@psg.com; Tue, 17 Jun 2008 11:34:14 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8ZRv-000CBH-9N for namedroppers@ops.ietf.org; Tue, 17 Jun 2008 11:34:12 +0000 Received: from [0.0.0.0] (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5HBXtWB004721; Tue, 17 Jun 2008 07:33:56 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080616215742.GA66314@commandprompt.com> References: <20080616215742.GA66314@commandprompt.com> Date: Tue, 17 Jun 2008 07:33:49 -0400 To: Andrew Sullivan From: Edward Lewis Subject: Re: Issue for discussion in draft-ietf-dnsext-dnssec-rsasha256 Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 17:57 -0400 6/16/08, Andrew Sullivan wrote: >The text may be inconsistent with the current text in RFC 4035, >section 5.3.1. This is a variant of the issue we've been discussing >lately with respect to Trust Anchors. I'd boil this problem down to - what was not anticipated during the development of DNSSEC was that some cryptographic protections are better than others. We had always assumed any cryptographic operation had the same meaning as any other. We did, for a time, measure the length of chains, but that was a measure of the number of operations and not the value of an individual operation. There's no guarantee that if there is a SHA-1 and SHA-2 for a set of data that you will see both (better stated - you will notice of one is missing). The signatures ensure the RRSet's integrity but do not protect the RRSet plus signatures. And there's no way in DNSSEC to try to retrieve a (suspected) missing signature. >The current I-D text entails behaviour that might surprise some >administrators. Suppose that a validator knows about SHA-2 >signatures, and receives an RRset with both SHA-1 and SHA-2 RRSIG >resource records. If for some innocent reason the validator cannot at >that moment validate the SHA-2 signature but _could_ validate the >SHA-1 signature, the validator would nevertheless have to treat the >RRset as bogus by virtue of the SHA-2 failure. Besides administrators - what about implementers? What if the failure is that the SHA-2 inception time is in the future and the SHA-1 validates now? (Let's assume the local clock is correct, but, you can see how this can be done by taking over the system clock...oh, wait, if that happens your DNS problems are not the most important.) >Since the DNSKEY has to have been verified anyway, one could argue >that there is no problem to solve here, and the text could be >removed. > >Others might argue that the presence of the two signatures could be a >sign of a downgrade attack. That is the reasoning behind including >this text in the first place. I think this is a problem rooted in "slapped on security" - when ever I have seen security bolted onto an existing system there is always the uncertainty that it might be stripped off on the way because the system also has to look like the old days for an old days element (client). Secondly, the problem is rooted in that there's a conflict between cryptographic algorithm "instability" and the stability needed in infrastructure code. Even a strong-today cryptographic algorithm eventually becomes a weak-today algorithm. We infrastructure folks aren't too used to putting in "succession planning" into our protocols to account for mechanisms that fade in value. (EDNSx anyone?) What I am trying to say is that any good solution here is doomed. I think we have to stick with the "OR" principle or else we risk cutting people off the network. DNSSEC shouldn't cause outages because of cryptographic book keeping mistakes. >It appears there are three options: > >1. Remove the text. It's not needed. > >2. Keep the text, and mark the current document as updating RFC4035, >because it is changing the rules of section 5.3.1 of RFC4035. > >3. Keep the text, and don't do anything else. This text is not >changing the meaning of RFC4035, and there's nothing in RFC4035 or any >of the other DNSSEC RFCs to require validators to follow the trust >chain using every available algorithm they support. I think the proposed text is wrong, it is conflict with 4035's "OR" principle. However, noting the situation described as exceptional may hint to an implementor to log this or even try to integrate with some management console and report it via SNMP. A lot of times it helps to have knowledge of these things going to security experts even if it doesn't cut the user off the network. >The editor tells me he'd appreciate comments to the list about this >issue. He better bring back presents for the WG. Or at least send a postcard. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays 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 Tue Jun 17 05:41:34 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053803A6AF0; Tue, 17 Jun 2008 05:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.786 X-Spam-Level: X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WP8QBTFJRJT; Tue, 17 Jun 2008 05:41:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 94B863A698A; Tue, 17 Jun 2008 05:41:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8aOp-000LA7-HO for namedroppers-data@psg.com; Tue, 17 Jun 2008 12:34:59 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8aOU-000L7o-RG for namedroppers@ops.ietf.org; Tue, 17 Jun 2008 12:34:50 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5HCYUW0014429 for ; Tue, 17 Jun 2008 08:34:31 -0400 Message-ID: <4857AF56.4080308@nist.gov> Date: Tue, 17 Jun 2008 08:34:30 -0400 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Issue for discussion in draft-ietf-dnsext-dnssec-rsasha256 References: <20080616215742.GA66314@commandprompt.com> In-Reply-To: <20080616215742.GA66314@commandprompt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew Sullivan wrote: > > In draft-ietf-dnsext-dnssec-rsasha256-04, we have at present the > following text in section 5.1: > > If both RSA/SHA-2 and RSA/SHA-1 RRSIG resource records are available > for a certain RRset, with a secure path to their keys, the validator > SHOULD ignore the SHA-1 signature. If the RSA/SHA-2 signature does > not verify the data, and the RSA/SHA-1 signature does, the validator > SHOULD mark the data with the security status from the RSA/SHA-2 > signature. > > The text may be inconsistent with the current text in RFC 4035, > section 5.3.1. This is a variant of the issue we've been discussing > lately with respect to Trust Anchors. > Sounds like something we would have punted (in the old days) as "local policy". :) > > Others might argue that the presence of the two signatures could be a > sign of a downgrade attack. That is the reasoning behind including > this text in the first place. > > It appears there are three options: > > 1. Remove the text. It's not needed. > This sounds the easiest. It might lead to some confusing for implementors, but by now most implementors know enough about security to ask someone who knows more about security :) > 2. Keep the text, and mark the current document as updating RFC4035, > because it is changing the rules of section 5.3.1 of RFC4035. > > 3. Keep the text, and don't do anything else. This text is not > changing the meaning of RFC4035, and there's nothing in RFC4035 or any > of the other DNSSEC RFCs to require validators to follow the trust > chain using every available algorithm they support. > #3 might be confusing to people who don't know DNSSEC RFC's inside an out. I don't think the text is inconsistent with Section 5.3.1, but I don't think the text is necessary either. So I can live with #1. Scott > The editor tells me he'd appreciate comments to the list about this > issue. > > Best regards, > > Andrew > -- ---------------------------------------- Scott Rose Computer Scientist NIST ph: +1 301-975-8439 scott.rose@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Jun 19 19:20:22 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0C1F3A67B7; Thu, 19 Jun 2008 19:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.535 X-Spam-Level: X-Spam-Status: No, score=-99.535 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRN8Bdc55NTb; Thu, 19 Jun 2008 19:20:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D17A23A6839; Thu, 19 Jun 2008 19:20:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K9W1M-000FDR-Em for namedroppers-data@psg.com; Fri, 20 Jun 2008 02:06:36 +0000 Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K9W1H-000FCN-WC for namedroppers@ops.ietf.org; Fri, 20 Jun 2008 02:06:34 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1K9W18-0000DJ-HO; Fri, 20 Jun 2008 04:06:22 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1K9W18-0001lL-6z; Fri, 20 Jun 2008 04:06:22 +0200 From: Florian Weimer To: Jesper G. =?iso-8859-1?Q?H=F8y?= Cc: Subject: Re: Anti DNS spoofing - Extended Query ID (XQID) References: <07a001c8a5fe$ce2952b0$6a7bf810$@com> <82r6cvwhxq.fsf@mid.bfk.de> <07d101c8a636$9470bbc0$bd523340$@com> Date: Fri, 20 Jun 2008 04:06:22 +0200 In-Reply-To: <07d101c8a636$9470bbc0$bd523340$@com> ("Jesper G. =?iso-8859-1?Q?H=F8y=22's?= message of "Thu, 24 Apr 2008 20:11:10 +0200") Message-ID: <87k5gkuag1.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Jesper G. H=F8y: >> This is a problem because some servers will return error >> responses when you query a subdomain of an existing name. Some will >> even drop the query. > > I haven't tested extensively, but I have not run into that situation so f= ar. > Do you have any examples of such servers? Right now, the name servers for www.cnn.com do not answer queries for 1.www.cnn.com. This seems to be the result of some sort of DNS loadbalancer/failover mechanism; other zones following the same delegation pattern share this behavior. I haven't yet figured out what products/configuration guidelines are involved in these cases, though. -- to unsubscribe send a message to namedroppers-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 Jun 19 20:24:35 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A77C3A68EC; Thu, 19 Jun 2008 20:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roBMUTjTdRgF; Thu, 19 Jun 2008 20:24:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 964133A68BA; Thu, 19 Jun 2008 20:24:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K9X5u-000ONk-LL for namedroppers-data@psg.com; Fri, 20 Jun 2008 03:15:22 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K9X5q-000ONB-Si for namedroppers@ops.ietf.org; Fri, 20 Jun 2008 03:15:20 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m5K3F6vM026326; Fri, 20 Jun 2008 13:15:06 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806200315.m5K3F6vM026326@drugs.dv.isc.org> To: Florian Weimer Cc: "Jesper G. =?iso-8859-1?Q?H=F8y?=" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Anti DNS spoofing - Extended Query ID (XQID) In-reply-to: Your message of "Fri, 20 Jun 2008 04:06:22 +0200." <87k5gkuag1.fsf@mid.deneb.enyo.de> Date: Fri, 20 Jun 2008 13:15:06 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > * Jesper G. H=F8y: > > >> This is a problem because some servers will return error > >> responses when you query a subdomain of an existing name. Some will > >> even drop the query. > > > > I haven't tested extensively, but I have not run into that situation so f= > ar. > > Do you have any examples of such servers? > > Right now, the name servers for www.cnn.com do not answer queries for > 1.www.cnn.com. This seems to be the result of some sort of DNS > loadbalancer/failover mechanism; other zones following the same > delegation pattern share this behavior. I haven't yet figured out what > products/configuration guidelines are involved in these cases, though. They also don't appear to answer anything but A and AAAA queries. Or for srv _http._tcp.www.cnn.com. Mind you there is nothing really new here. A lot of load balancer vendors seem to feel that they can break the DNS protocol with impunity. Name and shame may be the only way to correct this behaviour. Mark -- 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 Jun 20 06:32:18 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F6A3A6929; Fri, 20 Jun 2008 06:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+K4TeDQRkoZ; Fri, 20 Jun 2008 06:32:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 190A03A68E3; Fri, 20 Jun 2008 06:32:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K9gZS-0007zX-4V for namedroppers-data@psg.com; Fri, 20 Jun 2008 13:22:30 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K9gZN-0007yl-9E for namedroppers@ops.ietf.org; Fri, 20 Jun 2008 13:22:27 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5KDMFf3004166 for ; Fri, 20 Jun 2008 09:22:15 -0400 Message-ID: <485BAF09.3040109@nist.gov> Date: Fri, 20 Jun 2008 09:22:17 -0400 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: IETF DNSEXT WG Subject: [Fwd: New Version Notification for draft-crocker-dnssec-algo-signal-00] Content-Type: multipart/mixed; boundary="------------020201020007070708030407" X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --------------020201020007070708030407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI: A new individual submission from Steve Crocker and myself. It details a possible crypto algorithm signaling method for a client to list the algorithms it knows about to a server. The goal is twofold: 1. hopefully reduce response size from zones signed with multiple algorithms 2. track the implementation of new algorithms in client software to get a better understanding of when complete a rollover from a weaker algorithm to a new stronger algorithm. Please read the draft and send comments to us. We would like to ask the WG if this can become a DNSEXT WG document during the Dublin meeting (if agenda permits). Thanks, Scott --------------020201020007070708030407 Content-Type: message/rfc822; name="New Version Notification for draft-crocker-dnssec-algo-signal-00.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-crocker-dnssec-algo-signa"; filename*1="l-00.eml" X-Account-Key: account2 X-Mozilla-Keys: Return-Path: Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by fs4.antd.nist.gov (8.13.6/8.13.6) with ESMTP id m5KCxX1m018163 for ; Fri, 20 Jun 2008 08:59:33 -0400 Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id m5KCxN68005896 for ; Fri, 20 Jun 2008 08:59:24 -0400 Received: from spamav2.nist.gov (spamav2.nist.gov [129.6.13.239]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5KCxJYh019115 for ; Fri, 20 Jun 2008 08:59:19 -0400 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by spamav2.nist.gov (8.14.1/8.14.1) with ESMTP id m5KCxJZA002939 for ; Fri, 20 Jun 2008 08:59:19 -0400 Received: by core3.amsl.com (Postfix, from userid 30) id 6B2263A6A82; Fri, 20 Jun 2008 05:59:17 -0700 (PDT) From: IETF I-D Submission Tool To: scott.rose@nist.gov Cc: steve@shinkuro.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20080620125917.6B2263A6A82@core3.amsl.com> Date: Fri, 20 Jun 2008 05:59:17 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7160:2.4.4,1.2.40,4.0.166 definitions=2008-06-20_02:2008-06-19,2008-06-20,2008-06-20 signatures=0 X-PP-SpamDetails: rule=spampolicy2_notspam policy=spampolicy2 score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0805090000 definitions=main-0806200038 X-PP-SpamScore: 0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: wwwrun@core3.amsl.com Subject: New Version Notification for draft-crocker-dnssec-algo-signal-00 X-NIST-MailScanner-Information: X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on fs4.antd.nist.gov X-Virus-Status: Clean X-UID: 53783 X-Keywords: A new version of I-D, draft-crocker-dnssec-algo-signal-00.txt has been successfuly submitted by Scott Rose and posted to the IETF repository. Filename: draft-crocker-dnssec-algo-signal Revision: 00 Title: Signaling Cryptographic Algorithm Understanding in DNSSEC Creation_date: 2008-06-20 WG ID: Independent Submission Number_of_pages: 8 Abstract: The DNS Security Extensions (DNSSEC) was developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. Each digital signature added to a response increases the size of the response, which could result in the response message being truncated. This draft sets out to specify a way for clients to signal to a server which cryptographic algorithms they prefer in a DNSSEC response by defining an EDNS option to list a client's preferred algorithms. The IETF Secretariat. --------------020201020007070708030407-- -- to unsubscribe send a message to namedroppers-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 Jun 20 08:49:00 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097BC3A698B; Fri, 20 Jun 2008 08:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jZ4xOpaWxpu; Fri, 20 Jun 2008 08:48:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D21ED3A68E3; Fri, 20 Jun 2008 08:48:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K9iiv-0000Ux-R2 for namedroppers-data@psg.com; Fri, 20 Jun 2008 15:40:25 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K9iio-0000Tw-SC for namedroppers@ops.ietf.org; Fri, 20 Jun 2008 15:40:24 +0000 Received: from Puki.ogud.com (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5KFeF9R049246 for ; Fri, 20 Jun 2008 11:40:15 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200806201540.m5KFeF9R049246@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Jun 2008 11:39:56 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Happy Birthday: DNS is 25 years old Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: According to: >Subject: Re: DNS birthday >>At 10:38 26/07/2007, Paul V. Mockapetris wrote: >We celebrate the birthday on June 23, based on a 1983 birth. We should be thankful for the great design that Paul (and his collaborators) created, that has allowed the computer network to grow from O(10^3) devices to O(10^9) so far. I think this is a good time for us reflect on the history and impact of DNS on our lifes. Feel free to make public reflections on the DNS protocol here on namedroppers. Olafur PS: A nice birthday present for DNS would be for a Web Site dedicated to the history of DNS, evolution, and its impact. In addition I would like the site to incorporate the suggestion from Mark Andrews for "The DNS hall of shame" -- to unsubscribe send a message to namedroppers-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 Jun 20 09:40:54 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BBD73A685A; Fri, 20 Jun 2008 09:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3gBLWXf5HbY; Fri, 20 Jun 2008 09:40:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CFC403A63D2; Fri, 20 Jun 2008 09:40:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K9jXw-0007qA-7J for namedroppers-data@psg.com; Fri, 20 Jun 2008 16:33:08 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K9jXs-0007pd-8Z for namedroppers@ops.ietf.org; Fri, 20 Jun 2008 16:33:05 +0000 Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id C075F399B81; Fri, 20 Jun 2008 09:33:03 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=UFs7nDUgT73OxBahnSWXYgCigq4=; b=fP1vPHCGmlRGg7Tr0qL/sYss4rQwE9er+zcxF3bdwJGiuHp8CVKzirBEcjBhcn8svu507UQsoO39gzC/4pF/kBkxPhGuqW8hO5tww/mHo/VnjTzmGiwNkphz4y2heTt814esOKdJRsPxnX+wBb9BwNFdZu6VafvZmfJFWm5Y4Lk= Received: by wes.hardakers.net (Postfix, from userid 274) id 9696F399B82; Fri, 20 Jun 2008 09:33:03 -0700 (PDT) From: Wes Hardaker To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org Subject: Re: Happy Birthday: DNS is 25 years old Organization: Sparta References: <200806201540.m5KFeF9R049246@ogud.com> Date: Fri, 20 Jun 2008 09:33:03 -0700 In-Reply-To: <200806201540.m5KFeF9R049246@ogud.com> (Olafur Gudmundsson's message of "Fri, 20 Jun 2008 11:39:56 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >>>>> On Fri, 20 Jun 2008 11:39:56 -0400, Olafur Gudmundsson said: OG> PS: A nice birthday present for DNS would be for a Web Site dedicated OG> to the history of DNS, evolution, and its impact. Maybe this is a good starting spot: http://en.wikipedia.org/wiki/Domain_Name_System (remember, everything already exists on wikipedia and is 100% trustable). -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to unsubscribe send a message to namedroppers-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 Jun 20 11:28:44 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9593A6A3B; Fri, 20 Jun 2008 11:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69IM5v2Btcy7; Fri, 20 Jun 2008 11:28:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C3E043A6807; Fri, 20 Jun 2008 11:28:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K9lCj-000LGO-W9 for namedroppers-data@psg.com; Fri, 20 Jun 2008 18:19:21 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K9lCf-000LFj-EU for namedroppers@ops.ietf.org; Fri, 20 Jun 2008 18:19:19 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 6DBA9C2DA3; Fri, 20 Jun 2008 19:19:12 +0100 (BST) Date: Fri, 20 Jun 2008 19:19:09 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Wes Hardaker , Olafur Gudmundsson cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Happy Birthday: DNS is 25 years old Message-ID: In-Reply-To: References: <200806201540.m5KFeF9R049246@ogud.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 20 June 2008 09:33:03 -0700 Wes Hardaker wrote: > (remember, everything already exists on wikipedia and is 100% trustable). Sadly wikipedia data and DNS data suffer from similar trust problems. 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 Jun 22 06:00:56 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C63928C0F8; Sun, 22 Jun 2008 06:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.096 X-Spam-Level: ** X-Spam-Status: No, score=2.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GYBKOZSjgs8; Sun, 22 Jun 2008 06:00:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A92D028C0F9; Sun, 22 Jun 2008 06:00:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KAP1H-0009mj-57 for namedroppers-data@psg.com; Sun, 22 Jun 2008 12:50:11 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KAP16-0009l2-6W for namedroppers@ops.ietf.org; Sun, 22 Jun 2008 12:50:08 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KAP12-0002Ve-Nc; Sun, 22 Jun 2008 14:49:56 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 3FDF445D7; Sun, 22 Jun 2008 14:50:09 +0200 (CEST) Date: Sun, 22 Jun 2008 14:50:09 +0200 From: bert hubert To: Peter Koch Cc: IETF DNSEXT WG Subject: Re: Review of draft-ietf-dnsext-forgery-resilience-03.txt Message-ID: <20080622125008.GA18011@outpost.ds9a.nl> References: <20080527095222.GC25686@unknown.office.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080527095222.GC25686@unknown.office.denic.de> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hello Peter, Many thanks for your long and thoughtful reaction. Please find my reaction and resulting edits below. I've left out things on which I consider myself to have no expertise, like if this document should be BCP or standards track. > > Resolver: a nameserver performing recursive service for clients, > > also known as a caching server > > Instead of introducing new definitions and thus contributing to language > confusion, the document could borrow (with references) from earlier > publications. This beast is either a "resolver" (per RFC 1034), a "full- > service resolver (as per RFC 1123, 6.1.3.1) or a "recursive name server" > (as per RFC 4033). The definition in 1034 is too short, the one in 1123 is too long and lists requirements, 4033 does not define a recursive name server. I added a reference to 'full service resolver' and 1123: - Resolver: a nameserver performing recursive service for clients, also known as a caching server + Resolver: a nameserver performing recursive service for clients, also known as a caching server, or a full service resolver (, paragraph 6.1.3.1) > > Stub resolver: a very limited Resolver on a client computer, that > > leaves most of the recursing work to a full resolver > > See above. Why only "most of the recursing work"? Fixed. > > Question: a question sent out by a resolver, typically in a UDP > > Again, the usual terminology is "query" and "response", where "question" most > often refers to the actual question section in the packet (see RFC 1034). Fixed. > > Third party: any host other than the resolver or the intended > The resolver isn't defined as a host but as a piece of software above, so > "third party" is any entity different from the resolver or authoritative > name server. Fixed. > > Authentic answer: the answer that would be accepted if no third > > party interferes > > That's true, but kind of a reverse definition. The authentic response > is the one that originates from the true/real host using the target IP address > of the query. It should carry authentic data, but that's a subtly different > issue. Fixed, new: Authentic answer: the correct answer that comes from the right authoritative server > > Target domain: domain for which the attacker wishes to spoof in an > > answer > This phrase is used only once more in the draft, so it might not even be > necessary. > In any case, since the target is a particular node in the hierarchy rather > than a subtree, I'd use 'target domain name' here. Fixed. I've left it in because it helps frame the mindset needed for the rest of the document. > > The words below are aimed at authors of resolvers: it is up to > > operators to decide which nameserver implementation to use, or which > > options to enable. Operational constraints may override the security > > concerns described below. However, implementations are expected to > > allow an operator to enable functionality described in this document. > > The operational considerations need to be discussed somewhere! Well, I'm open to suggestions. Earlier feedback indicated this document should steer well clear of operational guidelines. I'm more than willing to include more wording on this subject, or to suggest other places for discussions. > > Prediction' and 'Name Chaining'. Furthermore, it emphasises a number > > of existing rules and guidelines embodied in the relevant STDs and > > RFCs. The following also specifies new requirements to make sure the > > Since "STDs" are a subset of "RFCs", "relevant DNS protocol specifications" > should suffice, maybe with a list of references already given here. Fixed. > > When certain steps are taken it is feasible to 'spoof' the current > > deployed majority of caching resolvers with carefully crafted and > > "caching resolvers" isn't among the list of defined terms. Fixed. > > To understand how this process works it is important to know what > > makes a resolver (and more specifically a caching server) accept an > > answer. > > The definitions section claims that "resolver" and "caching server" are > equivalent. Fixed. > > The following sentence in section 5.3.3 of [RFC1034] presaged the > > present problem: > > > > The resolver should be highly paranoid in its parsing of responses. > > It should also check that the response matches the query it sent > > using the ID field in the response. > > > > DNS data is to be accepted by a resolver if and only if: > > Now is this "normative" or the "emphasis" mentioned earlier? I'm unsure what you mean with this, or the following. Do you want to add references to each line? > > 3. The answer comes from the same network address the question was > > sent to > > RFC 2181, section 4. (2181 is missing from the normative references) Fixed. > > If a third party succeeds in meeting the four conditions before the > > answer from the authentic answer does so, it is in a position to feed > > "from the authentic _name server_"? Fixed. > > 4. Details > > I'd suggest a more descriptive headline: "Detailed Description of Spoofing > Scenarios" or something along that line. Fixed. > > 4.1. Forcing a question > > > > Formally, there is no need for a nameserver to perform service except > > for its operator, its customers or more generally its users. > > Recently, open recursing nameservers have been used to amplify denial > > of service attacks. > > A reference to [draft-ietf-dnsop-reflectors-are-evil-05.txt] might help here. Done. > > In spite of this, many resolvers perform at least partial service for > > the whole world. This is partially out of lack of concern, and is > > reminiscent of the open relay SMTP service the net enjoyed up to the > > early 1990s. Some access providers may serve so many subnets that it > > is hard to enumerate these all in the DNS configuration. > > > > Providing full service enables the third party to send the target > > resolver a question for the domain name it intends to spoof. On > > receiving this question, and not finding the answer in its cache, the > > resolver will transmit questions to relevant authoritative > > nameservers. This opens up a window of opportunity for getting fake > > answer data accepted. > > The two preceding paragraphs appear a bit verbose to me without completely > addressing the attack scenarios. It is important to state that even if > recursive service is restricted to "local" clients, a remote attacker can > induce DNS queries by other levels of indirection, e.g. using SMTP dialogues, > inline images in websites etc. Removed the "In spite of this" paragraph, added: ' Questions may however be forced indirectly, for example by inducing a mail server to perform DNS lookups.' > > The time to live of the 'target domain' determines how often a window > > "of the target domain name's RRSets" Fixed. > > Most domains have two or three authoritative nameservers, which make > s/most domains/many zones/; Fixed. > > nameserver. While two Best Current Practice documents ([RFC2827] and > > [RFC3013] specifically) direct Internet access providers to prevent > This is a basic premise that IMHO should be elevated to the top of this section. > Without being able to spoof the source address, the odds of hitting the right > one are irrelevant. Done. > > 4.5. Matching the destination address of the authentic answer > > This is more about the destination port than the destination address, isn't it? Added 'and port'. It might also be about the destination *address* since the local address from which queries are generated might be unknown, and often is in case of load balanced resolvers. > > If multiple ports are used for sending questions, this enlarges the > > effective address space by a factor equal to the number of ports > > used. > > s/effective address space/effective ID space/ Done. > > It should be noted that a firewall will not prevent the matching of > > this address, as it will accept answers that (appear) to come from > > the correct address, offering no additional security. > > This assumes a stateless packet filter? Even with a stateful packet filter, it won't help. > It might be worth mentioning NAT explicitly here since port rewriting at the > NAT might actually reduce the effect of port randomization (RFC 4787). Hmm - perhaps. But perhaps not. I'd hate for more discussion to ensue. > > its spoofed answer, typically in the order of at most 100ms > > (depending on the network distance to the authentic authoritative > > nameserver). > > This figure comes out of the blue? Yes - it might be 10ms, it might be 1000ms. Hence 'in the order'. > > 5. Birthday attacks > > > > The so called birthday paradox implies that a group of 23 people > > suffices to have a more than even chance of having two or more > > members of the group share a birthday. > > > > An attacker can benefit from this exact phenomenon if it can force > > the target resolver to have multiple equivalent outstanding questions > > at any one time to the same authoritative server. > > Only if these queries use different IDs, so "equivalent" needs to be > specified more clearly. > > > Any packet the attacker sends then has a much higher chance of being > > accepted because it only has to match any of the outstanding queries > > for that single domain. Compared to the birthday analogy above, of > > the group composed of questions and answers, the chance of having any > > of these share an ID rises quickly. > > > > As long as small numbers of questions are sent out, the chance of > > successfully spoofing an answer rises linearly with the number of > > outstanding questions for the exact domain and nameserver. > > > > For larger numbers this effect is less pronounced. > > > > More details are available in US-CERT [vu-457875]. > > Now, section 5 is only descriptive without any obvious connclusions. > First, I'd rather see this in an appendix and the "thou shalt not have > multiple outstanding queries with QNAME/QTYPE/QCLASS to the same > name server share the query ID or source port number" made explicit. > > > 6. Accepting only in-zone answers > > in-domain (see below). > > > Answers from authoritative nameservers often contain information that > > is not part of the zone for which we deem it authoritative. As an > > example, a query for the MX record of a domain might get as its > > answer a mail exchanger in another domain, and additionally the IP > > address of this mail exchanger. > > > > If accepted uncritically, the resolver stands the chance of accepting > > data from an untrusted source. Care must be taken to only accept > > data if it is known that the originator is authoritative for that > > data. > > Since the resolver doesn't and shouldn't know about zone cuts, you can't > determine this. So, it's "authoritative for that zone containing the data > or for any parent". > > > One very simple way to achieve this is to only accept data if it is > > part of the domain we asked the question for. > > Correct here. > > However, this whole section is independent of the rest, so I'd suggest to > re-order a bit (which will be done by moving 7 and 8 to the appendix, > see below). > Also, this recommendation is the one that aims at "name chaining", so it > might want to explicitly say that. Also, some example could help here: > > ;; QUESTION SECTION: > ;Example.NET. IN MX > > ;; ANSWER SECTION: > Example.NET. 86400 IN MX 10 mx1.example.org. > > ;; AUTHORITY SECTION: > Example.NET. 86400 IN NS ns3.example.org. > Example.NET. 86400 IN NS ns2.example.com. > Example.NET. 86400 IN NS ns1.Example.NET. > > ;; ADDITIONAL SECTION: > mx1.example.org. 86400 IN A 192.0.2.16 > ns1.Example.NET. 86400 IN A 192.0.2.32 > ns2.example.com. 86400 IN A 192.0.2.64 > ns3.example.org. 86400 IN AAAA 2001:DB8::53 > > The resolver SHOULD/MAY ignore all RRSets not owned at or below Example.NET. > > > 7. Combined difficulty > > > > Given a known or static destination port, matching ID field, source > > and destination address requires on average in the order of 2 * 2^15 > > = 65000 packets, assuming a domain has 2 authoritative nameservers. > > s/domain/zone/ > > > If the window of opportunity available is around 100ms, as assumed > > above, an attacker would need to be able to briefly transmit 650000 > > packets/s to have a 50% chance to get spoofed data accepted on the > > first attempt. > > [...] > > This whole section I'd also rather see in an appendix, otherwise it distracts > from the actual recommendations. > > > 8. Discussion > > > > The calculations above indicate the relative ease with which DNS data > > can be spoofed. For example, using the formula derived earlier on a > > domain with a 3600 second TTL, an attacker sending 7000 fake answer > > s/domain/RRSet/ > > > packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a > > record in the first 24 hours, which rises to 50% after a week. > > > > For a domain with a TTL of 60 seconds, the 10% level is hit after 24 > > s/domain/RRSet/ > > > minutes, 50% after less than 3 hours, 90% after around 9 hours. > > > > Note that the attacks mentioned above can be detected by watchful > > server operators - an unexpected incoming stream of 4.5mbit/s of > > packets might be noticed. > > > > An important assumption however in these calculations is a known or > > static destination port of the authentic answer. > > > > If that port number is unknown and needs to be guessed as well, the > > problem space expands by a factor of 64000, leading the attacker to > > need in excess of 285Gb/s to achieve similar success rates. > > > > Such bandwidth is not generally available, nor expected to be so in > > the foreseeable future. > > This whole section 8 also should go into an appendix, since it is a > calculation example based on figures estimated around tghe time of writing. > While it supports the claim that spoofing is doable, there's no immediate > recommendation following. > > > Note that some firewalls may need reconfiguring if they are currently > > setup to only allow outgoing queries from a single DNS source port. > > This important operational consideration needs to be more prominently > adddressed (see below). > > > 9. Countermeasures > > More explicit: "Recommendations" or "Recommended Countermeasures" Done. > > > Given the above, a resolver implementation MUST match answers to the > > following attributes of the question: > > > > o Remote address > > > > o Local address > > More precisely: The response source IP address MUST match the query's > destination IP address and the response destination IP address MUST match > the query's source IP address. Done. > > > o Query port > would this include UDP source (whatever that's worth) and destination > ports? Yes. > > o Query ID > > o Question name (compared case-insensitively) > > o Question class and type > > Use QNAME, QCLASS and QTYPE here. Please discuss with Paul - I'm not making further changes on this without consensus anymore. > > > before applying DNS trustworthiness rules. A mismatch should be > > considered a format error, and the answer invalid. > > So, instead of ignoring the fake response, will see a FORMERR or a SERVFAIL? The fake response is ignored in the sense that its data is not trusted. Paul outlined the reasons for this being a format error, but I don't recall the exact reasons. > Maybe use >= 1024 and give some reasoning for the choice to avoid "privileged" > ports discussion. Some ports are definitely bad choices (e.g. the "daytime" > port) anyway, so starting at 1024 is OK, but needs and explanation. "Please note that source ports could be selected from a larger range than indicated, but that this range is regarded as safe, with some lower port numbers reserved for activities which might conflict with proper DNS operation." > > o Use multiple different source ports simultaneously in case of > > multiple outstanding questions; > > Shouldn't this be independent of the number of active queries? It is very hard to use multiple different source ports simultaneosly with only one outstanding question :-) I don't recall where this specific wording came from, but it was recommened by someone. > > In case these abilities are enabled, the implementation MUST strive > > to have its choices of source port and question ID remain > > unpredictable, even if an attacker has knowledge of its > > (pseudo-)random generator. > > "MUST strive to" is a strange use of normative language. The mathematicians and cryptologists didn't like me mandating unpredictiveness - since this is an impossible goal formally. > > Resolvers SHOULD favour authoritative nameservers with which a trust > > relation has been established; > > That would need an explanation ... Came from TSIG proponents. > > Stub-resolvers SHOULD be able to use > > > TSIG ([RFC2845]) or IPSEC ([RFC2401]) when communicating with their > > recursive resolver. > > This is out of the scope of this document, isn't it? It does resolve the problem. > > In case a cryptographic verification of answer validity is available, > > resolver implementations MAY waive above rules, and rely on this > > guarantee instead. > > Why not name "cryptographic verification" DNSSEC? However, "answer validity" > isn't what DNSSEC delivers. Secure DNS might be more than DNSSEC one day, hence the broader wording. > > For brevity's sake, in lieu of repeating the security considerations > > references, the reader is referred to these sections. > > delete these 2 lines. They were added on specific request because some people, apparently, only read the 'Security' section. > > The above notwithstanding, it should be noted that using a low Time > > To Live for DNS records raises the chances of an attacker spoofing a > > resolver. > > Now, is this an operational recommendation? No - it only notes. I wrote this paragraph for you, feel free to tweak it. It was felt that it would be useful to make *note* of the impact of a low TTL, but not proscribe operational behaviour. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > > Requirement Levels", BCP 14, RFC 2119, March 1997. > > RFC 2181 missing here as normative reference. Added. > > [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the > > Internet Protocol", RFC 2401, November 1998. > > move to informative, same for probably all of the remaining references Done. > Also, it should be more explicit as to what the actual novelty is, probably > right away in the Security Considerations: > > ``This document recommends the use of UDP source port number randomization > to extend the effective DNS transaction ID beyond the available 16 bits.'' Done. Please see your changes on http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/21 Thanks! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source 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 Jun 23 09:47:13 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FFD73A697E; Mon, 23 Jun 2008 09:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.163 X-Spam-Level: X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_63=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChIWDcS9HUJZ; Mon, 23 Jun 2008 09:47:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED90F3A68B5; Mon, 23 Jun 2008 09:47:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KAp2l-000Evw-Qf for namedroppers-data@psg.com; Mon, 23 Jun 2008 16:37:27 +0000 Received: from [76.96.62.96] (helo=QMTA09.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KAp2P-000Ete-RN for namedroppers@ops.ietf.org; Mon, 23 Jun 2008 16:37:17 +0000 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA09.westchester.pa.mail.comcast.net with comcast id hPVU1Z00J1GhbT8590Qr00; Mon, 23 Jun 2008 16:37:05 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA07.westchester.pa.mail.comcast.net with comcast id hUcU1Z00T2P9w053TUcVE6; Mon, 23 Jun 2008 16:36:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=xKe8Z-5y34EA:10 a=uUnk1H2WmvYA:10 a=GIkoug0YZtL9KhvrVQIA:9 a=NOdRPNe7sBYcGBH6V2MA:7 a=4r0PpM8_lpTVF0icJrzHOpuV9oEA:4 a=lZB815dzVvQA:10 a=BZcC-Fvy4-IA:10 a=50e4U0PicR4A:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Jun 2008 12:36:31 -0400 To: Scott Rose ,IETF DNSEXT WG From: Michael StJohns Subject: Re: [Fwd: New Version Notification for draft-crocker-dnssec-algo-signal-00] In-Reply-To: <485BAF09.3040109@nist.gov> References: <485BAF09.3040109@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: Hi Scott - I took a look at this and comments follow. On the topic of whether or not to make this a WG document, I wouldn't oppose it, but if we're triaging new work, I also wouldn't put it very high up on the priority list. I'm not sure it will have all that much benefit for the amount of implementation required and I'm also not sure that it meets the "do no harm" test - it might do no harm, but it appears to be a complicating extension and may actually add to fragility by restricting the signed data available to get an answer at various places. Specific comments: You specify a priority order in section 2 for algorithms - but in section 4 the phrasing is "most preferred" without limiting the number of "most preferred". I assume you want "the single highest priority algorithm present" or do you want to permit the two or three highest priority ones? Maybe the option should indicate the number requested? Section 3 2nd para - "or has a trust anchor for" - should probably be "and has a trust anchor for" Section 3 - you dealt with the combination of this option with one flag bit (the DO bit) - but how about the rest. E.g, is this compatible with the CD bit and what happens when the server receives such a combination? You get a start on it in section 5 - but see my following comment. (Hmm.. thinking about this - why would you set this option in any query where the CD bit ISN'T set?) Section 4 - You're missing a discussion about what happens with stacking intermediate resolvers. Can an intermediate validating resolver querying another intermediate validating resolver set this option? (e.g. one server pointed at another through stub or forward style directives). Does it need to do something different? Section 5 - its unclear that a caching server can guarantee that it can answer an AU query out of cache - for example, the AU query that comes in from a client lists algorithms in a different priority order than the caching server was listing them upstream. Does the AU client return the data it has (its priority 1 data RSA/SHA256) or does it requery for the priority 1 data from the client (e.g. RSA/SHA1) even though the client is willing to accept RSA/SHA256 as priority 2? In general, I'm concerned about the interactions with the already somewhat fragile DNSSEC data model. Its unclear that this adds enough benefit given the need to really scrub through all the large numbers of permutations this will add to the logic tables. Mike At 09:22 AM 6/20/2008, Scott Rose wrote: >FYI: > >A new individual submission from Steve Crocker and myself. It details a possible crypto algorithm signaling method for a client to list the algorithms it knows about to a server. The goal is twofold: > >1. hopefully reduce response size from zones signed with multiple algorithms > >2. track the implementation of new algorithms in client software to get a better understanding of when complete a rollover from a weaker algorithm to a new stronger algorithm. > >Please read the draft and send comments to us. We would like to ask the WG if this can become a DNSEXT WG document during the Dublin meeting (if agenda permits). > >Thanks, >Scott > > >X-Account-Key: account2 >X-Mozilla-Keys: >Return-Path: >Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) > by fs4.antd.nist.gov (8.13.6/8.13.6) with ESMTP id m5KCxX1m018163 > for ; Fri, 20 Jun 2008 08:59:33 -0400 >Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) > by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id m5KCxN68005896 > for ; Fri, 20 Jun 2008 08:59:24 -0400 >Received: from spamav2.nist.gov (spamav2.nist.gov [129.6.13.239]) > by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5KCxJYh019115 > for ; Fri, 20 Jun 2008 08:59:19 -0400 >Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) > by spamav2.nist.gov (8.14.1/8.14.1) with ESMTP id m5KCxJZA002939 > for ; Fri, 20 Jun 2008 08:59:19 -0400 >Received: by core3.amsl.com (Postfix, from userid 30) > id 6B2263A6A82; Fri, 20 Jun 2008 05:59:17 -0700 (PDT) >From: IETF I-D Submission Tool >To: scott.rose@nist.gov >Cc: steve@shinkuro.com >Content-Type: text/plain; charset="utf-8" >Mime-Version: 1.0 >Message-Id: <20080620125917.6B2263A6A82@core3.amsl.com> >Date: Fri, 20 Jun 2008 05:59:17 -0700 (PDT) >X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7160:2.4.4,1.2.40,4.0.166 definitions=2008-06-20_02:2008-06-19,2008-06-20,2008-06-20 signatures=0 >X-PP-SpamDetails: rule=spampolicy2_notspam policy=spampolicy2 score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0805090000 definitions=main-0806200038 >X-PP-SpamScore: 0 >X-NIST-MailScanner: Found to be clean >X-NIST-MailScanner-From: wwwrun@core3.amsl.com >Subject: New Version Notification for draft-crocker-dnssec-algo-signal-00 >X-NIST-MailScanner-Information: >X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on fs4.antd.nist.gov >X-Virus-Status: Clean >X-UID: 53783 >X-Keywords: > > >A new version of I-D, draft-crocker-dnssec-algo-signal-00.txt has been successfuly submitted by Scott Rose and posted to the IETF repository. > >Filename: draft-crocker-dnssec-algo-signal >Revision: 00 >Title: Signaling Cryptographic Algorithm Understanding in DNSSEC >Creation_date: 2008-06-20 >WG ID: Independent Submission >Number_of_pages: 8 > >Abstract: >The DNS Security Extensions (DNSSEC) was developed to provide origin >authentication and integrity protection for DNS data by using digital >signatures. These digital signatures can be generated using >different algorithms. Each digital signature added to a response >increases the size of the response, which could result in the >response message being truncated. This draft sets out to specify a >way for clients to signal to a server which cryptographic algorithms >they prefer in a DNSSEC response by defining an EDNS option to list a >client's preferred algorithms. > > > >The IETF Secretariat. -- to unsubscribe send a message to namedroppers-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 Jun 23 10:52:56 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD303A6A4B; Mon, 23 Jun 2008 10:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UBE3zszmD3L; Mon, 23 Jun 2008 10:52:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3D53D3A6A2C; Mon, 23 Jun 2008 10:52:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KAq6J-000MKg-7l for namedroppers-data@psg.com; Mon, 23 Jun 2008 17:45:11 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KAq6F-000MKC-9v for namedroppers@ops.ietf.org; Mon, 23 Jun 2008 17:45:09 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 368D73A6A3F; Mon, 23 Jun 2008 10:45:05 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D Action:draft-ietf-dnsext-forgery-resilience-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080623174505.368D73A6A3F@core3.amsl.com> Date: Mon, 23 Jun 2008 10:45:05 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --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 : Measures for making DNS more resilient against forged answers Author(s) : B. Hubert, R. van Mook Filename : draft-ietf-dnsext-forgery-resilience-04.txt Pages : 23 Date : 2008-06-23 The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation. By describing certain behaviour that has previously not been standardised, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dnsext-forgery-resilience-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-23103838.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 23 11:05:07 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833AF3A69BE; Mon, 23 Jun 2008 11:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.921 X-Spam-Level: X-Spam-Status: No, score=0.921 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW7vQB1ZiDrt; Mon, 23 Jun 2008 11:05:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2FC613A6407; Mon, 23 Jun 2008 11:05:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KAqKO-000NrG-EM for namedroppers-data@psg.com; Mon, 23 Jun 2008 17:59:44 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KAqK9-000NoH-In for namedroppers@ops.ietf.org; Mon, 23 Jun 2008 17:59:33 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KAqK6-0001Xt-Hl for namedroppers@ops.ietf.org; Mon, 23 Jun 2008 19:59:26 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id A92343FE7; Mon, 23 Jun 2008 19:59:39 +0200 (CEST) Date: Mon, 23 Jun 2008 19:59:38 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: new draft of Forgery Resilience posted - summary of changes Message-ID: <20080623175938.GA9771@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hi everybody, Happy 25th birthday of DNS! I penned a huge message describing my thoughts on this anniversary, but decided instead to focus on the draft. I've just posted -04 of the Forgery Resilience draft. It has just appeared on http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-04 Many wg-members have submitted heaps of feedback, most of which I was able to work into the draft; some of which was contrary to earlier and equally weighty feedback, so I declared stalemate on that. Most of the changes came from this message http://marc.info/?l=namedroppers&m=121190105420696&w=2 by Peter Koch. Other suggestions have come from Andrew Sullivan. Exact changes can be viewed on: http://is.gd/E2B A lot of wording has been improved - for example, 'resolver' is now defined as equal to a full service resolver as mentioned in RFC 1123. Questions and answers have been replaced by queries and responses. The 'caching resolver' is gone. Some invalid responses have instead become packets, some domains have become domain names, some domains have become zones - all bringing this document in line with accepted DNS parlance. Many chapters have received more descriptive names ('Countermeasures' -> 'Recommended countermeasures'), the security section now explicitly states what this draft recommends. RFC 2181 has been added as a reference, as has draft-ietf-dnsop-reflectors-are-evil. Finally, TCP fallback when a spoofing attempt is detected has been added as an allowable strategy. Open questions are: 1) MUST/SHOULD/MAY in many places 2) It has been pointed out that this is not an operational document, and hence no operational recommendations are made. Instead, recommendations are made for implementors. However, it has also been pointed out that operational recommendations should be made. It is unclear however where these operational guidelines should live. Perhaps the relevant working group can send text. The chairs agree that strictly speaking this is outside the scope of this document, but if a draft paragraph is posted it will be reviewed for suitability. Please let me know your thoughts on this version! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source 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 Jun 23 13:43:52 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554DA3A69ED; Mon, 23 Jun 2008 13:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.559 X-Spam-Level: X-Spam-Status: No, score=0.559 tagged_above=-999 required=5 tests=[AWL=0.804, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5okjcOP2F1V; Mon, 23 Jun 2008 13:43:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AC823A69F9; Mon, 23 Jun 2008 13:43:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KAsmJ-000G0i-09 for namedroppers-data@psg.com; Mon, 23 Jun 2008 20:36:43 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KAsly-000Fxy-0w for namedroppers@ops.ietf.org; Mon, 23 Jun 2008 20:36:32 +0000 Received: from Puki.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5NKaGv7086234 for ; Mon, 23 Jun 2008 16:36:16 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200806232036.m5NKaGv7086234@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Jun 2008 16:35:23 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: new draft of Forgery Resilience posted - summary of changes In-Reply-To: <20080623175938.GA9771@outpost.ds9a.nl> References: <20080623175938.GA9771@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Thanks Bert, Unless someone raises issues with this version I plan on starting WGLC later this week. As for the operational considerations, IMHO that is outside the scope of the document, but in the words of my predecessor "Send text" apply. Olafur At 13:59 23/06/2008, bert hubert wrote: >Hi everybody, > >Happy 25th birthday of DNS! I penned a huge message describing my thoughts >on this anniversary, but decided instead to focus on the draft. > >I've just posted -04 of the Forgery Resilience draft. It has just appeared >on http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-04 > >Many wg-members have submitted heaps of feedback, most of which I was able >to work into the draft; some of which was contrary to earlier and equally >weighty feedback, so I declared stalemate on that. > >Most of the changes came from this message >http://marc.info/?l=namedroppers&m=121190105420696&w=2 by Peter Koch. Other >suggestions have come from Andrew Sullivan. > >Exact changes can be viewed on: http://is.gd/E2B > >A lot of wording has been improved - for example, 'resolver' is now defined >as equal to a full service resolver as mentioned in RFC 1123. Questions and >answers have been replaced by queries and responses. The 'caching resolver' >is gone. > >Some invalid responses have instead become packets, some domains have become >domain names, some domains have become zones - all bringing this document in >line with accepted DNS parlance. > >Many chapters have received more descriptive names ('Countermeasures' -> >'Recommended countermeasures'), the security section now explicitly states >what this draft recommends. > >RFC 2181 has been added as a reference, as has >draft-ietf-dnsop-reflectors-are-evil. > >Finally, TCP fallback when a spoofing attempt is detected has been added as >an allowable strategy. > >Open questions are: > 1) MUST/SHOULD/MAY in many places > > 2) It has been pointed out that this is not an operational document, >and hence no operational recommendations are made. Instead, recommendations >are made for implementors. However, it has also been pointed out that >operational recommendations should be made. It is unclear however where >these operational guidelines should live. Perhaps the relevant working group >can send text. The chairs agree that strictly speaking this is outside the >scope of this document, but if a draft paragraph is posted it will be >reviewed for suitability. > >Please let me know your thoughts on this version! > >-- >http://www.PowerDNS.com Open source, database driven DNS Software >http://netherlabs.nl Open and Closed source 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: -- to unsubscribe send a message to namedroppers-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 Jun 25 10:17:42 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E81C3A683B; Wed, 25 Jun 2008 10:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_63=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fxj5ne0jw7O; Wed, 25 Jun 2008 10:17:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A9D153A6A07; Wed, 25 Jun 2008 10:17:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBYUp-000P0U-7y for namedroppers-data@psg.com; Wed, 25 Jun 2008 17:09:27 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBYUh-000OzJ-4t for namedroppers@ops.ietf.org; Wed, 25 Jun 2008 17:09:22 +0000 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5PH8vkS019972; Wed, 25 Jun 2008 13:08:57 -0400 Received: from 619893L ([129.6.220.160]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m5PH8ll6007177; Wed, 25 Jun 2008 13:08:50 -0400 From: "Scott Rose" To: "Michael StJohns" , "IETF DNSEXT WG" Subject: RE: [Fwd: New Version Notification for draft-crocker-dnssec-algo-signal-00] Date: Wed, 25 Jun 2008 13:08:48 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200806231637.m5NGbIcR029078@spamav2.nist.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Specific comments: > > You specify a priority order in section 2 for algorithms - but > in section 4 the phrasing is "most preferred" without limiting > the number of "most preferred". I assume you want "the single > highest priority algorithm present" or do you want to permit the > two or three highest priority ones? Maybe the option should > indicate the number requested? > Yes, but it also depends on local policy (on the server). I would expect that only one set of RRSIGs in a response. > Section 3 2nd para - "or has a trust anchor for" - should > probably be "and has a trust anchor for" > Will fix. > Section 3 - you dealt with the combination of this option with > one flag bit (the DO bit) - but how about the rest. E.g, is this > compatible with the CD bit and what happens when the server > receives such a combination? You get a start on it in section 5 > - but see my following comment. (Hmm.. thinking about this - why > would you set this option in any query where the CD bit ISN'T set?) > You probably shouldn't. The text probably isn't clear enough on that. Only a validating resolver should be setting the AU option. > Section 4 - You're missing a discussion about what happens with > stacking intermediate resolvers. Can an intermediate validating > resolver querying another intermediate validating resolver set > this option? (e.g. one server pointed at another through stub > or forward style directives). Does it need to do something different? > Sorry - must not have fleshed it out enough. I know I probably need to add more descriptive text. Maybe another section for middleboxes. I would say "yes" if it is a validing resolver (and sets the CD bit). > Section 5 - its unclear that a caching server can guarantee that > it can answer an AU query out of cache - for example, the AU > query that comes in from a client lists algorithms in a different > priority order than the caching server was listing them upstream. > Does the AU client return the data it has (its priority 1 data > RSA/SHA256) or does it requery for the priority 1 data from the > client (e.g. RSA/SHA1) even though the client is willing to > accept RSA/SHA256 as priority 2? > I feel a cache should answer with whatever is in the cache and not re-query. Also, a caching recursive server should not use the AU option in order to insure all RRSIGs are obtained and stored in the cache. > In general, I'm concerned about the interactions with the already > somewhat fragile DNSSEC data model. Its unclear that this adds > enough benefit given the need to really scrub through all the > large numbers of permutations this will add to the logic tables. > We wrote this up to start the discussion on algorithm rollover, multi-algorithms and larger response sizes in DNSSEC. I don't expect the logic table to grow too large because there will only most likely be 2-3 algorithms in use (in general) at any time: the "old" one, the "new" one folks are migrating to, and an optional "new/private" one. Steve and I can hopefully get out a new version during IETF in July. I will work in these comments. Scott > Mike > > > > > > > > > At 09:22 AM 6/20/2008, Scott Rose wrote: > >FYI: > > > >A new individual submission from Steve Crocker and myself. It > details a possible crypto algorithm signaling method for a client > to list the algorithms it knows about to a server. The goal is twofold: > > > >1. hopefully reduce response size from zones signed with > multiple algorithms > > > >2. track the implementation of new algorithms in client software > to get a better understanding of when complete a rollover from a > weaker algorithm to a new stronger algorithm. > > > >Please read the draft and send comments to us. We would like to > ask the WG if this can become a DNSEXT WG document during the > Dublin meeting (if agenda permits). > > > >Thanks, > >Scott > > > > > >X-Account-Key: account2 > >X-Mozilla-Keys: > > >Return-Path: > >Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) > > by fs4.antd.nist.gov (8.13.6/8.13.6) with ESMTP id m5KCxX1m018163 > > for ; Fri, 20 Jun 2008 08:59:33 -0400 > >Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) > > by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id m5KCxN68005896 > > for ; Fri, 20 Jun 2008 08:59:24 -0400 > >Received: from spamav2.nist.gov (spamav2.nist.gov [129.6.13.239]) > > by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5KCxJYh019115 > > for ; Fri, 20 Jun 2008 08:59:19 -0400 > >Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) > > by spamav2.nist.gov (8.14.1/8.14.1) with ESMTP id m5KCxJZA002939 > > for ; Fri, 20 Jun 2008 08:59:19 -0400 > >Received: by core3.amsl.com (Postfix, from userid 30) > > id 6B2263A6A82; Fri, 20 Jun 2008 05:59:17 -0700 (PDT) > >From: IETF I-D Submission Tool > >To: scott.rose@nist.gov > >Cc: steve@shinkuro.com > >Content-Type: text/plain; charset="utf-8" > >Mime-Version: 1.0 > >Message-Id: <20080620125917.6B2263A6A82@core3.amsl.com> > >Date: Fri, 20 Jun 2008 05:59:17 -0700 (PDT) > >X-Proofpoint-Virus-Version: vendor=fsecure > engine=1.12.7160:2.4.4,1.2.40,4.0.166 > definitions=2008-06-20_02:2008-06-19,2008-06-20,2008-06-20 signatures=0 > >X-PP-SpamDetails: rule=spampolicy2_notspam policy=spampolicy2 > score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 > adultscore=0 classifier=spam adjust=0 reason=mlx > engine=5.0.0-0805090000 definitions=main-0806200038 > >X-PP-SpamScore: 0 > >X-NIST-MailScanner: Found to be clean > >X-NIST-MailScanner-From: wwwrun@core3.amsl.com > >Subject: New Version Notification for draft-crocker-dnssec-algo-signal-00 > >X-NIST-MailScanner-Information: > >X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version > 0.93.1 on fs4.antd.nist.gov > >X-Virus-Status: Clean > >X-UID: 53783 > >X-Keywords: > > > > > > >A new version of I-D, draft-crocker-dnssec-algo-signal-00.txt > has been successfuly submitted by Scott Rose and posted to the > IETF repository. > > > >Filename: draft-crocker-dnssec-algo-signal > >Revision: 00 > >Title: Signaling Cryptographic Algorithm Understanding in DNSSEC > >Creation_date: 2008-06-20 > >WG ID: Independent Submission > >Number_of_pages: 8 > > > >Abstract: > >The DNS Security Extensions (DNSSEC) was developed to provide origin > >authentication and integrity protection for DNS data by using digital > >signatures. These digital signatures can be generated using > >different algorithms. Each digital signature added to a response > >increases the size of the response, which could result in the > >response message being truncated. This draft sets out to specify a > >way for clients to signal to a server which cryptographic algorithms > >they prefer in a DNSSEC response by defining an EDNS option to list a > >client's preferred algorithms. > > > > > > > > >The IETF Secretariat. > > -- to unsubscribe send a message to namedroppers-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 Jun 25 10:19:17 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F543A6A87; Wed, 25 Jun 2008 10:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEZWkW2Dghfw; Wed, 25 Jun 2008 10:19:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B688C3A6A81; Wed, 25 Jun 2008 10:19:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBYTc-000OrD-9n for namedroppers-data@psg.com; Wed, 25 Jun 2008 17:08:12 +0000 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBYTU-000OqL-7P for namedroppers@ops.ietf.org; Wed, 25 Jun 2008 17:08:06 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m5PH7wne019405; Wed, 25 Jun 2008 12:07:58 -0500 Received: from garak.ads.sparta.com (garak.sparta.com [157.185.63.81]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m5PH7uxi025342; Wed, 25 Jun 2008 12:07:56 -0500 Received: from mailbin2.ads.sparta.com ([157.185.85.6]) by garak.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 12:07:55 -0500 Received: from [157.185.81.214] ([157.185.81.214]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 13:15:44 -0400 In-Reply-To: <20080623175938.GA9771@outpost.ds9a.nl> References: <20080623175938.GA9771@outpost.ds9a.nl> Mime-Version: 1.0 (Apple Message framework v753.1) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <305D87A7-0D8B-4248-805E-52DEED0A0F37@sparta.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: Re: new draft of Forgery Resilience posted - summary of changes Date: Wed, 25 Jun 2008 13:07:50 -0400 To: bert hubert X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 25 Jun 2008 17:15:44.0421 (UTC) FILETIME=[1A20DD50:01C8D6E7] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Wed, 25 Jun 2008 12:07:59 -0500 (CDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I support this draft, but I do have a couple of suggestions: On page 4, it is mentioned that: It should be noted that even when all measures suggested below are implemented, protocol users are not protected against third parties with the ability to intercept, change or inject packets sent to the resolver. I'm wondering what "inject packets sent to the resolver" means in this context. If this refers to the close-in attack scenario where an attacker is able to view the outbound requests as they are sent out, craft a response packet, and send it to the resolver before the real answer arrived, I'd like this to be stated more clearly. Specifically, we should note that spoofing of responses is trivial when the attacker is able to sniff/inspect the packet sent out by the resolver even when all the guidelines sugested in this document are followed. This must also be mentioned in the security considerations section. Secondly, some of the text in the document creates the impression that DNSSEC is still in the development stage. I'd suggest the following changes: i) Replace following text on page 3, para 7: ... Although the DNS community is working hard on finalising and implementing a cryptographically enhanced DNS protocol, steps should be taken to make sure that the existing use of DNS is as secure as possible within the bounds of the relevant standards. with: While DNSSEC ( see [RFC4033] and beyond) mitigates most of these threats, steps should be taken to ensure that the existing use of DNS is as secure as possible within the bounds of the relevant DNS standards, even without the use of DNSSEC. ii) Replace following text on page 4, para 1: ... protocol specifications. The following also specifies new requirements to make sure the Domain Name System can be relied upon until a more secure protocol has been standardised and deployed. with: protocol specifications. The following also specifies new requirements to make sure the Domain Name System can be relied upon until DNSSEC is more widely deployed. iii) And, remove "under development" in the last para in Page 4: For protocol extensions under development that offer protection against these scenarios, see [RFC4033] and beyond. Suresh -- to unsubscribe send a message to namedroppers-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 Jun 25 11:28:21 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3993A6A26; Wed, 25 Jun 2008 11:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2Hl67bbEATU; Wed, 25 Jun 2008 11:28:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB7303A67AB; Wed, 25 Jun 2008 11:28:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBZcD-00063z-Jq for namedroppers-data@psg.com; Wed, 25 Jun 2008 18:21:09 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBZc9-00063G-ST for namedroppers@ops.ietf.org; Wed, 25 Jun 2008 18:21:07 +0000 Received: from [10.20.30.162] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5PIKrfj086210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2008 11:20:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 25 Jun 2008 11:20:50 -0700 To: "Scott Rose" , "Michael StJohns" , "IETF DNSEXT WG" From: Paul Hoffman Subject: RE: [Fwd: New Version Notification for draft-crocker-dnssec-algo-signal-00] Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 1:08 PM -0400 6/25/08, Scott Rose wrote: > > In general, I'm concerned about the interactions with the already >> somewhat fragile DNSSEC data model. Its unclear that this adds >> enough benefit given the need to really scrub through all the >> large numbers of permutations this will add to the logic tables. >> > >We wrote this up to start the discussion on algorithm rollover, >multi-algorithms and larger response sizes in DNSSEC. I don't expect the >logic table to grow too large because there will only most likely be 2-3 >algorithms in use (in general) at any time: the "old" one, the "new" one >folks are migrating to, and an optional "new/private" one. I agree with Mike's concern about the small benefit for the possibly large configuration risk. I get more concerned when I see predictions that clearly underestimate the number of algorithms expected in use. There is already strong interest in two (RSA-SHA1 because it's there now, RSA-SHA2 because it's the right way to go), and will likely be interest in at least two others from large customers (DSA and ECDSA). That's four in the immediate future, not even counting what happens if there is a partially effective attack on any of those. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 25 14:03:49 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C348B28C11A; Wed, 25 Jun 2008 14:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OI-lqD5XCgIp; Wed, 25 Jun 2008 14:03:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 783AF3A6A6B; Wed, 25 Jun 2008 14:03:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBbzu-000NJa-QI for namedroppers-data@psg.com; Wed, 25 Jun 2008 20:53:46 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBbzc-000NGW-Ga for namedroppers@ops.ietf.org; Wed, 25 Jun 2008 20:53:38 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KBbzV-0004lw-21 for namedroppers@ops.ietf.org; Wed, 25 Jun 2008 22:53:21 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 1B9BF40E1; Wed, 25 Jun 2008 22:53:34 +0200 (CEST) Date: Wed, 25 Jun 2008 22:53:33 +0200 From: bert hubert To: Suresh Krishnaswamy Cc: namedroppers@ops.ietf.org Subject: Re: new draft of Forgery Resilience posted - summary of changes Message-ID: <20080625205333.GD6088@outpost.ds9a.nl> References: <20080623175938.GA9771@outpost.ds9a.nl> <305D87A7-0D8B-4248-805E-52DEED0A0F37@sparta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <305D87A7-0D8B-4248-805E-52DEED0A0F37@sparta.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 25, 2008 at 01:07:50PM -0400, Suresh Krishnaswamy wrote: > I support this draft, but I do have a couple of suggestions: Thanks! Although I am grateful for your suggestions, I will only be making very minimal changes to the draft. The document has been going to and fro for the past 2+ years now, so I'm only removing blatant errors at this stage. Anything else must be absolutely uncontroversial. > I'm wondering what "inject packets sent to the resolver" means in this > context. If this refers to the close-in attack scenario where an attacker > is able to view the outbound requests as they are sent out, craft a > response packet, and send it to the resolver before the real answer Yes. I've changed the above to: "It should be noted that even when all measures suggested below are implemented, protocol users are not protected against third parties with the ability to observe, modify or inject packets in the traffic of a resolver." The English sounds worse though. I've also strenghtened the security section wording on the benefits of real cryptographical security: "Recommendations found above should be considered complementary to possible cryptographical enhancements of the domain name system, which protect against a larger class of attacks." > Secondly, some of the text in the document creates the impression that > DNSSEC is still in the development stage. I'd suggest the following [..] Off-list, arguments have already been made that it is not uncontroversial if DNSSEC is finished or in a development state or not. So I respectfully will not fiddle with the draft because it *might* reflect an impression that might be true - please see my reasons above. I fully support the case for better DNS security through cryptographical means though! Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source 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 Wed Jun 25 19:54:36 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92173A68CC; Wed, 25 Jun 2008 19:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jam5NndfZr4a; Wed, 25 Jun 2008 19:54:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68C473A68B7; Wed, 25 Jun 2008 19:54:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBhPJ-0005Wv-BC for namedroppers-data@psg.com; Thu, 26 Jun 2008 02:40:21 +0000 Received: from [76.96.30.96] (helo=QMTA09.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBhPF-0005WN-TZ for namedroppers@ops.ietf.org; Thu, 26 Jun 2008 02:40:19 +0000 Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id iSY91Z0040b6N64A900t00; Thu, 26 Jun 2008 02:40:17 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id iSgB1Z00K2P9w058PSgCQf; Thu, 26 Jun 2008 02:40:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=xKe8Z-5y34EA:10 a=uUnk1H2WmvYA:10 a=mmd7f0GsJ4tFP52D5csA:9 a=gtXz7ZkROSejAmoeC6hGLnsef7QA:4 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 25 Jun 2008 22:40:13 -0400 To: "Scott Rose" , "IETF DNSEXT WG" From: Michael StJohns Subject: RE: [Fwd: New Version Notification for draft-crocker-dnssec-algo-signal-00] In-Reply-To: References: <200806231637.m5NGbIcR029078@spamav2.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 01:08 PM 6/25/2008, Scott Rose wrote: >> Section 5 - its unclear that a caching server can guarantee that >> it can answer an AU query out of cache - for example, the AU >> query that comes in from a client lists algorithms in a different >> priority order than the caching server was listing them upstream. >> Does the AU client return the data it has (its priority 1 data >> RSA/SHA256) or does it requery for the priority 1 data from the >> client (e.g. RSA/SHA1) even though the client is willing to >> accept RSA/SHA256 as priority 2? >> >I feel a cache should answer with whatever is in the cache and not re-query. >Also, a caching recursive server should not use the AU option in order to >insure all RRSIGs are obtained and stored in the cache. So you're saying that the only entity that should use the AU option is a validating end system? If that's the case - I'd suggest stating that up front as pretty much the first thing said. Mike -- to unsubscribe send a message to namedroppers-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 Jun 25 19:54:50 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA11D3A68DE; Wed, 25 Jun 2008 19:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqIE6QUs6hF7; Wed, 25 Jun 2008 19:54:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E60EE3A68CC; Wed, 25 Jun 2008 19:54:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBhSa-0005jO-Cs for namedroppers-data@psg.com; Thu, 26 Jun 2008 02:43:44 +0000 Received: from [76.96.30.32] (helo=QMTA03.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBhSP-0005iR-51 for namedroppers@ops.ietf.org; Thu, 26 Jun 2008 02:43:38 +0000 Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id iSAS1Z01Y0cQ2SLA304v00; Thu, 26 Jun 2008 02:43:31 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id iSjU1Z0042P9w058WSjU9L; Thu, 26 Jun 2008 02:43:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=xKe8Z-5y34EA:10 a=uUnk1H2WmvYA:10 a=4JKcHtx2wCrGBXxBnSoA:9 a=t4JoH3Q3BSisqKGen8EGMQKjtqQA:4 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 25 Jun 2008 22:43:29 -0400 To: Paul Hoffman ,"Scott Rose" , "IETF DNSEXT WG" From: Michael StJohns Subject: RE: [Fwd: New Version Notification for draft-crocker-dnssec-algo-signal-00] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 02:20 PM 6/25/2008, Paul Hoffman wrote: > There is already strong interest in two (RSA-SHA1 because it's there now, RSA-SHA2 because it's the right way to go), and will likely be interest in at least two others from large customers (DSA and ECDSA). That's four in the immediate future, not even counting what happens if there is a partially effective attack on any of those. It's actually worse than that. For ECDSA, the general recommendation is to use the matching strength of hash so ECDSA on a 224bit curve uses the SHA224 hash, on the 256 bit curve, SHA256, etc. Mike -- to unsubscribe send a message to namedroppers-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 Jun 26 06:04:11 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7343A67B4; Thu, 26 Jun 2008 06:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-B8853gADoS; Thu, 26 Jun 2008 06:04:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C00193A6916; Thu, 26 Jun 2008 06:04:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBqxx-000Dhm-Ie for namedroppers-data@psg.com; Thu, 26 Jun 2008 12:52:45 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBqxX-000DfK-BN for namedroppers@ops.ietf.org; Thu, 26 Jun 2008 12:52:35 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5QCq6cH020200 for ; Thu, 26 Jun 2008 08:52:06 -0400 Message-ID: <486390F6.6030708@nist.gov> Date: Thu, 26 Jun 2008 08:52:06 -0400 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: IETF DNSEXT WG Subject: Re: [Fwd: New Version Notification for draft-crocker-dnssec-algo-signal-00] References: <200806231637.m5NGbIcR029078@spamav2.nist.gov> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Michael StJohns wrote: > At 01:08 PM 6/25/2008, Scott Rose wrote: >>> Section 5 - its unclear that a caching server can guarantee that >>> it can answer an AU query out of cache - for example, the AU >>> query that comes in from a client lists algorithms in a different >>> priority order than the caching server was listing them upstream. >>> Does the AU client return the data it has (its priority 1 data >>> RSA/SHA256) or does it requery for the priority 1 data from the >>> client (e.g. RSA/SHA1) even though the client is willing to >>> accept RSA/SHA256 as priority 2? >>> >> I feel a cache should answer with whatever is in the cache and not re-query. >> Also, a caching recursive server should not use the AU option in order to >> insure all RRSIGs are obtained and stored in the cache. > > So you're saying that the only entity that should use the AU option is a validating end system? If that's the case - I'd suggest stating that up front as pretty much the first thing said. > That is the intension, sorry if it didn't seem clear. I'll make it more direct in the revision. It does not seem like a good idea to have a non-validating stub dictate which algorithms its upstream validating cache must request if it does not know what algorithms it supports. When I mentioned that I believed there would be "only 2-3 algorithms in use", I meant in a zone. While there could be multiple algorithms used in the DNS, I can't see too many zones having more than 2-3 algorithms in use at a given time. Right now, there are several defined, but only 2 that are commonly used (and both are RSA/SHA-1). Scott > Mike > > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- ---------------------------------------- Scott Rose Computer Scientist NIST ph: +1 301-975-8439 scott.rose@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Jun 26 07:52:05 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30F43A6A84; Thu, 26 Jun 2008 07:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.029 X-Spam-Level: X-Spam-Status: No, score=-0.029 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf5dJ7JoXfB5; Thu, 26 Jun 2008 07:52:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4325528C132; Thu, 26 Jun 2008 07:52:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBskI-000Pvx-38 for namedroppers-data@psg.com; Thu, 26 Jun 2008 14:46:46 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBsk8-000PuS-S8 for namedroppers@ops.ietf.org; Thu, 26 Jun 2008 14:46:43 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KBsk6-0006xe-0u for namedroppers@ops.ietf.org; Thu, 26 Jun 2008 16:46:34 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 833C74B489; Thu, 26 Jun 2008 16:46:45 +0200 (CEST) Date: Thu, 26 Jun 2008 16:46:45 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: Re: new draft of Forgery Resilience posted - summary of changes Message-ID: <20080626144644.GD19608@outpost.ds9a.nl> References: <20080623175938.GA9771@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080623175938.GA9771@outpost.ds9a.nl> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hi everybody, I've just posted version -05 of the Forgery Resilience draft. It has appeared on http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-05.txt Compared to -04: * An IANA section has been added (asking IANA to do nothing) * A reference to RFC 2401 has been replaced by a reference to 4301 (its successor) * Typos (scnearios, reponses, acknowledgements, ountermeasures) were fixed * A tighter description of attacks by third parties that can see your packets was added * Added wording that cryptograpical security mechanisms protect against more attacks Based on feedback so far, and the final small tweaks found in -05, I kindly request that a WG last call be initiated. Kind regards, bert hubert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source 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 Thu Jun 26 07:52:39 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED5E3A6A84; Thu, 26 Jun 2008 07:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN0pqRCKfQNw; Thu, 26 Jun 2008 07:52:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F5F03A6904; Thu, 26 Jun 2008 07:52:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBsj3-000Pmw-Sr for namedroppers-data@psg.com; Thu, 26 Jun 2008 14:45:29 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBsim-000PkL-E6 for namedroppers@ops.ietf.org; Thu, 26 Jun 2008 14:45:27 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 0875F28C11B; Thu, 26 Jun 2008 07:45:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D Action:draft-ietf-dnsext-forgery-resilience-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080626144505.0875F28C11B@core3.amsl.com> Date: Thu, 26 Jun 2008 07:45:04 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --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 : Measures for making DNS more resilient against forged answers Author(s) : B. Hubert, R. van Mook Filename : draft-ietf-dnsext-forgery-resilience-05.txt Pages : 24 Date : 2008-06-26 The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation. By describing certain behaviour that has previously not been standardised, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dnsext-forgery-resilience-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-26073752.I-D@ietf.org> --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 Thu Jun 26 09:36:23 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD543A695F; Thu, 26 Jun 2008 09:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTyFkYYL62xI; Thu, 26 Jun 2008 09:36:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECC773A6885; Thu, 26 Jun 2008 09:36:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBuLl-000Bgt-2C for namedroppers-data@psg.com; Thu, 26 Jun 2008 16:29:33 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBuLd-000BgE-5X for namedroppers@ops.ietf.org; Thu, 26 Jun 2008 16:29:27 +0000 Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5QGTMpk057507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jun 2008 09:29:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080626144505.0875F28C11B@core3.amsl.com> References: <20080626144505.0875F28C11B@core3.amsl.com> Date: Thu, 26 Jun 2008 09:29:20 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Requirements levels in draft-ietf-dnsext-forgery-resilience-05.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The title of section 9 disagrees with the fact that the section contains MUST requirements. >9. Recommended Countermeasures > > Given the above, a resolver implementation MUST match responses to > the following attributes of the query: > >. . . > > Resolver implementations MUST have the ability to: Either the title of the section needs to be changed to "Required Countermeasures", or the MUSTs should be downgraded to SHOULDs with explanations of when the SHOULDs do not need to be followed. Changing the title seems like the better option. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 26 10:28:29 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FE703A6B02; Thu, 26 Jun 2008 10:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF+iZyjTdi85; Thu, 26 Jun 2008 10:28:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2647B3A6A4F; Thu, 26 Jun 2008 10:28:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBv8q-000IRF-N3 for namedroppers-data@psg.com; Thu, 26 Jun 2008 17:20:16 +0000 Received: from [76.96.62.17] (helo=QMTA10.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBv8m-000IQC-Fp for namedroppers@ops.ietf.org; Thu, 26 Jun 2008 17:20:14 +0000 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA10.westchester.pa.mail.comcast.net with comcast id ieZa1Z0051GhbT85A0Gb00; Thu, 26 Jun 2008 17:20:09 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA07.westchester.pa.mail.comcast.net with comcast id ihL71Z00K2P9w053ThL8An; Thu, 26 Jun 2008 17:20:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=xKe8Z-5y34EA:10 a=uUnk1H2WmvYA:10 a=cciMR--oNT_0gNyUXmkA:9 a=5ofCgshBJUEvY7OryJbJu8LeQbAA:4 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Jun 2008 13:14:59 -0400 To: Scott Rose ,IETF DNSEXT WG From: Michael StJohns Subject: Re: [Fwd: New Version Notification for draft-crocker-dnssec-algo-signal-00] In-Reply-To: <486390F6.6030708@nist.gov> References: <200806231637.m5NGbIcR029078@spamav2.nist.gov> <486390F6.6030708@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 08:52 AM 6/26/2008, Scott Rose wrote: >Michael StJohns wrote: >>At 01:08 PM 6/25/2008, Scott Rose wrote: >>>>Section 5 - its unclear that a caching server can guarantee that >>>>it can answer an AU query out of cache - for example, the AU >>>>query that comes in from a client lists algorithms in a different >>>>priority order than the caching server was listing them upstream. >>>> Does the AU client return the data it has (its priority 1 data >>>>RSA/SHA256) or does it requery for the priority 1 data from the >>>>client (e.g. RSA/SHA1) even though the client is willing to >>>>accept RSA/SHA256 as priority 2? >>>I feel a cache should answer with whatever is in the cache and not re-query. >>>Also, a caching recursive server should not use the AU option in order to >>>insure all RRSIGs are obtained and stored in the cache. >>So you're saying that the only entity that should use the AU option is a validating end system? If that's the case - I'd suggest stating that up front as pretty much the first thing said. > >That is the intension, sorry if it didn't seem clear. I'll make it more direct in the revision. It does not seem like a good idea to have a non-validating stub dictate which algorithms its upstream validating cache must request if it does not know what algorithms it supports. I re-read the document and you used "client" and "validating resolver". Both unfortunately ambiguous even in context. An [end-system | intermediate] [validating [| non-validating]] [caching [| non-caching]] [recursive | (non-recursive | stub) ] resolver. *sigh* I went back and tried to find an unambiguous term that is common across most documents and the closest I came was "end-system resolver". Anyone else have a term of art that's better and that's unambiguous regardless of context? "Client resolver" isn't as it could include an intermediate resolver during a discussion of protocol interactions.. "Stub resolver" is unambiguous, but expressly excludes an end-system resolver that can do recursion. -- to unsubscribe send a message to namedroppers-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 Jun 26 13:46:15 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CFEA3A69FC; Thu, 26 Jun 2008 13:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.182 X-Spam-Level: X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PT-xi1RnLUt7; Thu, 26 Jun 2008 13:46:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 439863A6A19; Thu, 26 Jun 2008 13:46:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBy9w-000H4c-Td for namedroppers-data@psg.com; Thu, 26 Jun 2008 20:33:36 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBy9j-000H2f-Cn for namedroppers@ops.ietf.org; Thu, 26 Jun 2008 20:33:34 +0000 Received: from Puki.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5QKXJxA036876 for ; Thu, 26 Jun 2008 16:33:19 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200806262033.m5QKXJxA036876@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Jun 2008 16:33:14 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This note starts a Working Group Last Call for this Standards Track document ending on noon July 12'th 2006 (Dublin time). URL for the document and its history: http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/ This document updates and clarifies RFC1034 in how a resolver should generate random query ID, how to use multiple ports and possibly addresses to make it harder to guess the details of a query by a particular resolver. Please read the document carefully, in particular section 9. At this point the chairs would like to know if the current RFC2119 wording in that section is acceptable or how it can be improved. The document process rules in this group, require that at least 5 members of the working to state that they have read the document and there is consensus of support to publish as an Standards Track RFC. Olafur & Andrew -- to unsubscribe send a message to namedroppers-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 Jun 26 14:24:23 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5A2C3A6A2B; Thu, 26 Jun 2008 14:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8anC3+o-+Gc; Thu, 26 Jun 2008 14:24:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7EE093A6A28; Thu, 26 Jun 2008 14:24:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBys3-000MP5-Lw for namedroppers-data@psg.com; Thu, 26 Jun 2008 21:19:11 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KByrz-000MOC-5f for namedroppers@ops.ietf.org; Thu, 26 Jun 2008 21:19:09 +0000 Received: from Puki.ogud.com (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5QLJ3fG037314; Thu, 26 Jun 2008 17:19:03 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200806262119.m5QLJ3fG037314@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Jun 2008 17:18:57 -0400 To: Paul Hoffman , namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: Requirements levels in draft-ietf-dnsext-forgery-resilience-05.txt In-Reply-To: References: <20080626144505.0875F28C11B@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul, I'm treating your comment as a WGLC comment, At 12:29 26/06/2008, Paul Hoffman wrote: >The title of section 9 disagrees with the fact that the section >contains MUST requirements. > >>9. Recommended Countermeasures >> >> Given the above, a resolver implementation MUST match responses to >> the following attributes of the query: >> >>. . . >> >> Resolver implementations MUST have the ability to: > >Either the title of the section needs to be changed to "Required >Countermeasures", or the MUSTs should be downgraded to SHOULDs with >explanations of when the SHOULDs do not need to be followed. >Changing the title seems like the better option. Thanks for this comment you are right that "Required Countermeasures" is a better title. I will put this in the queue for things to change after the WGLC. 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 Jun 26 14:57:16 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F253A6908; Thu, 26 Jun 2008 14:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.95 X-Spam-Level: X-Spam-Status: No, score=-4.95 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JDG7u0q5BDj; Thu, 26 Jun 2008 14:57:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D0363A68AD; Thu, 26 Jun 2008 14:57:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBzLa-000PZL-Sy for namedroppers-data@psg.com; Thu, 26 Jun 2008 21:49:42 +0000 Received: from [207.219.45.62] (helo=mx4.ca.afilias.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBzLX-000PYa-8j for namedroppers@ops.ietf.org; Thu, 26 Jun 2008 21:49:41 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1KBzLW-00008v-Dy; Thu, 26 Jun 2008 17:49:38 -0400 Message-ID: <48640EEF.9000506@ca.afilias.info> Date: Thu, 26 Jun 2008 17:49:35 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_chair?= CC: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" References: <200806262033.m5QKXJxA036876@ogud.com> In-Reply-To: <200806262033.m5QKXJxA036876@ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ólafur Guðmundsson /DNSEXT chair wrote: > > This note starts a Working Group Last Call for this Standards Track > document > ending on noon July 12'th 2006 (Dublin time). > > URL for the document and its history: > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/ > > > This document updates and clarifies RFC1034 in how a resolver should > generate > random query ID, how to use multiple ports and possibly addresses to make > it harder to guess the details of a query by a particular resolver. > > Please read the document carefully, in particular section 9. At this > point > the chairs would like to know if the current RFC2119 wording in that > section is acceptable or how it can be improved. > > The document process rules in this group, require that at least > 5 members of the working to state that they have read the document > and there is consensus of support to publish as an Standards Track RFC. > > Olafur & Andrew I have read the document carefully. I have one, very minor nit, on the recommendations in section 9. Has consideration been given on the matching of "Question name", in a case-SENSITIVE manner? I realize there is other outstanding (in both senses :-)) work on randomizing uc/lc on labels that match '[-a-z0-9]*', and I would hope this instant ID could be constructed to dovetail with that other ID. It may require some tinkering in other bits of the text, to handle the edge cases of authority servers giving answers whose question matches case insensitively but not case-sensitively. Repeating the question (once) should suffice, and a case mismatch caused by the authority server could be detected. Conversely, a spoofed packet would need to match case to succeed, or to succeed in meeting the 'birthday attack' criteria twice while not matching case. Both branches of those conditionals, significantly improve the resulting forgery resilience. Other than that, I am in favo(u)r of the document moving forward. Brian Dickson -- to unsubscribe send a message to namedroppers-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 Jun 26 15:06:13 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B463A697A; Thu, 26 Jun 2008 15:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJXGHAqJVkgw; Thu, 26 Jun 2008 15:06:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 87E343A687A; Thu, 26 Jun 2008 15:06:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBzVl-0000f1-EJ for namedroppers-data@psg.com; Thu, 26 Jun 2008 22:00:13 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBzVh-0000eU-7Z for namedroppers@ops.ietf.org; Thu, 26 Jun 2008 22:00:11 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5QM06Rg086802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jun 2008 15:00:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200806262033.m5QKXJxA036876@ogud.com> References: <200806262033.m5QKXJxA036876@ogud.com> Date: Thu, 26 Jun 2008 14:59:13 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 4:33 PM -0400 6/26/08, Ólafur Gu©£mundsson /DNSEXT chair wrote: >Please read the document carefully, in particular section 9. At this point >the chairs would like to know if the current RFC2119 wording in that >section is acceptable or how it can be improved. It can be improved. >9. Recommended Countermeasures This should be "Required Countermeasures" because of the use of the word "MUST" in the body of the section. > > Given the above, a resolver implementation MUST match responses to > the following attributes of the query: > > o Remote address > > o Local address > > o Query port > > o Query ID > > o Question name (compared case-insensitively) > > o Question class and type > > before applying DNS trustworthiness rules (see [RFC2181], section > 5.4.1). More precisely, the response source IP address MUST match > the query's destination IP address and the response destination IP > address MUST match the query's source IP address. What happened to the other fields (query port, ID, name, and class)? This sentence sounds like that only the addresses must match, which is not what the rest of the section says. I propose dropping this sentence, or making it much longer. > A mismatch should > be considered a format error, and the response invalid. A mismatch MUST be considered a format error and the response MUST be considered invalid. > > Resolver implementations MUST have the ability to: > > o Use an unpredictable source port for outgoing queries from the > range (53, or > 1024) of available ports that is as large as > possible and practicable; > > o Use multiple different source ports simultaneously in case of > multiple outstanding queries; > > o Use an unpredictable query ID for outgoing queries, utilizing the > full range available (0-65535); (Editorial: drop the last semicolon) A conformant implementation "MUST have the ability" to do those things, but doesn't need to make that available to the operator? That seems like undershooting the goal. Proposed change: ----- A resolver MUST use an unpredictable source port for outgoing queries in a port range that is as large as possible and practicable. That range SHOULD be 53 plus 1024 to 65535 inclusive unless other restrictions are put on the range by the operating system or a firewall. If a resolver has multiple outstanding queries, it SHOULD use different source ports for each query unless doing so is restricted by the operating system or a firewall. A resolver MUST use an unpredictable query ID for outgoing queries in the range of 0 to 65535 inclusive. ----- > Please note that source ports could be selected from a larger range > than indicated, but that this range is regarded as safe, with some > lower port numbers reserved for activities which might conflict with > proper DNS operation. > > In case these abilities are enabled, the implementation MUST strive > to have its choices of source port and query ID remain unpredictable, > even if an attacker has knowledge of its (pseudo-)random generator. How would an implementer do that? If this means to say "use a secret value as a seed to the pseudo-random generator", it needs to say so explicitly. > > If a resolver is multihomed or otherwise has the ability to transmit > and receive datagrams using more than one IP source address, then an > IP address can be chosen at random in order to increase an attacker's > difficulty in guessing what address to flood. Worded as a requirement: "...then an IP address SHOULD be chosen at random unless doing so would have a negative operational impact, in order to..." > If a resolver sends out multiple equivalent queries to any > authoritative server, before receiving a response, all MUST have > identical ID, source address and source port. > > Resolvers SHOULD favour authoritative nameservers with which a trust > relation has been established; Why is this a SHOULD instead of a MUST? Under what circumstances would I accept an response from an untrusted server over one from a strusted server? > Stub-resolvers SHOULD be able to use > TSIG ([RFC2845]) or IPSEC ([RFC4301]) when communicating with their > recursive resolver. Add "if those services are available" to the end of the sentence to explain the SHOULD. > In case a cryptographic verification of response validity is > available, resolver implementations MAY waive above rules, and rely > on this guarantee instead. This is completely unclear. Does it mean DNSSEC, IPSEC, or TSIG, all of which give cryptographic verification? Which "above rules" might be waved? > > Proper unpredictability can be achieved by employing a high quality > random generator, as described in [RFC4086]. Most of RFC 4086 is about pseudo-random generators, not true random generators, as the document makes clear. This sentence would be better worded as "[RFC4086] gives guidelines for attaining high quality pseudo-random and random values." > > If a resolver detects that an attempt is being made to spoof it, > perhaps by discovering that many packets fail the criteria as > outlined above, it MAY abandon the UDP query and re-issue it over > TCP. TCP, by the nature of its use of sequence numbers, is far more > resilient against forgery by third parties. The "MAY" here seems weak. It may abandon UDP any time it wants anyway. Also, the word "spoof" in this context is quite unclear. Normally, it is used as an active verb, such as "Mallory tried to spoof the responses". Proposed rewording: ----- If a resolver detects that an attempt is being made to send it spoofed responses, perhaps by discovering that many packets fail the five criteria for matching queries to responses, the resolver SHOULD abandon the UDP query and re-issue it over TCP if using TCP is possible in the system. ----- The second sentence is important, but out of place in recommendations. The use of TCP to reduce spoofing is never mentioned anywhere else in the document. but it should be. A new section, probably 4.7, should be added to discuss using TCP when an attack is detected. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 26 20:16:37 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7D73A6923; Thu, 26 Jun 2008 20:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.194 X-Spam-Level: X-Spam-Status: No, score=-0.194 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtZRAGUfngiT; Thu, 26 Jun 2008 20:16:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3F2103A679F; Thu, 26 Jun 2008 20:16:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KC4JU-0006Yy-Cd for namedroppers-data@psg.com; Fri, 27 Jun 2008 03:07:52 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KC4JQ-0006YR-Rn for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 03:07:50 +0000 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5R37eeg039543 for ; Thu, 26 Jun 2008 23:07:43 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200806270307.m5R37eeg039543@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Jun 2008 23:07:31 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" In-Reply-To: <200806262033.m5QKXJxA036876@ogud.com> References: <200806262033.m5QKXJxA036876@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 17:19 26/06/2008, =D3lafur Gu=F0mundsson /DNSEXT wrote: >This note starts a Working Group Last Call for this Standards Track= document >ending on noon July 12'th 2006 (Dublin time). Correction: "July 12'th 2008 (Dublin time)". 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 Fri Jun 27 03:18:40 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5DA33A6836; Fri, 27 Jun 2008 03:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3rpQ4lyW+wG; Fri, 27 Jun 2008 03:18:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 054F328C51D; Fri, 27 Jun 2008 02:44:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCANO-000BMX-9n for namedroppers-data@psg.com; Fri, 27 Jun 2008 09:36:18 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCANJ-000BLd-H3 for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 09:36:16 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m5R9ZoTC008991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2008 11:35:51 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4864B478.7030702@nlnetlabs.nl> Date: Fri, 27 Jun 2008 11:35:52 +0200 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Olafur Gudmundsson CC: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" References: <200806262033.m5QKXJxA036876@ogud.com> <200806270307.m5R37eeg039543@ogud.com> In-Reply-To: <200806270307.m5R37eeg039543@ogud.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 27 Jun 2008 11:35:51 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dnsext, I reviewed -05 of the forgery resilience draft for WGLC. Unbound 1.0.0 implements the forgery resilience measures. They are enabled by default. And I think these measures are important for modern day resolvers. Let me emphasize that I think the content was well worth implementing to enhance security, before I continue to critique the text of the document. I think that because the measures are not to cause interoperability in the DNS but for security enhancement, this draft is a BCP (not standards track). I think the line 'This document updates RFC 1034' should be removed. I do not think there is any reason. About the case sensitivity idea. I have also implemented that in unbound, however, the default is turned off. The fall back when no the case fails needs to get a serious calculation of how many queries to retry before accepting the downgrade to case insensitive. The number of queries needs to be considered in the light of a DoS or flood because of this. Otherwise, I think case sensitive query name comparisons could be a very good idea, and could fit in the framework provided by this draft. The second formula in section 7.2 has one too many '-' in the dividing line, otherwise, the ascii art formulas are nicely done. The unbound implementation uses a practical range of ports, about 59k ports, using above 1024, avoiding ports in the IANA allocated ports list, and leaving open a couple small windows in the traditional unix ephemeral port system ranges. These choices are made to avoid denial of service by grabbing important ports for the server that the resolver is running on. I think the current text about port ranges is sort of OK, but these recommendations may be helpful to other implementors. However, the paragraph: ~ If a resolver sends out multiple equivalent queries to any ~ authoritative server, before receiving a response, all MUST have ~ identical ID, source address and source port. MUST change to SHOULD. Please add more text to explain the following: It is allowed to send multiple queries to an authoritative server before receiving a response, e.g. due to UDP time outs, but at any time the server MUST only accept for reception one tuple of ID, source address and source port. So, in order to follow this precisely (and unbound doesn't due to UDP retry logic), I want this changed so that the resolver is required to only *listen* to one ID, source addres and source port combination. bert hubert in the Authors Addresses is missing capitalization. The header says A. Hubert. So, I think the draft is fine, but should be changed, as above. Also, it should be BCP. Additionally, if name comparison sensitivity work is done, I would prefer that that new text is presented to the working group to get feedback on that text. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhktHgACgkQkDLqNwOhpPjVuQCggs4FAWjz2t1hR1n+AQ7N0zqD po0AnRk7qPFthrtLN3WxBPhi+GvBULZ9 =IuUV -----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 Fri Jun 27 05:41:09 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35653A68B3; Fri, 27 Jun 2008 05:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.734 X-Spam-Level: X-Spam-Status: No, score=0.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+kmVOTIIEik; Fri, 27 Jun 2008 05:41:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEE9C3A67A7; Fri, 27 Jun 2008 05:41:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCD85-0006Vl-1J for namedroppers-data@psg.com; Fri, 27 Jun 2008 12:32:41 +0000 Received: from [69.46.124.26] (helo=outbound.afilias.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCD81-0006VA-C0 for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 12:32:39 +0000 Received: from bmp-336-ms505.wa.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1KCD7w-0002h6-4m; Fri, 27 Jun 2008 12:32:32 +0000 Cc: IETF DNSEXT WG Message-Id: <41077817-2D2A-4F5E-B7A2-DD660C2A0D30@ca.afilias.info> From: Shane Kerr To: Wouter Wijngaards In-Reply-To: <4864B478.7030702@nlnetlabs.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Name sensitivity, was Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Date: Fri, 27 Jun 2008 14:32:29 +0200 References: <200806262033.m5QKXJxA036876@ogud.com> <200806270307.m5R37eeg039543@ogud.com> <4864B478.7030702@nlnetlabs.nl> X-Mailer: Apple Mail (2.924) X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 27, 2008, at 11:35 +0200, Wouter Wijngaards wrote: > > > About the case sensitivity idea. I have also implemented that in > unbound, however, the default is turned off. The fall back when no > the > case fails needs to get a serious calculation of how many queries to > retry before accepting the downgrade to case insensitive. The > number of > queries needs to be considered in the light of a DoS or flood > because of > this. Otherwise, I think case sensitive query name comparisons > could be > a very good idea, and could fit in the framework provided by this > draft. Most cache poisoning attacks are going to rely on guessing state from the querying server, so this involves sending multiple answers to a query, right? In this case, I think rather that as soon as a server has answered a query preserving case, then future queries to that server should rely on that behavior. It means sort of increasing the security if possible, rather than trying to determine whether a server preserves case through retries. There are problems with this of course (operators using multiple vendors on a single IP address via load balancing, for example), but I think it is basically a way to add 0x20-style security without extra packets. > Additionally, if name comparison sensitivity work is > done, I would prefer that that new text is presented to the working > group to get feedback on that text. I agree. -- Shane -- to unsubscribe send a message to namedroppers-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 Jun 27 07:07:57 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4B73A69AD; Fri, 27 Jun 2008 07:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=1.375, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0epKoxwSWmQ; Fri, 27 Jun 2008 07:07:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2921E3A68C8; Fri, 27 Jun 2008 07:07:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCESX-000ILj-Kn for namedroppers-data@psg.com; Fri, 27 Jun 2008 13:57:53 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCESQ-000IKK-7P for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 13:57:51 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id AB2511143E; Fri, 27 Jun 2008 13:57:38 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Shane Kerr cc: Wouter Wijngaards , IETF DNSEXT WG Subject: Re: Name sensitivity, was Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" In-Reply-To: Your message of "Fri, 27 Jun 2008 14:32:29 +0200." <41077817-2D2A-4F5E-B7A2-DD660C2A0D30@ca.afilias.info> References: <200806262033.m5QKXJxA036876@ogud.com> <200806270307.m5R37eeg039543@ogud.com> <4864B478.7030702@nlnetlabs.nl> <41077817-2D2A-4F5E-B7A2-DD660C2A0D30@ca.afilias.info> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 27 Jun 2008 13:57:38 +0000 Message-ID: <44854.1214575058@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Shane Kerr > ... > In this case, I think rather that as soon as a server has answered a query > preserving case, then future queries to that server should rely on that > behavior. It means sort of increasing the security if possible, rather than > trying to determine whether a server preserves case through retries. > > There are problems with this of course (operators using multiple vendors on > a single IP address via load balancing, for example), but I think it is > basically a way to add 0x20-style security without extra packets. how will you know if a server preserves case unless you send something having mixed case and it echos you, and then you send it different mixed case and it echos that also? responses are supposed to be in "zone case". so if you query for 3com.com you get back 3Com.com, as a way to protect the zone owner's trademarks. the implementations i tested almost always answer in "query case" except where they "always downshift to lower case". nobody preserves "zone case", which is a latent bug and if i worked at 3Com i'd be angry about it. furthermore, name compression in intermediaries tends to ignore case, so if the first instance of the "3Com.com" domain happens to be "3COM.COM" then that case will be seen not just in the answer section but also the authority and additional sections. therefore the parent zone's delegation is likely to have more impact on the case of a domain name than anything at the apex, since it'll have entered a given cache first. the reason dns-0x20 currently says "try several times with different cases and make the server solve your case-riddle and solve different QID-riddles each time" is to be sure that a case-mismatch in the response isn't due to any kind of attack. so the thing dns-0x20 is trying to prove is that you're safe to consume a mismatching answer, and not that a given server does or doesn't preserve case. that difference sounds subtle but it's gigantic. and i don't see how to do it without extra packets. but i don't mind those extra packets, it only overloads servers who don't preserve case, and they have a trivial way to get the extra traffic to stop: start preserving case. > > Additionally, if name comparison sensitivity work is done, I would prefer > > that that new text is presented to the working group to get feedback on > > that text. > > I agree. it was previously agreed here that we would not workshop the dns-0x20 idea as part of the forgery-resilience effort, and that the two drafts would proceed independently. forgery-resilience is already two years old and i'd rather see it published without any mention (that is, no mention at all) of domain name case. i have not read the current draft but if it talks at all about preserving case or comparing casefully vs. caselessly then i object. i welcome comments on the dns-0x20 draft itself, but not if it makes the forgery-resilience draft take longer to see the light of day. we need it out in the field. actually we needed it years ago. let's get it out there. -- to unsubscribe send a message to namedroppers-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 Jun 27 08:02:45 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4AD3A6B29; Fri, 27 Jun 2008 08:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbqPckTh00KT; Fri, 27 Jun 2008 08:02:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 567323A6B15; Fri, 27 Jun 2008 08:02:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCFNH-000P3T-IB for namedroppers-data@psg.com; Fri, 27 Jun 2008 14:56:31 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCFN0-000P1b-2h for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 14:56:29 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5REtpx4016080; Fri, 27 Jun 2008 10:55:52 -0400 Message-ID: <4864FF7B.1020300@nist.gov> Date: Fri, 27 Jun 2008 10:55:55 -0400 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_chair?= CC: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" References: <200806262033.m5QKXJxA036876@ogud.com> In-Reply-To: <200806262033.m5QKXJxA036876@ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I've read the draft and after Paul Hoffman's comments/changes are addressed I think it should move forward. One comment: "In case these abilities are enabled, the implementation MUST strive to have its choices of source port and query ID remain unpredictable, even if an attacker has knowledge of its (pseudo-)random generator." Along the lines of Paul's comment - can the implementer really guarantee that in any way? I think the MUST in the above can be toned down or dropped. Scott Ólafur Guðmundsson /DNSEXT chair wrote: > > This note starts a Working Group Last Call for this Standards Track > document > ending on noon July 12'th 2006 (Dublin time). > > URL for the document and its history: > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/ > > > This document updates and clarifies RFC1034 in how a resolver should > generate > random query ID, how to use multiple ports and possibly addresses to make > it harder to guess the details of a query by a particular resolver. > > Please read the document carefully, in particular section 9. At this point > the chairs would like to know if the current RFC2119 wording in that > section is acceptable or how it can be improved. > > The document process rules in this group, require that at least > 5 members of the working to state that they have read the document > and there is consensus of support to publish as an Standards Track RFC. > > Olafur & Andrew > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- ---------------------------------------- Scott Rose Computer Scientist NIST ph: +1 301-975-8439 scott.rose@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Jun 27 08:27:33 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EBD73A69A9; Fri, 27 Jun 2008 08:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBeo+NWVz94F; Fri, 27 Jun 2008 08:27:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 516B73A6903; Fri, 27 Jun 2008 08:27:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCFll-00025D-SX for namedroppers-data@psg.com; Fri, 27 Jun 2008 15:21:49 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCFlQ-000239-1A for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 15:21:38 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8AF6311439; Fri, 27 Jun 2008 15:21:27 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: new draft of Forgery Resilience posted - summary of changes In-Reply-To: Your message of "Thu, 26 Jun 2008 16:46:45 +0200." <20080626144644.GD19608@outpost.ds9a.nl> References: <20080623175938.GA9771@outpost.ds9a.nl> <20080626144644.GD19608@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 27 Jun 2008 15:21:27 +0000 Message-ID: <48570.1214580087@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > I've just posted version -05 of the Forgery Resilience draft. It has > appeared on > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-05.txt i object to this language: o Question name (compared case-insensitively) please change it to say: o Question name otherwise, i echo all of wouter winknaards' suggestions, especially the part about removing this header: Updates: 1034 (if approved) -- to unsubscribe send a message to namedroppers-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 Jun 27 10:04:20 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808A23A6900; Fri, 27 Jun 2008 10:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm5XruoMQ70L; Fri, 27 Jun 2008 10:04:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 633DD3A69C0; Fri, 27 Jun 2008 10:02:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCGdT-0009Oc-9L for namedroppers-data@psg.com; Fri, 27 Jun 2008 16:17:19 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCGdP-0009Nq-Nq for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 16:17:17 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5RGGpDx069445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2008 09:16:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4864B478.7030702@nlnetlabs.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <200806270307.m5R37eeg039543@ogud.com> <4864B478.7030702@nlnetlabs.nl> Date: Fri, 27 Jun 2008 09:16:50 -0700 To: Wouter Wijngaards , Olafur Gudmundsson From: Paul Hoffman Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 11:35 AM +0200 6/27/08, Wouter Wijngaards wrote: >I think the line 'This document updates RFC 1034' should be removed. I >do not think there is any reason. There are SHOULDs and MUSTs in this document that are not in 1034 in areas that 1034 touches on, so it does in fact update 1034. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 27 10:04:24 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BBA93A697D; Fri, 27 Jun 2008 10:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E2cJhWia6s3; Fri, 27 Jun 2008 10:04:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DABE03A6B59; Fri, 27 Jun 2008 10:03:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCGjy-000A66-65 for namedroppers-data@psg.com; Fri, 27 Jun 2008 16:24:02 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCGjq-000A4x-Ju for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 16:24:00 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 42A5411425; Fri, 27 Jun 2008 16:23:54 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Paul Hoffman cc: IETF DNSEXT WG Subject: Re: Name sensitivity, was Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" In-Reply-To: Your message of "Fri, 27 Jun 2008 08:58:58 MST." References: <200806262033.m5QKXJxA036876@ogud.com> <200806270307.m5R37eeg039543@ogud.com> <4864B478.7030702@nlnetlabs.nl> <41077817-2D2A-4F5E-B7A2-DD660C2A0D30@ca.afilias.info> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 27 Jun 2008 16:23:54 +0000 Message-ID: <50986.1214583834@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Paul Hoffman > > This seems to be adding a new and useful feature in a terribly kludgy way > that is likely to cause hidden interoperability problems. The WG should > balance whether or not the value (harder to forge when the feature works) is > worth those potential problems. http://tools.ietf.org/id/draft-vixie-dnsext-dns0x20-00.txt is the draft, and it is unrelated to forgery-resilience, which is today's topic here. please read the draft and comment on it (everybody, not just mr. hoffman). > If not, creating a trivial DNS extension (add another 64 bits of randomness) > would gain the benefit desired with no interop problems for those systems > that implement the new extension. trivial? "you keep using that word; i do not think it means what you think it means." or perhaps: "they tried, and failed?" ... "they tried, and died." -- to unsubscribe send a message to namedroppers-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 Jun 27 10:04:25 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B583A6921; Fri, 27 Jun 2008 10:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LbCbuJcNSCO; Fri, 27 Jun 2008 10:04:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 391CD3A6822; Fri, 27 Jun 2008 10:04:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCGLw-00075H-Kk for namedroppers-data@psg.com; Fri, 27 Jun 2008 15:59:12 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCGLo-00072b-0o for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 15:59:10 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5RFx2rt067893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jun 2008 08:59:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <41077817-2D2A-4F5E-B7A2-DD660C2A0D30@ca.afilias.info> References: <200806262033.m5QKXJxA036876@ogud.com> <200806270307.m5R37eeg039543@ogud.com> <4864B478.7030702@nlnetlabs.nl> <41077817-2D2A-4F5E-B7A2-DD660C2A0D30@ca.afilias.info> Date: Fri, 27 Jun 2008 08:58:58 -0700 To: IETF DNSEXT WG From: Paul Hoffman Subject: Re: Name sensitivity, was Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This seems to be adding a new and useful feature in a terribly kludgy way that is likely to cause hidden interoperability problems. The WG should balance whether or not the value (harder to forge when the feature works) is worth those potential problems. If not, creating a trivial DNS extension (add another 64 bits of randomness) would gain the benefit desired with no interop problems for those systems that implement the new extension. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 27 11:39:42 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10413A68DD; Fri, 27 Jun 2008 11:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.275 X-Spam-Level: X-Spam-Status: No, score=-4.275 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP3fmdAjM+d0; Fri, 27 Jun 2008 11:39:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 95BD73A6813; Fri, 27 Jun 2008 11:39:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCIiX-0001ji-RG for namedroppers-data@psg.com; Fri, 27 Jun 2008 18:30:41 +0000 Received: from [207.219.45.62] (helo=mx4.ca.afilias.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCIiT-0001j9-8D for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 18:30:39 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1KCIiN-0006Fp-Mc; Fri, 27 Jun 2008 14:30:31 -0400 Message-ID: <486531C2.4040608@ca.afilias.info> Date: Fri, 27 Jun 2008 14:30:26 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Paul Vixie CC: Shane Kerr , Wouter Wijngaards , IETF DNSEXT WG Subject: Re: Name sensitivity, was Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" References: <200806262033.m5QKXJxA036876@ogud.com> <200806270307.m5R37eeg039543@ogud.com> <4864B478.7030702@nlnetlabs.nl> <41077817-2D2A-4F5E-B7A2-DD660C2A0D30@ca.afilias.info> <44854.1214575058@sa.vix.com> In-Reply-To: <44854.1214575058@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: >> From: Shane Kerr >> ... >> In this case, I think rather that as soon as a server has answered a query >> preserving case, then future queries to that server should rely on that >> behavior. It means sort of increasing the security if possible, rather than >> trying to determine whether a server preserves case through retries. >> >> There are problems with this of course (operators using multiple vendors on >> a single IP address via load balancing, for example), but I think it is >> basically a way to add 0x20-style security without extra packets. >> > > how will you know if a server preserves case unless you send something having > mixed case and it echos you, and then you send it different mixed case and it > echos that also? > [snip] > and i don't see how to do it without extra packets. but i don't mind those > extra packets, it only overloads servers who don't preserve case, and they > have a trivial way to get the extra traffic to stop: start preserving case. > > "Don't check for an error condition you don't know how to handle." Corollary - don't check for things you don't care about. This can be handled nearly trivially, with one extra query (and then only for those servers who don't preserve the case of the query): => If the question in the response matches case-insensitively, but not case sensitively, re-query with the question *from* the suspect answer, including the answer's question's case. => If *that* doesn't match upon receiving an answer, that's an error, for sure. Here's why: => If something is not preserving case, but gives otherwise matching answers, then it could reasonably be expected to return *consistent* results. E.g. Q->A: Foo->Foo (good - case matched) vs Foo->FOO (try one more time) FOO->FOO (good - results were the same, and on the second query case matched.) vs Foo->foo (try one more time) foo->FOO (bad - results changed between case-insensitive identical queries) There are probably some corner cases involving load balancers and heterogenous software implementations. I believe it is the case that either: (1) case should be preserved between query and response (2) case of answer should be independent of case of query, *but* always the same for a given label in the zone. Is this an assertion true as either (1) or (2), for all known authority server software systems deployed? Does anyone know, or have a good guess? Does anyone know of counterexamples? >>> Additionally, if name comparison sensitivity work is done, I would prefer >>> that that new text is presented to the working group to get feedback on >>> that text. >>> >> I agree. >> > > it was previously agreed here that we would not workshop the dns-0x20 idea > as part of the forgery-resilience effort, and that the two drafts would > proceed independently. forgery-resilience is already two years old and i'd > rather see it published without any mention (that is, no mention at all) of > domain name case. i have not read the current draft but if it talks at all > about preserving case or comparing casefully vs. caselessly then i object. > > i welcome comments on the dns-0x20 draft itself, but not if it makes the > forgery-resilience draft take longer to see the light of day. we need it > out in the field. actually we needed it years ago. let's get it out there. > I agree whole-heartedly (and then some) with this last statement. If it isn't nearly trivial to add case stuff, in terms of required/recommended, perhaps as a footnote/appendix, i.e. outside of the official aspects of the ID, would be a prudent thing to do... Brian -- to unsubscribe send a message to namedroppers-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 Jun 27 11:51:52 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93A33A6B1E; Fri, 27 Jun 2008 11:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N9Aunm8VlQn; Fri, 27 Jun 2008 11:51:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7EF313A6B1C; Fri, 27 Jun 2008 11:51:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCIwe-0003Z7-TP for namedroppers-data@psg.com; Fri, 27 Jun 2008 18:45:16 +0000 Received: from [131.111.8.131] (helo=ppsw-1.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCIwL-0003V4-P7 for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 18:45:07 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:50465) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1KCIw5-0004w2-6I (Exim 4.67) (return-path ); Fri, 27 Jun 2008 19:44:41 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KCIw5-00050m-UF (Exim 4.67) (return-path ); Fri, 27 Jun 2008 19:44:41 +0100 Date: Fri, 27 Jun 2008 19:44:41 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Brian Dickson cc: =?ISO-8859-15?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT_chair?= , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" In-Reply-To: <48640EEF.9000506@ca.afilias.info> Message-ID: References: <200806262033.m5QKXJxA036876@ogud.com> <48640EEF.9000506@ca.afilias.info> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, 26 Jun 2008, Brian Dickson wrote: > > Has consideration been given on the matching of "Question name", in a > case-SENSITIVE manner? I think the conclusion of Vixie's 0x20 discussion was to keep it separate from Bert's draft, because 0x20 introduces interoperability problems whereas the forgery-resilience techniques are safe. Tony. -- f.anthony.n.finch http://dotat.at/ FORTIES CROMARTY FORTH: MAINLY SOUTHWESTERLY 4 OR 5, OCCASIONALLY 6, BECOMING VARIABLE 4. MODERATE OR ROUGH DECREASING SLIGHT OR MODERATE. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. -- to unsubscribe send a message to namedroppers-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 Jun 27 11:56:56 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D12A3A68DD; Fri, 27 Jun 2008 11:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2Go3s2IeBqu; Fri, 27 Jun 2008 11:56:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 998D93A6B1E; Fri, 27 Jun 2008 11:56:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCJ40-0004RI-JO for namedroppers-data@psg.com; Fri, 27 Jun 2008 18:52:52 +0000 Received: from [131.111.8.136] (helo=ppsw-6.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCJ3w-0004QJ-61 for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 18:52:50 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58601) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1KCJ3O-00065n-Jp (Exim 4.67) (return-path ); Fri, 27 Jun 2008 19:52:14 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KCJ3O-0005tF-49 (Exim 4.67) (return-path ); Fri, 27 Jun 2008 19:52:14 +0100 Date: Fri, 27 Jun 2008 19:52:14 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Scott Rose cc: =?ISO-8859-15?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT_chair?= , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" In-Reply-To: <4864FF7B.1020300@nist.gov> Message-ID: References: <200806262033.m5QKXJxA036876@ogud.com> <4864FF7B.1020300@nist.gov> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, 27 Jun 2008, Scott Rose wrote: > > "In case these abilities are enabled, the implementation MUST strive > to have its choices of source port and query ID remain unpredictable, > even if an attacker has knowledge of its (pseudo-)random generator." > > Along the lines of Paul's comment - can the implementer really guarantee that > in any way? I think the MUST in the above can be toned down or dropped. Perhaps it should say "knowledge of the implementation of its (pseudo-)random number generator" as opposed to its secret internal state. This is the usual criterion for a cryptographically secure PRNG. Tony. -- f.anthony.n.finch http://dotat.at/ ROCKALL MALIN: CYCLONIC BECOMING SOUTHWESTERLY 5 OR 6, OCCASIONALLY 7 AT FIRST. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. RAIN OR THUNDERY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. -- to unsubscribe send a message to namedroppers-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 Jun 27 15:19:26 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD7B3A6975; Fri, 27 Jun 2008 15:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t64upUMzGfKb; Fri, 27 Jun 2008 15:19:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CC00A3A67E3; Fri, 27 Jun 2008 15:19:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCM9i-000486-C7 for namedroppers-data@psg.com; Fri, 27 Jun 2008 22:10:58 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCM9e-00047R-If for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 22:10:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0BDBA11425; Fri, 27 Jun 2008 22:10:49 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Brian Dickson cc: Shane Kerr , Wouter Wijngaards , IETF DNSEXT WG Subject: Re: Name sensitivity, was Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" In-Reply-To: Your message of "Fri, 27 Jun 2008 14:30:26 -0400." <486531C2.4040608@ca.afilias.info> References: <200806262033.m5QKXJxA036876@ogud.com> <200806270307.m5R37eeg039543@ogud.com> <4864B478.7030702@nlnetlabs.nl> <41077817-2D2A-4F5E-B7A2-DD660C2A0D30@ca.afilias.info> <44854.1214575058@sa.vix.com> <486531C2.4040608@ca.afilias.info> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 27 Jun 2008 22:10:49 +0000 Message-ID: <64044.1214604649@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > There are probably some corner cases involving load balancers and > heterogenous software implementations. indeed, i think my proposed mechanism would still have to be used, because of the degenerate HA/LB case. -- to unsubscribe send a message to namedroppers-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 Jun 27 16:37:53 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267913A682C; Fri, 27 Jun 2008 16:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNhoTFXhlwSO; Fri, 27 Jun 2008 16:37:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 15F5A3A6800; Fri, 27 Jun 2008 16:37:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCNOt-000DH1-2S for namedroppers-data@psg.com; Fri, 27 Jun 2008 23:30:43 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCNOp-000DGh-6z for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 23:30:41 +0000 Received: from [165.227.249.200] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5RNUbIf098356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jun 2008 16:30:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <486531C2.4040608@ca.afilias.info> References: <200806262033.m5QKXJxA036876@ogud.com> <200806270307.m5R37eeg039543@ogud.com> <4864B478.7030702@nlnetlabs.nl> <41077817-2D2A-4F5E-B7A2-DD660C2A0D30@ca.afilias.info> <44854.1214575058@sa.vix.com> <486531C2.4040608@ca.afilias.info> Date: Fri, 27 Jun 2008 16:30:34 -0700 To: From: Paul Hoffman Subject: Re: Name sensitivity, was Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 2:30 PM -0400 6/27/08, Brian Dickson wrote: > Foo->FOO (try one more time) > FOO->FOO (good - results were the same, and on the second query >case matched.) If the attacker knew you were doing this, why wouldn't he just send back the same response to your second query, like half a second later? --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 27 17:25:12 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6218B3A6800; Fri, 27 Jun 2008 17:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=-1.966, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, RCVD_IN_XBL=3.033, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSODkm9Ulkxk; Fri, 27 Jun 2008 17:25:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FC003A6814; Fri, 27 Jun 2008 17:25:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCO9p-000JaW-Od for namedroppers-data@psg.com; Sat, 28 Jun 2008 00:19:13 +0000 Received: from [207.219.45.62] (helo=mx4.ca.afilias.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCO9l-000JZu-F4 for namedroppers@ops.ietf.org; Sat, 28 Jun 2008 00:19:11 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1KCO9k-0004Kz-FL; Fri, 27 Jun 2008 20:19:08 -0400 Message-ID: <48658377.4020008@ca.afilias.info> Date: Fri, 27 Jun 2008 20:19:03 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Paul Hoffman CC: namedroppers@ops.ietf.org Subject: Re: Name sensitivity, was Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" References: <200806262033.m5QKXJxA036876@ogud.com> <200806270307.m5R37eeg039543@ogud.com> <4864B478.7030702@nlnetlabs.nl> <41077817-2D2A-4F5E-B7A2-DD660C2A0D30@ca.afilias.info> <44854.1214575058@sa.vix.com> <486531C2.4040608@ca.afilias.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Hoffman wrote: > At 2:30 PM -0400 6/27/08, Brian Dickson wrote: >> Foo->FOO (try one more time) >> FOO->FOO (good - results were the same, and on the second query >> case matched.) > > If the attacker knew you were doing this, why wouldn't he just send > back the same response to your second query, like half a second later? The presumptions (in the ID) are that the attacker doesn't have access to the wire itself, and does not have control of arbitrary authority servers. At best, the attacker has control of some authority server somewhere. The recommendations of the ID include, repeat queries using different source ports. This alone would defeat the "send back the same response" vector. Plus: If the attacker can deterministically know the parameters to inject bad "foo", you're already toast. If the attacker doesn't, the case check is no worse, probably a bit better, and possibly a lot better. Note the following: The probability for a single-instance birthday attack, based on random query-id, is low even with other factors weakening things (e.g. number of ports used << 2^16). The probability of two successive such successful injections (i.e. both succeed in guessing PRNG 16-bit values) is substantially lower, i.e. decreases from 1/N to 1/(N^2) for some (large) value N. (That's why I raised the case issue, and hinted that while not strictly necessarily, having it dovetail into the 0x20 proposal, is a nice segue.) Brian -- to unsubscribe send a message to namedroppers-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 Jun 27 18:31:04 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47233A6828; Fri, 27 Jun 2008 18:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.014 X-Spam-Level: X-Spam-Status: No, score=-4.014 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajQfvjFl+y9a; Fri, 27 Jun 2008 18:31:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 36EEB3A6782; Fri, 27 Jun 2008 18:31:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCP9m-0001DF-4y for namedroppers-data@psg.com; Sat, 28 Jun 2008 01:23:14 +0000 Received: from [64.18.1.183] (helo=exprod6og102.obsmtp.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCP9h-0001CR-MF for namedroppers@ops.ietf.org; Sat, 28 Jun 2008 01:23:11 +0000 Received: from source ([63.240.6.3]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP; Fri, 27 Jun 2008 18:23:05 PDT Received: from d01smtp07.Mi8.com ([172.16.1.114]) by Outbound02.Mi8.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 21:26:03 -0400 Received: from D01SMTP04.Mi8.com ([172.16.1.243]) by d01smtp07.Mi8.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 21:26:03 -0400 Received: from mail pickup service by D01SMTP04.Mi8.com with Microsoft SMTPSVC; Fri, 27 Jun 2008 21:25:42 -0400 Received: from psmtp.com ([64.18.1.123]) by D01SMTP04.Mi8.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 15:03:18 -0400 Received: from source ([147.28.0.62]) (using TLSv1) by exprod6mx223.postini.com ([64.18.5.10]) with SMTP; Fri, 27 Jun 2008 14:00:14 CDT Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCIwe-0003Z7-TP for namedroppers-data@psg.com; Fri, 27 Jun 2008 18:45:16 +0000 Received: from [131.111.8.131] (helo=ppsw-1.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCIwL-0003V4-P7 for namedroppers@ops.ietf.org; Fri, 27 Jun 2008 18:45:07 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:50465) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1KCIw5-0004w2-6I (Exim 4.67) (return-path ); Fri, 27 Jun 2008 19:44:41 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KCIw5-00050m-UF (Exim 4.67) (return-path ); Fri, 27 Jun 2008 19:44:41 +0100 Date: Fri, 27 Jun 2008 19:44:41 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Brian Dickson cc: =?ISO-8859-15?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT_chair?= , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" In-Reply-To: <48640EEF.9000506@ca.afilias.info> Message-ID: References: <200806262033.m5QKXJxA036876@ogud.com> <48640EEF.9000506@ca.afilias.info> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-ID: X-pstn-neptune: 0/0/0.00/0 X-pstn-levels: (S:99.90000/99.90000 CV:99.0000 R:95.9108 P:95.9108 M:97.0282 C:98.6951 ) X-pstn-settings: 5 (2.0000:2.0000) s cv gt3 gt2 gt1 r p m c X-pstn-addresses: from [17/1] X-OriginalArrivalTime: 27 Jun 2008 19:03:18.0226 (UTC) FILETIME=[75B8DB20:01C8D888] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, 26 Jun 2008, Brian Dickson wrote: > > Has consideration been given on the matching of "Question name", in a > case-SENSITIVE manner? I think the conclusion of Vixie's 0x20 discussion was to keep it separate from Bert's draft, because 0x20 introduces interoperability problems whereas the forgery-resilience techniques are safe. Tony. -- f.anthony.n.finch http://dotat.at/ FORTIES CROMARTY FORTH: MAINLY SOUTHWESTERLY 4 OR 5, OCCASIONALLY 6, BECOMING VARIABLE 4. MODERATE OR ROUGH DECREASING SLIGHT OR MODERATE. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. -- to 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 Jun 28 00:21:30 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7F83A6ADB; Sat, 28 Jun 2008 00:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5jgWPV51uNk; Sat, 28 Jun 2008 00:21:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DBC0D3A68C6; Sat, 28 Jun 2008 00:21:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCUcJ-000Igw-GY for namedroppers-data@psg.com; Sat, 28 Jun 2008 07:13:03 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCUc0-000Ieo-84 for namedroppers@ops.ietf.org; Sat, 28 Jun 2008 07:12:54 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KCUbs-0007PI-4X for namedroppers@ops.ietf.org; Sat, 28 Jun 2008 09:12:36 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 46CF94B4D6; Sat, 28 Jun 2008 09:12:49 +0200 (CEST) Date: Sat, 28 Jun 2008 09:12:48 +0200 From: bert hubert To: Tony Finch Cc: Brian Dickson , ?lafur Gu?mundsson /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <20080628071248.GA10892@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <48640EEF.9000506@ca.afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 27, 2008 at 07:44:41PM +0100, Tony Finch wrote: > > Has consideration been given on the matching of "Question name", in a > > case-SENSITIVE manner? > > I think the conclusion of Vixie's 0x20 discussion was to keep it separate > from Bert's draft, because 0x20 introduces interoperability problems I would indeed vastly prefer to keep things separate. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source 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 Sun Jun 29 04:46:17 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77D643A6811; Sun, 29 Jun 2008 04:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.267 X-Spam-Level: X-Spam-Status: No, score=-103.267 tagged_above=-999 required=5 tests=[AWL=3.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgSfACoBCZ+s; Sun, 29 Jun 2008 04:46:16 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 576E63A67F9; Sun, 29 Jun 2008 04:46:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvFU-000MPf-IO for namedroppers-data@psg.com; Sun, 29 Jun 2008 11:39:16 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvFK-000MOR-GX for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 11:39:14 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KCvFI-0002Be-PJ for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 13:39:04 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 2632C4554; Sun, 29 Jun 2008 13:39:18 +0200 (CEST) Date: Sun, 29 Jun 2008 13:39:18 +0200 From: bert hubert To: Tony Finch Cc: Scott Rose , ?lafur Gu?mundsson /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <20080629113918.GD10892@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <4864FF7B.1020300@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 27, 2008 at 07:52:14PM +0100, Tony Finch wrote: > Perhaps it should say "knowledge of the implementation of its > (pseudo-)random number generator" as opposed to its secret internal state. > This is the usual criterion for a cryptographically secure PRNG. Added this, thanks. http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/28 -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source 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 Sun Jun 29 04:46:19 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DCDF3A6833; Sun, 29 Jun 2008 04:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.474 X-Spam-Level: X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NRRka53itPL; Sun, 29 Jun 2008 04:46:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 870403A67F9; Sun, 29 Jun 2008 04:46:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvCb-000M3L-JJ for namedroppers-data@psg.com; Sun, 29 Jun 2008 11:36:17 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvCO-000M1k-4g for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 11:36:15 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KCvCJ-00025B-1l for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 13:35:59 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id F03144554; Sun, 29 Jun 2008 13:36:11 +0200 (CEST) Date: Sun, 29 Jun 2008 13:36:11 +0200 From: bert hubert To: Paul Hoffman Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <20080629113611.GC10892@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 26, 2008 at 02:59:13PM -0700, Paul Hoffman wrote: > >9. Recommended Countermeasures > > This should be "Required Countermeasures" because of the use of the > word "MUST" in the body of the section. I've changed it to 'Countermeasures' while this discussion runs. > > [Local address, Query port, Query ID, Question name,Question class and type] > > before applying DNS trustworthiness rules (see [RFC2181], section > > 5.4.1). More precisely, the response source IP address MUST match > > the query's destination IP address and the response destination IP > > address MUST match the query's source IP address. > > What happened to the other fields (query port, ID, name, and class)? > This sentence sounds like that only the addresses must match, which > is not what the rest of the section says. I propose dropping this > sentence, or making it much longer. This sentence was added during the previous round of editing. It indeeds adds only a partial explanation. As a middle ground, I've removed this partial improvement, and beefed up the original bullet-points: Given the above, a resolver implementation MUST match responses to the following attributes of the query: * Source address against query destination address * Destination address agaist query source address * Destination port against query source port * Query ID * Question name * Question class and type before applying DNS trustworthiness rules (see , section 5.4.1). > > A mismatch should > > be considered a format error, and the response invalid. > > A mismatch MUST be considered a format error and the response MUST be > considered invalid. Makes sense. > > full range available (0-65535); > > (Editorial: drop the last semicolon) Thanks. > A conformant implementation "MUST have the ability" to do those > things, but doesn't need to make that available to the operator? That > seems like undershooting the goal. Proposed change: Do you think we need to make it explicit? Having an ability appears to imply that it can be used. > A resolver MUST use an unpredictable source port for outgoing queries > in a port range that is as large as possible and practicable. That > range SHOULD be 53 plus 1024 to 65535 inclusive unless other While I see merit in your suggested changes, this paragraph is starting to suffer from metal fatigue and it will soon break. In other words, I prefer not to tinker with it anymore unless the improvement is vast. > > In case these abilities are enabled, the implementation MUST strive > > to have its choices of source port and query ID remain unpredictable, > > even if an attacker has knowledge of its (pseudo-)random generator. > > How would an implementer do that? If this means to say "use a secret > value as a seed to the pseudo-random generator", it needs to say so > explicitly. This is one way to do it, I'm not ruling out anybody using a hardware random generator. I've added: 'This can be achieved by seeding an algorithm with a secret state.'. > > If a resolver is multihomed or otherwise has the ability to transmit > > and receive datagrams using more than one IP source address, then an > > IP address can be chosen at random in order to increase an attacker's > > difficulty in guessing what address to flood. > > Worded as a requirement: "...then an IP address SHOULD be chosen at > random unless doing so would have a negative operational impact, in > order to..." This is an operator requirement, and hence outside the cope of this document. > > Resolvers SHOULD favour authoritative nameservers with which a trust > > relation has been established; > > Why is this a SHOULD instead of a MUST? Under what circumstances > would I accept an response from an untrusted server over one from a > strusted server? Fine. > > Stub-resolvers SHOULD be able to use > > TSIG ([RFC2845]) or IPSEC ([RFC4301]) when communicating with their > > recursive resolver. > > Add "if those services are available" to the end of the sentence to > explain the SHOULD. Done. > > In case a cryptographic verification of response validity is > > available, resolver implementations MAY waive above rules, and rely > > on this guarantee instead. > > This is completely unclear. Does it mean DNSSEC, IPSEC, or TSIG, all > of which give cryptographic verification? Which "above rules" might > be waved? I've move this paragraph up so it covers only ('the above') the things you could do away with when using cryptgraphic verification of response *authenticity*. I don't want to restrict this document to any specific verification protocol that might come along. So DNSSEC, IPSEC, TSIG might all be fine. > > Proper unpredictability can be achieved by employing a high quality > > random generator, as described in [RFC4086]. > > Most of RFC 4086 is about pseudo-random generators, not true random I've added '(pseudo-)'. This paragraph is the result of prolonged discussions, and it too is starting to suffer from metal fatigue, hence only a small change. > The "MAY" here seems weak. It may abandon UDP any time it wants > anyway. Also, the word "spoof" in this context is quite unclear. > Normally, it is used as an active verb, such as "Mallory tried to > spoof the responses". Proposed rewording: I'm pondering better wording for this paragraph. Your suggestion comes a long way but it is still not abundantly clear. > ----- > If a resolver detects that an attempt is being made to send it > spoofed responses, perhaps by discovering that many packets fail the > five criteria for matching queries to responses, the resolver SHOULD > abandon the UDP query and re-issue it over TCP if using TCP is > possible in the system. > ----- On the MAY, SHOULD front, I think this needs some more discussion. Paul, many thanks for your careful reading of the draft! Your changes can be seen in http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/27 Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source 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 Sun Jun 29 04:46:28 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92703A6833; Sun, 29 Jun 2008 04:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvEKkicGvvOA; Sun, 29 Jun 2008 04:46:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B0BD63A67F9; Sun, 29 Jun 2008 04:46:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvHc-000Mkb-9Y for namedroppers-data@psg.com; Sun, 29 Jun 2008 11:41:28 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvHY-000Mhd-L9 for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 11:41:26 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KCvHW-0002Da-ME for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 13:41:22 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 253634554; Sun, 29 Jun 2008 13:41:36 +0200 (CEST) Date: Sun, 29 Jun 2008 13:41:36 +0200 From: bert hubert To: Scott Rose Cc: ?lafur Gu?mundsson /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <20080629114135.GE10892@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <4864FF7B.1020300@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4864FF7B.1020300@nist.gov> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 27, 2008 at 10:55:55AM -0400, Scott Rose wrote: > I've read the draft and after Paul Hoffman's comments/changes are > addressed I think it should move forward. Thanks. > "In case these abilities are enabled, the implementation MUST strive > to have its choices of source port and query ID remain unpredictable, > even if an attacker has knowledge of its (pseudo-)random generator." > > Along the lines of Paul's comment - can the implementer really guarantee > that in any way? I think the MUST in the above can be toned down or > dropped. I anticipated this problem, hence the somewhat odd wording that an implementation "MUST strive". This is like the guaranteeing the pursuit of happiness instead of guaranteeing happiness. I hope the 'MUST strive' formula means we can lambast implementations that don't try hard enough, without mandating them to solve the halting problem. But let me know what you think. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source 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 Sun Jun 29 04:48:08 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377493A6833; Sun, 29 Jun 2008 04:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qven4EVsyH9A; Sun, 29 Jun 2008 04:48:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68BF23A6811; Sun, 29 Jun 2008 04:48:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvK3-000N56-Gg for namedroppers-data@psg.com; Sun, 29 Jun 2008 11:43:59 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvJz-000N4L-QN for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 11:43:57 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KCvJx-0002FW-Lu for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 13:43:53 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id ECE974554; Sun, 29 Jun 2008 13:44:06 +0200 (CEST) Date: Sun, 29 Jun 2008 13:44:06 +0200 From: bert hubert To: Wouter Wijngaards Cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <20080629114406.GB3655@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <200806270307.m5R37eeg039543@ogud.com> <4864B478.7030702@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4864B478.7030702@nlnetlabs.nl> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 27, 2008 at 11:35:52AM +0200, Wouter Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > I reviewed -05 of the forgery resilience draft for WGLC. Thank you! > I think that because the measures are not to cause interoperability in > the DNS but for security enhancement, this draft is a BCP (not standards > track). > > I think the line 'This document updates RFC 1034' should be removed. I > do not think there is any reason. I don't consider myself competent to discuss the nuances of this. > About the case sensitivity idea. I have also implemented that in > unbound, however, the default is turned off. The fall back when no the It has previously been decided to not commingle the case sensitivity tricks with this draft since there are cases where the 0x20-trick appears not to work. > The second formula in section 7.2 has one too many '-' in the dividing > line, otherwise, the ascii art formulas are nicely done. Ah! Fixed, thanks. > running on. I think the current text about port ranges is sort of OK, > but these recommendations may be helpful to other implementors. This paragraph has gone to and fro many times over the past two years. I like to think it has settled down by now. > However, the paragraph: > ~ If a resolver sends out multiple equivalent queries to any > ~ authoritative server, before receiving a response, all MUST have > ~ identical ID, source address and source port. > MUST change to SHOULD. Why? > Please add more text to explain the following: > It is allowed to send multiple queries to an authoritative server before > receiving a response, e.g. due to UDP time outs, but at any time the > server MUST only accept for reception one tuple of ID, source address > and source port. > > So, in order to follow this precisely (and unbound doesn't due to UDP > retry logic), I want this changed so that the resolver is required to > only *listen* to one ID, source addres and source port combination. Understood, and it even makes more sense this way. > bert hubert in the Authors Addresses is missing capitalization. The > header says A. Hubert. And both are true - my initial is A but people call me Bert. I've added caps. Thanks for your review! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source 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 Sun Jun 29 05:08:06 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29CA83A6961; Sun, 29 Jun 2008 05:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.504 X-Spam-Level: X-Spam-Status: No, score=-103.504 tagged_above=-999 required=5 tests=[AWL=2.795, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7NsWMkPb3DP; Sun, 29 Jun 2008 05:08:05 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 57F8F3A693F; Sun, 29 Jun 2008 05:08:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvbt-000PPS-HZ for namedroppers-data@psg.com; Sun, 29 Jun 2008 12:02:25 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvbi-000POQ-Q0 for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 12:02:23 +0000 Received: from Puki.ogud.com (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5TC2A38058224 for ; Sun, 29 Jun 2008 08:02:10 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200806291202.m5TC2A38058224@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 29 Jun 2008 08:00:16 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" In-Reply-To: <20080628071248.GA10892@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <48640EEF.9000506@ca.afilias.info> <20080628071248.GA10892@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: x20 is out-of-scope for this document, please take any discussion on 0x20 (and other additions) to a mail thread that does not contain WGLC in the subject line. thanks Olafur At 03:12 28/06/2008, bert hubert wrote: >On Fri, Jun 27, 2008 at 07:44:41PM +0100, Tony Finch wrote: > > > Has consideration been given on the matching of "Question name", in a > > > case-SENSITIVE manner? > > > > I think the conclusion of Vixie's 0x20 discussion was to keep it separate > > from Bert's draft, because 0x20 introduces interoperability problems > >I would indeed vastly prefer to keep things separate. > > Bert > >-- >http://www.PowerDNS.com Open source, database driven DNS Software >http://netherlabs.nl Open and Closed source 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 Sun Jun 29 05:24:19 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2571E3A67EC; Sun, 29 Jun 2008 05:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOIMOeJXppW5; Sun, 29 Jun 2008 05:24:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C4993A67AE; Sun, 29 Jun 2008 05:24:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvsA-0001Hg-QN for namedroppers-data@psg.com; Sun, 29 Jun 2008 12:19:14 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvs6-0001HH-Sl for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 12:19:13 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 2EBF8C2DA3; Sun, 29 Jun 2008 13:19:04 +0100 (BST) Date: Sun, 29 Jun 2008 13:19:02 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert , Scott Rose cc: "?lafur Gu?mundsson /DNSEXT chair" , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <745AC98387631EFB03DD402C@Ximines.local> In-Reply-To: <20080629114135.GE10892@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <4864FF7B.1020300@nist.gov> <20080629114135.GE10892@outpost.ds9a.nl> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 29 June 2008 13:41:36 +0200 bert hubert wrote: > I anticipated this problem, hence the somewhat odd wording that an > implementation "MUST strive". This is like the guaranteeing the pursuit of > happiness instead of guaranteeing happiness. General comment: I find it difficult to understand the benefit of "MUST strive to do X" over "SHOULD do X". Take two implementations, neither of which do X, and and RFC worded "MUST strive to do X". One could be conformant to the RFC and one not, even though the functionality was identical, on the basis that one implementer tried hard to make his implementation do X, and one didn't try at all. They could even have identical code. I think you either want to go for the simple options ("SHOULD do X" or "MUST do X") or focus on the result you want to achieve rather than an analysis of the effort put in "MUST (maximise|minimise) effect Y". In this case I suggest: > "In case these abilities are enabled, the implementation MUST *ensure* > its choices of source port and query ID remain unpredictable, > even if an attacker has knowledge of both *the algorithm used by the* > implementation including its* (pseudo-)random generator *and > previous wire data*" Clearly if you know both the algorithm and the internal state of a PRNG you can predict its next output. Not knowing the algorithm is insufficient if the algorithm can be guessed from wire data (e.g. an incrementing port). The only reason I can think of toning this down from MUST is because some host systems might not support it. But then the result is the implemented system as a whole is not conformant in that it is not "more resilient against forged answers"; that isn't a disaster, just a reflection of reality. If you really need to tone it down for this reason insert "subject to user configuration or host limitations" or similar. But I think "MUST" is better. 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 Jun 29 05:29:26 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F263A687E; Sun, 29 Jun 2008 05:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFiwS4WON+Tc; Sun, 29 Jun 2008 05:29:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4B093A67EC; Sun, 29 Jun 2008 05:29:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvtK-0001Qi-AW for namedroppers-data@psg.com; Sun, 29 Jun 2008 12:20:26 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCvtG-0001QJ-Jk for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 12:20:24 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id AE97EC2DA3; Sun, 29 Jun 2008 13:20:20 +0100 (BST) Date: Sun, 29 Jun 2008 13:20:18 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Alex Bligh , bert hubert , Scott Rose cc: "?lafur Gu?mundsson /DNSEXT chair" , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: In-Reply-To: <745AC98387631EFB03DD402C@Ximines.local> References: <200806262033.m5QKXJxA036876@ogud.com> <4864FF7B.1020300@nist.gov> <20080629114135.GE10892@outpost.ds9a.nl> <745AC98387631EFB03DD402C@Ximines.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 29 June 2008 13:19:02 +0100 Alex Bligh wrote: > Clearly if you know both the algorithm and the internal state of a > PRNG you can predict its next output. Not knowing the algorithm > is insufficient if the algorithm can be guessed from wire data > (e.g. an incrementing port). I forgot to add that I don't think that change is critical, given this is a WGLC, just a nice-to-have. 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 Jun 29 09:29:12 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5916C3A6881; Sun, 29 Jun 2008 09:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[AWL=1.284, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBaSeQMGFL9d; Sun, 29 Jun 2008 09:29:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF6ED3A6850; Sun, 29 Jun 2008 09:29:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCzeN-000AA9-7O for namedroppers-data@psg.com; Sun, 29 Jun 2008 16:21:15 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCzeJ-000A9j-4q for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 16:21:13 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9B41C11425 for ; Sun, 29 Jun 2008 16:21:05 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: NSEC design question wrt synthesized RCODE 3 (NXDOMAIN) X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 29 Jun 2008 16:21:05 +0000 Message-ID: <48608.1214756465@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: i was largely uninvolved in the discussions which led to the NXT RR, thus my ignorance, and thus this question. why are initiators prohibited from using a cached NSEC to synthesize RCODE 3? here's some context. first, DLV. in DLV, we treat the DLV initiator as a DNS application or consumer, not as a DNS initiator in its own right. therefore a cached NSEC is capable of causing the DLV initiator to suppress certain queries, which in the case of DLV actually means, suppressing most queries. but no RCODE 3 is sent on any wire, so we're within the letter of the prohibition against using a cached NSEC to synthesize an RCODE 3. second, root name service. many responses sent by root name servers are negative, to questions having more than one label (e.g., EXCHANGE.CORPORATE or WWW.INTERNAL.CORPORATE). the resulting RCODE 3 is somehat ambiguous, since it refers to the question name in its entirety, whereas the thing that doesn't exist is the TLD. if we had a way to signal that the TLD doesn't exist, and get that cached, we might be able to avoid some number of future questions at/below that TLD. third, DNSSEC motivation. many have called DNSSEC "a solution searching for its problem" and it's often said that the cost and complexity it demands are unwarranted by the risks it protects against or the benefits it brings. some of us feel that protecting the infrastructure itself would be motive enough, others feel that making it possible for new applications to depend on authenticity from DNS would also be motive enough. so: how cool would it be if signing a zone, including the root zone, allowed one to usefully express the nonexistence of a slice of the namespace larger than the question name, and if turning on validation in a recursive DNS meant a drop in upstream bandwidth due to cached NSEC, in spite of the rise in upstream bandwidth due to all the new cryptoblobs you'd be receiving? thus my question. why do we prohibit the use of a cached NSEC RR for synthesizing RCODE 3 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 Jun 29 09:44:57 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C7A3A690B; Sun, 29 Jun 2008 09:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS5M0Vso3jb9; Sun, 29 Jun 2008 09:44:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C61B3A6850; Sun, 29 Jun 2008 09:44:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCzqT-000BsJ-5x for namedroppers-data@psg.com; Sun, 29 Jun 2008 16:33:45 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCzqP-000Brq-Ja for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 16:33:43 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 42E7E11425; Sun, 29 Jun 2008 16:33:41 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: Scott Rose , ?lafur Gu?mundsson /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" In-Reply-To: Your message of "Sun, 29 Jun 2008 13:41:36 +0200." <20080629114135.GE10892@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <4864FF7B.1020300@nist.gov> <20080629114135.GE10892@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 29 Jun 2008 16:33:41 +0000 Message-ID: <51425.1214757221@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > I anticipated this problem, hence the somewhat odd wording that an > implementation "MUST strive". This is like the guaranteeing the pursuit of > happiness instead of guaranteeing happiness. > > I hope the 'MUST strive' formula means we can lambast implementations that > don't try hard enough, without mandating them to solve the halting problem. > > But let me know what you think. > > Bert i think it's unreasonable to use words like this that don't offer specific guidance. as an implementor, i'd ignore the words, knowing they were a trap so that folks could yell at me no matter what i did, and so, i'd ignore the yelling, too. (remembering that one of the great mass murderers of the first half of the 20th century was convicted only of tax evasion since that's all the authorities could actually prove.) -- to unsubscribe send a message to namedroppers-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 Jun 29 11:47:20 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0E893A6872; Sun, 29 Jun 2008 11:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-VrbOwedLZH; Sun, 29 Jun 2008 11:47:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D0F93A6863; Sun, 29 Jun 2008 11:47:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KD1pd-0006vj-Bz for namedroppers-data@psg.com; Sun, 29 Jun 2008 18:41:01 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KD1pY-0006uv-QO for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 18:40:59 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KD1pT-0001AX-P4 for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 20:40:51 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 41DC04084; Sun, 29 Jun 2008 20:41:05 +0200 (CEST) Date: Sun, 29 Jun 2008 20:41:05 +0200 From: bert hubert To: Alex Bligh Cc: Scott Rose , ?lafur Gu?mundsson /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <20080629184104.GA9944@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <4864FF7B.1020300@nist.gov> <20080629114135.GE10892@outpost.ds9a.nl> <745AC98387631EFB03DD402C@Ximines.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <745AC98387631EFB03DD402C@Ximines.local> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, Jun 29, 2008 at 01:19:02PM +0100, Alex Bligh wrote: > The only reason I can think of toning this down from MUST is > because some host systems might not support it. But then the result > is the implemented system as a whole is not conformant in that it > is not "more resilient against forged answers"; that isn't a The reason it was toned down originally was that it was claimed it is a mathematical impossibility to ensure that a (pseudo-)random generator be unpredictable forever and ever. The only thing one can do is try. But I'm fine with any wording, although I have a soft spot for 'MUST strive'. Perhaps Scott has some guidance - NIST routinely mandates things in this area, perhaps there is some better wording that does not mandate implementors to be able to predict the progress of mathematics for the next 100 years. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source 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 Sun Jun 29 12:51:51 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC0C3A691F; Sun, 29 Jun 2008 12:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmsdyJ9-WKL2; Sun, 29 Jun 2008 12:51:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BBFAC3A68CC; Sun, 29 Jun 2008 12:51:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KD2oO-000GFV-Qg for namedroppers-data@psg.com; Sun, 29 Jun 2008 19:43:48 +0000 Received: from [65.201.175.9] (helo=cliffie.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KD2o2-000GDb-VS for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 19:43:37 +0000 Received: from euphoria.home (pool-71-179-82-149.bltmmd.fios.verizon.net [71.179.82.149]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cliffie.verisignlabs.com (Postfix) with ESMTP id C641D1366D8; Sun, 29 Jun 2008 15:43:25 -0400 (EDT) Cc: namedroppers@ops.ietf.org Message-Id: From: "Blacka, David" To: Paul Vixie In-Reply-To: <48608.1214756465@sa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: NSEC design question wrt synthesized RCODE 3 (NXDOMAIN) Date: Sun, 29 Jun 2008 15:43:25 -0400 References: <48608.1214756465@sa.vix.com> X-Mailer: Apple Mail (2.924) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 29, 2008, at 12:21 PM, Paul Vixie wrote: > i was largely uninvolved in the discussions which led to the NXT RR, > thus > my ignorance, and thus this question. why are initiators prohibited > from > using a cached NSEC to synthesize RCODE 3? here's some context. ... > thus my question. why do we prohibit the use of a cached NSEC RR for > synthesizing RCODE 3 responses? I generally recall discussion of this in the 2002/2003 timeframe. A little research (and I do mean little) yields this as the earliest thread on the subject that I could find: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02127.html but, at that point, the language prohibiting this sort of reuse of NSEC/NXT records was already in the dnssec-bis-protocols draft. One of the dnssec-bis document editors might recall the origins of the language. My personal recollection is that this language exists basically to satisfy the "principle of least surprise". Surprise on the part of the zone operator when a new name added to the zone isn't immediately visible, and surprise on the part of the end user when a name doesn't resolve for them, but it works fine for their neighbor. Also, I think the prohibition has the effect of simplifying the protocol. -- David Blacka Sr. Engineer Platform Product Development -- to unsubscribe send a message to namedroppers-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 Jun 29 12:54:40 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17073A6A23; Sun, 29 Jun 2008 12:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXHFfkXPil5N; Sun, 29 Jun 2008 12:54:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E71E53A6A22; Sun, 29 Jun 2008 12:54:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KD2oU-000GFz-Fg for namedroppers-data@psg.com; Sun, 29 Jun 2008 19:43:54 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KD2oI-000GEw-Dr for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 19:43:44 +0000 Received: from [10.100.96.243] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 8D338C2DA3; Sun, 29 Jun 2008 20:43:38 +0100 (BST) Date: Sun, 29 Jun 2008 20:44:47 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert cc: Scott Rose , "?lafur Gu?mundsson /DNSEXT chair" , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <411C59A066A01E6106DC756B@nimrod.local> In-Reply-To: <20080629184104.GA9944@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <4864FF7B.1020300@nist.gov> <20080629114135.GE10892@outpost.ds9a.nl> <745AC98387631EFB03DD402C@Ximines.local> <20080629184104.GA9944@outpost.ds9a.nl> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 29 June 2008 20:41:05 +0200 bert hubert wrote: > The reason it was toned down originally was that it was claimed it is a > mathematical impossibility to ensure that a (pseudo-)random generator be > unpredictable forever and ever. > > The only thing one can do is try. Well technically that might be accurate, but (I allege) only in the sense that it is mathematically impossible to generate a hash function that is never invertible given enough data and CPU processing power. Indeed many PRNG algorithms are very similar to a truncated hash of the internal state. I really wouldn't worry about this, but if we are going to get pedantic, I have a slightly different concern which is that the problem is not really making the port etc. difficult to predict accurately, but making it difficult to predict. Using a port of 20000 or 20001 randomly is impossible to predict (and conforms to the previous "MUST"), but is all but useless against forged replies. So I suggest: > "In case these abilities are enabled, the implementation MUST > minimise the ability of third parties to guess the implementation's > future choices of source port and query ID remain even where that > third party has knowledge of both the algorithm > used by the implementation including its (pseudo-)random > generator and all previous wire data" 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 Jun 29 14:18:32 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A27DB3A6983; Sun, 29 Jun 2008 14:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TcZI3tjWTBQ; Sun, 29 Jun 2008 14:18:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC8383A6954; Sun, 29 Jun 2008 14:18:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KD4BD-00036p-7d for namedroppers-data@psg.com; Sun, 29 Jun 2008 21:11:27 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KD4B9-000364-3q for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 21:11:24 +0000 Received: from [165.227.249.200] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5TLBHMl055349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jun 2008 14:11:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080629113611.GC10892@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <20080629113611.GC10892@outpost.ds9a.nl> Date: Sun, 29 Jun 2008 14:11:16 -0700 To: bert hubert From: Paul Hoffman Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: There seems to be a basic disconnect in this discussion, and reconnecting it will help us focus. Is this document meant to be a Best Current Practices RFC or a Standards Track RFC? The two have *very* different properties for the section we are discussing. If is meant to be a BCP, we can actually drop the reference to RFC 2119 and dispense with the caps-lock MUST and SHOULD stuff and just say what we mean in the language we think is most appropriate for describing what we think an operator should do if they are doing their "best". If it is meant as a Standards Track RFC, then the RFC 2119 language has a fairly precise meaning. A disinterested third party should be able to examine an implementation and read the RFC and say "this implementation conforms to the RFC" or "this implementation does not conform to the RFC". My comments on this thread were based on reading the bit above the title of the draft which says "Standards Track" and taking that at face value. However, it seems that this is not what others on the list think is the case, or want to be the case. FWIW, it is the WG chairs who determine this, not the WG, although chairs often ask the WG for opinions. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 29 15:58:31 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98AC3A6A49; Sun, 29 Jun 2008 15:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=2.207, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRvRwUyIClcl; Sun, 29 Jun 2008 15:58:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C15893A6A2D; Sun, 29 Jun 2008 15:58:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KD5jZ-000H2J-Ev for namedroppers-data@psg.com; Sun, 29 Jun 2008 22:51:01 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KD5jV-000H1Y-4r for namedroppers@ops.ietf.org; Sun, 29 Jun 2008 22:50:59 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m5TMonn1092506; Mon, 30 Jun 2008 08:50:49 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200806292250.m5TMonn1092506@drugs.dv.isc.org> To: Paul Vixie Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: NSEC design question wrt synthesized RCODE 3 (NXDOMAIN) In-reply-to: Your message of "Sun, 29 Jun 2008 16:21:05 GMT." <48608.1214756465@sa.vix.com> Date: Mon, 30 Jun 2008 08:50:49 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > i was largely uninvolved in the discussions which led to the NXT RR, thus > my ignorance, and thus this question. why are initiators prohibited from > using a cached NSEC to synthesize RCODE 3? here's some context. Conservitism. There isn't a technical reason. Just a fear that it would be badly implemented. > first, DLV. > > in DLV, we treat the DLV initiator as a DNS application or consumer, not > as a DNS initiator in its own right. therefore a cached NSEC is capable > of causing the DLV initiator to suppress certain queries, which in the case > of DLV actually means, suppressing most queries. but no RCODE 3 is sent > on any wire, so we're within the letter of the prohibition against using > a cached NSEC to synthesize an RCODE 3. > > second, root name service. > > many responses sent by root name servers are negative, to questions having > more than one label (e.g., EXCHANGE.CORPORATE or WWW.INTERNAL.CORPORATE). > the resulting RCODE 3 is somehat ambiguous, since it refers to the question > name in its entirety, whereas the thing that doesn't exist is the TLD. if > we had a way to signal that the TLD doesn't exist, and get that cached, we > might be able to avoid some number of future questions at/below that TLD. > > third, DNSSEC motivation. > > many have called DNSSEC "a solution searching for its problem" and it's often > said that the cost and complexity it demands are unwarranted by the risks it > protects against or the benefits it brings. some of us feel that protecting > the infrastructure itself would be motive enough, others feel that making it > possible for new applications to depend on authenticity from DNS would also > be motive enough. > > so: > > how cool would it be if signing a zone, including the root zone, allowed one to usefully express the nonexistence of a slice of the namespace larger > than the question name, and if turning on validation in a recursive DNS meant > a drop in upstream bandwidth due to cached NSEC, in spite of the rise in > upstream bandwidth due to all the new cryptoblobs you'd be receiving? > > thus my question. why do we prohibit the use of a cached NSEC RR for > synthesizing RCODE 3 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: -- 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 Mon Jun 30 02:40:28 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74733A6AAA; Mon, 30 Jun 2008 02:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAunlcDRc29c; Mon, 30 Jun 2008 02:40:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 09CA23A67FB; Mon, 30 Jun 2008 02:40:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDFiI-0005qD-56 for namedroppers-data@psg.com; Mon, 30 Jun 2008 09:30:22 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDFiB-0005ox-8h for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 09:30:17 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id E2FA53A6A57; Mon, 30 Jun 2008 02:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D Action:draft-ietf-dnsext-tsig-md5-deprecated-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080630093001.E2FA53A6A57@core3.amsl.com> Date: Mon, 30 Jun 2008 02:30:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --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 : Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records Author(s) : F. Dupont Filename : draft-ietf-dnsext-tsig-md5-deprecated-00.txt Pages : 6 Date : 2008-06-30 The main goal of this document is to deprecate the use of HMAC-MD5 as an algorithm for the TSIG (secret key transaction authentication) resource record in the DNS (domain name system). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-md5-deprecated-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dnsext-tsig-md5-deprecated-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-30022804.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 30 06:05:12 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B851E3A67F5; Mon, 30 Jun 2008 06:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S60dEJwTxcKy; Mon, 30 Jun 2008 06:05:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C66EA3A67A8; Mon, 30 Jun 2008 06:05:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDIum-000GMk-Om for namedroppers-data@psg.com; Mon, 30 Jun 2008 12:55:28 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDIud-000GL2-Ku for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 12:55:25 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5UCtARx028305; Mon, 30 Jun 2008 08:55:11 -0400 Message-ID: <4868D7AE.4060701@nist.gov> Date: Mon, 30 Jun 2008 08:55:10 -0400 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: bert hubert CC: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" References: <200806262033.m5QKXJxA036876@ogud.com> <4864FF7B.1020300@nist.gov> <20080629114135.GE10892@outpost.ds9a.nl> <745AC98387631EFB03DD402C@Ximines.local> <20080629184104.GA9944@outpost.ds9a.nl> In-Reply-To: <20080629184104.GA9944@outpost.ds9a.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bert hubert wrote: > On Sun, Jun 29, 2008 at 01:19:02PM +0100, Alex Bligh wrote: >> The only reason I can think of toning this down from MUST is >> because some host systems might not support it. But then the result >> is the implemented system as a whole is not conformant in that it >> is not "more resilient against forged answers"; that isn't a > > The reason it was toned down originally was that it was claimed it is a > mathematical impossibility to ensure that a (pseudo-)random generator be > unpredictable forever and ever. > > The only thing one can do is try. > > But I'm fine with any wording, although I have a soft spot for 'MUST > strive'. > > Perhaps Scott has some guidance - NIST routinely mandates things in this > area, perhaps there is some better wording that does not mandate > implementors to be able to predict the progress of mathematics for the next > 100 years. > There isn't much in the way of guidance for application developers other than "make sure you can (and do) use an approved PRNG". A list of approved algorithms is on the NIST site and implementations are validated via the NIST Cryptographic Algorithm Validation Program: http://csrc.nist.gov/groups/STM/cavp/ NIST tends to give guidance/recommendations on the crypto algorithm development side, then say implements "Shall" (as in "must comply with the regulation") use a library that has been validated. NIST doesn't put the burden on the application developer to do anything more than properly use the approved crypto library. So the phrase "MUST strive" could still be included (or "SHOULD strive") with text indicating that it should be interpreted to mean the implementor should properly use the PRNG. Scott > Bert > -- ---------------------------------------- Scott Rose Computer Scientist NIST ph: +1 301-975-8439 scott.rose@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Jun 30 08:02:16 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4300A3A69BF; Mon, 30 Jun 2008 08:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrhZbeNcUbGe; Mon, 30 Jun 2008 08:02:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C9C63A6932; Mon, 30 Jun 2008 08:02:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDKmH-000AFq-4f for namedroppers-data@psg.com; Mon, 30 Jun 2008 14:54:49 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDKm7-000AD5-Py for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 14:54:46 +0000 Received: from commandprompt.com (227-54-222-209.mycybernet.net [209.222.54.227]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m5UEuX9b025567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Jun 2008 07:56:40 -0700 Date: Mon, 30 Jun 2008 10:54:31 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Intended status (Was: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") Message-ID: <20080630145430.GG35169@commandprompt.com> References: <200806262033.m5QKXJxA036876@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200806262033.m5QKXJxA036876@ogud.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Mon, 30 Jun 2008 07:56:41 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, On Thu, Jun 26, 2008 at 04:33:14PM -0400, Ólafur Guðmundsson /DNSEXT chair wrote: > The document process rules in this group, require that at least > 5 members of the working to state that they have read the document > and there is consensus of support to publish as an Standards Track RFC. Just to be clear, we are requesting that the document be considered for adoption as a standards track RFC. Therefore, if you think the draft needs fixing to address its suitability for the standards track, those comments are on-topic. Similarly, if you have read and do not support the document as a standards track RFC, you should say so. And finally, of course, if you have read the document and think it should be a standards track RFC, say that too. But we'd like to avoid a debate about whether it ought to be on the standards track, and we'd like to avoid discussing how the document should be altered so that it would be appropriate for some other intended status. For what it's worth, our reasoning for putting this on the standards track is that the requirement in section 9 that resolvers be capable of using multiple source ports at once is arguably a new requirement, and could have interoperation effects. This is also the basis for the note of what RFCs the I-D will update if approved. Best regards, Olafur & Andrew -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- to unsubscribe send a message to namedroppers-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 Jun 30 08:12:47 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE06F3A68F7; Mon, 30 Jun 2008 08:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIzm4e+vDhar; Mon, 30 Jun 2008 08:12:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D5E33A6986; Mon, 30 Jun 2008 08:12:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDKxt-000CKz-Th for namedroppers-data@psg.com; Mon, 30 Jun 2008 15:06:49 +0000 Received: from [69.17.117.9] (helo=mail7.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDKxm-000CJe-MY for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 15:06:44 +0000 Received: (qmail 195 invoked from network); 30 Jun 2008 15:06:42 -0000 Received: from unknown (HELO [164.99.130.39]) (federico@[130.57.22.201]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 30 Jun 2008 15:06:42 -0000 Message-ID: <4868F721.1050809@ximian.com> Date: Mon, 30 Jun 2008 11:09:21 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: bert hubert CC: namedroppers@ops.ietf.org Subject: Re: new draft of Forgery Resilience posted - summary of changes References: <20080623175938.GA9771@outpost.ds9a.nl> <20080626144644.GD19608@outpost.ds9a.nl> In-Reply-To: <20080626144644.GD19608@outpost.ds9a.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Helo Bert, I had not seen the drafts since I gave feedback on v2 - the document has progressed very nicely, nice work! I have a couple of questions: In 8, where it is noted that spoofing can be noticed by a watchful operator, I would think the resolver should watch as well. Maybe keeping track of all the IPs the resolver is getting messages from is too serious overhead, but noticing repeated discarded responses (thousands of them) to the same query, should only require a single integer... or am I missing something ? It looks like 9 is going there where it says "if a resolver detects an attempt is being made to spoof it...", but then the dropping UPD for a TCP query is only under MAY. I can see reasons for this not being a MUST, but how about a SHOULD? Is there a reason to have that option so weakly worded? At the risk of sounding like a DJB fan, has it been considered to give a requirement level to source port randomization (SHOULD) ? Best -Federico bert hubert wrote: > Hi everybody, > > I've just posted version -05 of the Forgery Resilience draft. It has > appeared on > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-05.txt > > Compared to -04: > > * An IANA section has been added (asking IANA to do nothing) > * A reference to RFC 2401 has been replaced by a reference to 4301 > (its successor) > * Typos (scnearios, reponses, acknowledgements, ountermeasures) were > fixed > * A tighter description of attacks by third parties that can see your > packets was added > * Added wording that cryptograpical security mechanisms protect > against more attacks > > Based on feedback so far, and the final small tweaks found in -05, I kindly > request that a WG last call be initiated. > > Kind regards, > > bert hubert > -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - flucifredi@ximian.com -- to unsubscribe send a message to namedroppers-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 Jun 30 08:40:27 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9055D3A6A1A; Mon, 30 Jun 2008 08:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiJP+5e3I5eK; Mon, 30 Jun 2008 08:40:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B8DA3A68EA; Mon, 30 Jun 2008 08:40:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDLPE-000I1g-C9 for namedroppers-data@psg.com; Mon, 30 Jun 2008 15:35:04 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDLP7-000I0H-L4 for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 15:35:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 535941143A; Mon, 30 Jun 2008 15:34:52 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Andrew Sullivan cc: namedroppers@ops.ietf.org Subject: Re: Intended status (Was: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") In-Reply-To: Your message of "Mon, 30 Jun 2008 10:54:31 -0400." <20080630145430.GG35169@commandprompt.com> References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 30 Jun 2008 15:34:52 +0000 Message-ID: <6218.1214840092@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > The document process rules in this group, require that at least > > 5 members of the working to state that they have read the document > > and there is consensus of support to publish as an Standards Track RFC. > > Just to be clear, we are requesting that the document be considered > for adoption as a standards track RFC. Therefore, if you think the > draft needs fixing to address its suitability for the standards track, > those comments are on-topic. ... i think it needs fixing along the lines of what wouter said, and to remove any mention of upper/lower case comparisons of question name, but other than that i am in favour of progressing this draft. > ... > For what it's worth, our reasoning for putting this on the standards > track is that the requirement in section 9 that resolvers be capable > of using multiple source ports at once is arguably a new requirement, > and could have interoperation effects. This is also the basis for the > note of what RFCs the I-D will update if approved. this is going to be controversial some day. use of multiple source ports is one known defense for one known class of spoofing attack. there may be other defenses some day, and there may be other classes of spoofing attack. making multiple source ports a requirement isn't in the right spirit. requirements should be written in terms of results not methods. it's fine to require that dns transactions be protected against spoofing by an equivilent of 30 bits of randomness (16 in the QID, 14 or so in the UDP port) but if someone wants to implement that with 14 in the QID, 10 in the UDP port, 3 in the 0x20 bits (if that bill ever becomes a law) and 3 in the IP source (using a brace of 8 IP addresses), or if someone wants to randomize the IP destination (rather than using RTT sorting or any other semi-deterministic selection criteria) to get one or two bits of randomness, this RFC should permit the other approaches. likewise if SIG(0) is used, or TSIG, or some new protocol feature that gives a 30 (or 32 or 128 or whatever) bit QID. or IPSEC tunnels with out of band authentication data. if this is going to be on the standards track, then section 9 will have to be genericised and put in terms of requirements not methodologies. if it's going to be a BCP then it's fine like it is now. -- to unsubscribe send a message to namedroppers-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 Jun 30 08:45:39 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A193A6932; Mon, 30 Jun 2008 08:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.959 X-Spam-Level: X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFS9jNHZeFBk; Mon, 30 Jun 2008 08:45:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4BEAA3A6AB6; Mon, 30 Jun 2008 08:45:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDLTK-000If0-Vs for namedroppers-data@psg.com; Mon, 30 Jun 2008 15:39:18 +0000 Received: from [207.219.45.62] (helo=vgateway.libertyrms.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDLTD-000Ie5-Er for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 15:39:13 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by vgateway.libertyrms.info with esmtp (Exim 4.22) id 1KDLTC-0000D5-Jj; Mon, 30 Jun 2008 11:39:10 -0400 Message-ID: <4868FE13.1070805@ca.afilias.info> Date: Mon, 30 Jun 2008 11:38:59 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: Intended status (Was: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> In-Reply-To: <20080630145430.GG35169@commandprompt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew Sullivan wrote: > Dear colleagues, > > On Thu, Jun 26, 2008 at 04:33:14PM -0400, Ólafur Guðmundsson /DNSEXT chair wrote: > > >> The document process rules in this group, require that at least >> 5 members of the working to state that they have read the document >> and there is consensus of support to publish as an Standards Track RFC. >> > > Just to be clear, we are requesting that the document be considered > for adoption as a standards track RFC. Therefore, if you think the > draft needs fixing to address its suitability for the standards track, > those comments are on-topic. Similarly, if you have read and do not > support the document as a standards track RFC, you should say so. And > finally, of course, if you have read the document and think it should > be a standards track RFC, say that too. I have read the document. I think it should be a standards track RFC. I think it needs a minor fix to clarify the "compare the question section of the reply" as far as case-sensitivity is concerned. Here's what I think needs to be clarified: A response is valid if the question section matches in a case-insensitive fashion but not in a case-sensitive fashion. A response is also valid if the question section matches in a case-sensitive fashion. Clearly, an implementation would be compliant with the ID (and other RFCs) if the comparison is done in a case-insensitive fashion. What needs to be clarified is that: An implementation *may* do additional forgery-resilience stuff involving case-sensitivity, so long as it does not strictly require case-sensitive matching. I.e. that a response which matches case-insensitively but not case-sensitively, that is not forged, is not permanently rejected. Furthermore, it should be clear that this additional checking (case sensitivity) is *strictly* optional, and matching case-insensitively would be completely conforming. I recognize that careful choice of words may be needed to convey this. However, I think it is important to ensure that even prior to 0x20, that implementers may begin putting in hooks for it, without running afoul (or even appearing to run afoul of) forgery-resilience. I believe everyone reading this list understands this already - it is important, however, that the sentiment of the WG be reflected in the ID, so that those who don't read anything but the RFCs, "get it". Brian Dickson -- to unsubscribe send a message to namedroppers-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 Jun 30 08:48:35 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50DC23A688F; Mon, 30 Jun 2008 08:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu1ERjcCaNjg; Mon, 30 Jun 2008 08:48:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2CE783A684E; Mon, 30 Jun 2008 08:48:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDLW9-000JEB-L5 for namedroppers-data@psg.com; Mon, 30 Jun 2008 15:42:13 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDLW4-000JDO-UX for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 15:42:10 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 947E51143B; Mon, 30 Jun 2008 15:42:08 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Federico Lucifredi cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: new draft of Forgery Resilience posted - summary of changes In-Reply-To: Your message of "Mon, 30 Jun 2008 11:09:21 -0400." <4868F721.1050809@ximian.com> References: <20080623175938.GA9771@outpost.ds9a.nl> <20080626144644.GD19608@outpost.ds9a.nl> <4868F721.1050809@ximian.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 30 Jun 2008 15:42:08 +0000 Message-ID: <6454.1214840528@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > In 8, where it is noted that spoofing can be noticed by a watchful > operator, I would think the resolver should watch as well. Maybe keeping > track of all the IPs the resolver is getting messages from is too serious > overhead, but noticing repeated discarded responses (thousands of them) to > the same query, should only require a single integer... or am I missing > something ? how many single integers would we keep, as a quota matter? if it's 10000 then we can expect attackers to spoof us in a way that churns through all 10000 buckets rapidly enough that no bucket ever gets old enough to count the real attacks. (i don't know if this means you're missing something, but this approach has already been considered and found unacceptable by several of us here.) > It looks like 9 is going there where it says "if a resolver detects an > attempt is being made to spoof it...", but then the dropping UPD for a TCP > query is only under MAY. I can see reasons for this not being a MUST, but > how about a SHOULD? Is there a reason to have that option so weakly worded? this document should make observations, propose some alternatives, and maybe recommend things, but if at all possible, not extend the DNS protocol by requiring certain specific actions when certain on-wire patterns are seen. > At the risk of sounding like a DJB fan, has it been considered to give a > requirement level to source port randomization (SHOULD) ? even those of us who are not DJB fans know that UDP source port randomization is a good idea, and i for one wish that i had listened to DJB about this when he first proposed 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 Mon Jun 30 09:01:45 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A262C3A6A41; Mon, 30 Jun 2008 09:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWPGVzcaFH9k; Mon, 30 Jun 2008 09:01:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47D4B3A684E; Mon, 30 Jun 2008 09:01:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDLiU-000LQg-HB for namedroppers-data@psg.com; Mon, 30 Jun 2008 15:54:58 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDLiK-000LPF-0t for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 15:54:56 +0000 Received: from commandprompt.com (227-54-222-209.mycybernet.net [209.222.54.227]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m5UFujTl028226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Jun 2008 08:56:49 -0700 Date: Mon, 30 Jun 2008 11:54:43 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Intended status (Was: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") Message-ID: <20080630155443.GB51849@commandprompt.com> References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> <6218.1214840092@sa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6218.1214840092@sa.vix.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Mon, 30 Jun 2008 08:56:49 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 30, 2008 at 03:34:52PM +0000, Paul Vixie wrote: > i think it needs fixing along the lines of what wouter said, and to remove > any mention of upper/lower case comparisons of question name, but other than > that i am in favour of progressing this draft. … > if this is going to be on the standards track, then section 9 will have to be > genericised and put in terms of requirements not methodologies. if it's going > to be a BCP then it's fine like it is now. Since the request is about the document as a candidate for the standards track, if you have ways you think it needs to be fixed, sending replacement text will be a big help. Best regards, Andrew -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- to unsubscribe send a message to namedroppers-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 Jun 30 09:03:53 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6A63A685D; Mon, 30 Jun 2008 09:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh8bbNJYadYM; Mon, 30 Jun 2008 09:03:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E4863A6A1A; Mon, 30 Jun 2008 09:03:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDLkl-000Lrj-Rl for namedroppers-data@psg.com; Mon, 30 Jun 2008 15:57:19 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDLke-000Lqd-MD for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 15:57:14 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5UFvAVV039532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Jun 2008 08:57:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080630093001.E2FA53A6A57@core3.amsl.com> References: <20080630093001.E2FA53A6A57@core3.amsl.com> Date: Mon, 30 Jun 2008 08:56:16 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Greetings again. The logic in this document is kind of a mess. It says, in essence: a) MD5 turns out to be weaker than expected for a hash b) therefore it should be deprecated and HMAC-SHA1 be mandatory The first statement is certainly true, but irrelevant, because TSIG uses HMAC-MD5, not MD5. As the draft admits, there are no known attacks on HMAC-MD5. To the best of my knowledge, there have been no papers published even hinting at it. The second statement is short-sighted. The document talks about the desire to have algorithms that can be used in systems that are validated with FIPS 140 for NIST in the US. However, NIST has already said that SHA-1 will be deprecated in about 2.5 years; see . So making SHA-1 mandatory based on wanting to use FIPS algorithms is also not a good idea. Getting rid of TSIG-HMAC-MD5 for NIST-related reasons would also require us to get rid of TSIG-HMAC-SHA1, either now or in 2.5 years from now. If the only reason for this draft to exist is to deprecate TSIG-HMAC-MD5, then it seems like vast overkill. Instead, a better idea is a simple one-page draft that takes TSIG-HMAC-MD5 from mandatory to optional. That draft doesn't need any questionable cryptography or discussion of NIST. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 30 09:56:59 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C63B3A69BD; Mon, 30 Jun 2008 09:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4xFwJR+l1+N; Mon, 30 Jun 2008 09:56:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E6D63A63EC; Mon, 30 Jun 2008 09:56:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDMWY-0003ol-EB for namedroppers-data@psg.com; Mon, 30 Jun 2008 16:46:42 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDMWU-0003nz-BU for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 16:46:40 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 10E9411437; Mon, 30 Jun 2008 16:46:33 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Andrew Sullivan cc: namedroppers@ops.ietf.org Subject: Re: Intended status (Was: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") In-Reply-To: Your message of "Mon, 30 Jun 2008 11:54:43 -0400." <20080630155443.GB51849@commandprompt.com> References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> <6218.1214840092@sa.vix.com> <20080630155443.GB51849@commandprompt.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 30 Jun 2008 16:46:33 +0000 Message-ID: <8896.1214844393@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Since the request is about the document as a candidate for the > standards track, if you have ways you think it needs to be fixed, > sending replacement text will be a big help. can i first see the current text, since there have been a lot of proposed edits here in the last few days since a draft was pub'd. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 30 10:13:21 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0893A63EC; Mon, 30 Jun 2008 10:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMFa9ezgbRxH; Mon, 30 Jun 2008 10:13:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D4CF53A67F4; Mon, 30 Jun 2008 10:13:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDMqb-0007jX-1Y for namedroppers-data@psg.com; Mon, 30 Jun 2008 17:07:25 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDMqQ-0007hh-NR for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 17:07:20 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5UH770o026237 for ; Mon, 30 Jun 2008 13:07:08 -0400 Message-ID: <486912BB.9030300@nist.gov> Date: Mon, 30 Jun 2008 13:07:07 -0400 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt References: <20080630093001.E2FA53A6A57@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Hoffman wrote: > Greetings again. The logic in this document is kind of a mess. It says, > in essence: > > a) MD5 turns out to be weaker than expected for a hash > > b) therefore it should be deprecated and HMAC-SHA1 be mandatory > > The first statement is certainly true, but irrelevant, because TSIG uses > HMAC-MD5, not MD5. As the draft admits, there are no known attacks on > HMAC-MD5. To the best of my knowledge, there have been no papers > published even hinting at it. > > The second statement is short-sighted. The document talks about the > desire to have algorithms that can be used in systems that are validated > with FIPS 140 for NIST in the US. However, NIST has already said that > SHA-1 will be deprecated in about 2.5 years; see > . So making SHA-1 > mandatory based on wanting to use FIPS algorithms is also not a good > idea. Getting rid of TSIG-HMAC-MD5 for NIST-related reasons would also > require us to get rid of TSIG-HMAC-SHA1, either now or in 2.5 years from > now. > SHA-1 is to be deprecated by 2010, but that doesn't include HMAC-SHA1, which can continue beyond 2010 if used with an appropriately long secret string. I don't know if that extends back to HMA-MD5, but I do know HMAC-SHA1 is still allowed for use within the USG after 2010 or until a known attack is discovered. > If the only reason for this draft to exist is to deprecate > TSIG-HMAC-MD5, then it seems like vast overkill. Instead, a better idea > is a simple one-page draft that takes TSIG-HMAC-MD5 from mandatory to > optional. That draft doesn't need any questionable cryptography or > discussion of NIST. > I agree with the last part. I could also live with moving HMAC-MD5 to optional. It is up to the parties involved to decide with algorithm to use anyway. Scott > --Paul Hoffman, Director > --VPN Consortium > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- ---------------------------------------- Scott Rose Computer Scientist NIST ph: +1 301-975-8439 scott.rose@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Jun 30 10:19:28 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E7B3A6AB7; Mon, 30 Jun 2008 10:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwTQYdaAHpeK; Mon, 30 Jun 2008 10:19:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 09A353A6919; Mon, 30 Jun 2008 10:19:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDMu7-0008VQ-JE for namedroppers-data@psg.com; Mon, 30 Jun 2008 17:11:03 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDMtw-0008T8-5R for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 17:11:00 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KDMtt-0001qq-BB; Mon, 30 Jun 2008 19:10:49 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 8D27A4570; Mon, 30 Jun 2008 19:11:01 +0200 (CEST) Date: Mon, 30 Jun 2008 19:11:01 +0200 From: bert hubert To: Paul Vixie Cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: Intended status (Was: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") Message-ID: <20080630171101.GE31211@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> <6218.1214840092@sa.vix.com> <20080630155443.GB51849@commandprompt.com> <8896.1214844393@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8896.1214844393@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 30, 2008 at 04:46:33PM +0000, Paul Vixie wrote: > can i first see the current text, since there have been a lot of > proposed edits here in the last few days since a draft was pub'd. Sure - the latest version in XML can always be read on http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/browser/trunk/draft-ietf-dnsext-forgery-resilience.xml It can be converted using http://xml.resource.org/ I've put the up to the minute text version on http://ds9a.nl/tmp/draft-ietf-dnsext-forgery-resilience.txt Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source 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 Jun 30 11:30:31 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9710E3A6A53; Mon, 30 Jun 2008 11:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoywt4EGxiNF; Mon, 30 Jun 2008 11:30:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E7A23A69C0; Mon, 30 Jun 2008 11:30:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDO1V-000LRU-0E for namedroppers-data@psg.com; Mon, 30 Jun 2008 18:22:45 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDO1P-000LQQ-CQ for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 18:22:41 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DE35E11432; Mon, 30 Jun 2008 18:22:33 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: Intended status (Was: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") In-Reply-To: Your message of "Mon, 30 Jun 2008 19:11:01 +0200." <20080630171101.GE31211@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> <6218.1214840092@sa.vix.com> <20080630155443.GB51849@commandprompt.com> <8896.1214844393@sa.vix.com> <20080630171101.GE31211@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 30 Jun 2008 18:22:33 +0000 Message-ID: <12278.1214850153@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > can i first see the current text, since there have been a lot of > > proposed edits here in the last few days since a draft was pub'd. > > I've put the up to the minute text version on > http://ds9a.nl/tmp/draft-ietf-dnsext-forgery-resilience.txt +--- | Updates: 1034 (if approved) +--- strike this, unless you can cite chapter and verse of what's being changed. (just because it's on the standards track doesn't mean it automatically updates 1034, you have to say what changes you're making, which i don't see.) merely amending the specification with new rules does not automatically update 1034 or 1035. (some day there will be an RFC which is automatically updated by any DNS protocol amendment, but right now there isn't one.) +--- | 9. Countermeasures ... | o Destination address agaist query source address +--- s/agaist/against/ +--- ... | Resolver implementations MUST have the ability to: | | o Use an unpredictable source port for outgoing queries from the | range (53, or > 1024) of available ports that is as large as | possible and practicable; | | o Use multiple different source ports simultaneously in case of | multiple outstanding queries; | | o Use an unpredictable query ID for outgoing queries, utilizing the | full range available (0-65535) +--- here's the rub. maybe try this: Full DNS resolvers MUST defend themselves against IP spoofing as follows: o Exposed transaction identity markers such as UDP source port or DNS ID must be unpredictable by any trivial observation (so, constants are outlawed, as are simple increments; and, any random number generator used should be crypto-strength.) o A minimum of 30 bits of transaction identity must be expressed and compared, either using 16 bits of QID plus 14 bits of UDP source port, or an equivilent amount expressed some other way (for example, using multiple IP source addresses, or similar.) o Use more than one IP/UDP endpoint simultaneously, in the case of multiple outstanding upstream queries. Any combination of multiple IP source addresses and multiple UDP port numbers is acceptable, as long as the number of combinations is nontrivial. Discussion: Since an attacker can force a full DNS resolver to send queries to the attacker's own name servers, any constant or sequential state held by such a resolver can be measured, and it must not be trivially easy to reverse engineer the resolver's internal state in a way that allows low-cost high-accuracy prediction of future state. A full DNS resolver with only one or a small number of upstream- facing endpoints is effectively using constants for IP source address and UDP port number, and these are very predictable by potential attackers, and must therefore be avoided. A full DNS resolver who uses a simple increment to get its next DNS ID is likewise very predictable and so very spoofable. Finally, weak random number generators have been shown to expose their internal state, such that an attacker who witnesses several sequential "random" values can easily predict the next ones. A crypto-strength random number generator is one whose output cannot be predicted no matter how many successive values are witnessed. +--- | Please note that source ports could be selected from a larger range | than indicated, but that this range is regarded as safe, with some | lower port numbers reserved for activities which might conflict with | proper DNS operation. | | In case these abilities are enabled, the implementation MUST strive | to have its choices of source port and query ID remain unpredictable, | even if an attacker has knowledge of the implementation of its | (pseudo-)random generator. This can be achieved by seeding an | algorithm with a secret state. | | If a resolver is multihomed or otherwise has the ability to transmit | and receive datagrams using more than one IP source address, then an | IP address can be chosen at random in order to increase an attacker's | difficulty in guessing what address to flood. | | If a resolver sends out multiple equivalent queries to any | authoritative server, at any time only one ID, source address and | source port combination MUST be acceptable as the correct answer. | | In case a cryptographic verification of response authenticity is | available, resolver implementations MAY waive above rules, and rely | on this guarantee instead. | | Resolvers MUST favour authoritative nameservers with which a trust | relation has been established; Stub-resolvers SHOULD be able to use | TSIG ([RFC2845]) or IPSEC ([RFC4301]) when communicating with their | recursive resolver, if these services are available. | | Proper unpredictability can be achieved by employing a high quality | (pseudo-)random generator, as described in [RFC4086]. | | If a resolver detects that an attempt is being made to spoof it, | perhaps by discovering that many packets fail the criteria as | outlined above, it MAY abandon the UDP query and re-issue it over | TCP. TCP, by the nature of its use of sequence numbers, is far more | resilient against forgery by third parties. +--- i'd axe all of this text. -- to unsubscribe send a message to namedroppers-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 Jun 30 11:31:48 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B99EC3A6A53; Mon, 30 Jun 2008 11:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5F2iZ6N1Irk; Mon, 30 Jun 2008 11:31:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D688C3A682E; Mon, 30 Jun 2008 11:31:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDO6U-000MLw-La for namedroppers-data@psg.com; Mon, 30 Jun 2008 18:27:54 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDO6Q-000MLE-Q3 for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 18:27:52 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 852691142F; Mon, 30 Jun 2008 18:27:50 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Federico Lucifredi cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: new draft of Forgery Resilience posted - summary of changes In-Reply-To: Your message of "Mon, 30 Jun 2008 14:13:30 -0400." <4869224A.2070209@post.harvard.edu> References: <20080623175938.GA9771@outpost.ds9a.nl> <20080626144644.GD19608@outpost.ds9a.nl> <4868F721.1050809@ximian.com> <6454.1214840528@sa.vix.com> <4869224A.2070209@post.harvard.edu> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 30 Jun 2008 18:27:50 +0000 Message-ID: <12518.1214850470@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > One integer per outstanding query that we are expecting a response for ? you think an attacker can't run that number up to 10001 or your quota+1? -- to unsubscribe send a message to namedroppers-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 Jun 30 11:48:31 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83103A68FC; Mon, 30 Jun 2008 11:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sinjvqhIGHOa; Mon, 30 Jun 2008 11:48:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF6EF3A679C; Mon, 30 Jun 2008 11:48:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDOKZ-000Oi2-75 for namedroppers-data@psg.com; Mon, 30 Jun 2008 18:42:27 +0000 Received: from [69.17.117.3] (helo=mail1.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDOKU-000Ogy-Ig for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 18:42:24 +0000 Received: (qmail 24186 invoked from network); 30 Jun 2008 18:42:22 -0000 Received: from unknown (HELO [164.99.130.39]) (federico@[130.57.22.201]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 30 Jun 2008 18:42:22 -0000 Message-ID: <486929AD.5050905@ximian.com> Date: Mon, 30 Jun 2008 14:45:01 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Paul Vixie CC: bert hubert , namedroppers@ops.ietf.org Subject: Re: new draft of Forgery Resilience posted - summary of changes References: <20080623175938.GA9771@outpost.ds9a.nl> <20080626144644.GD19608@outpost.ds9a.nl> <4868F721.1050809@ximian.com> <6454.1214840528@sa.vix.com> <4869224A.2070209@post.harvard.edu> <12518.1214850470@sa.vix.com> In-Reply-To: <12518.1214850470@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: >> One integer per outstanding query that we are expecting a response for ? > > you think an attacker can't run that number up to 10001 or your quota+1? Oops. I think I tried to condense my thinking too much. I agree, if we were trying to run counters per-IP, no matter how many the buckets, the attacker would be able to exceed it. But if we are keeping a _single_ counter, per each outstanding query we expect a response for, indicating the number of discarded responses to this query we have seen, the load is O(n) - one integer per query we have outstanding. I imagine a resolver needs to keep a few hundred bytes of state about each query it is expecting responses for, adding 1 integer to each seems little harm - and it would allow the responder to switch to TCP behavior once a certain threshold is exceeded. Best -F -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - flucifredi@ximian.com -- to unsubscribe send a message to namedroppers-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 Jun 30 11:50:28 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25463A699C; Mon, 30 Jun 2008 11:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltyvQaa9aN4E; Mon, 30 Jun 2008 11:50:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2193A3A6936; Mon, 30 Jun 2008 11:50:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDOKt-000Okw-AU for namedroppers-data@psg.com; Mon, 30 Jun 2008 18:42:47 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDOKo-000OkN-K4 for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 18:42:45 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5UIge2q056573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Jun 2008 11:42:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080630171101.GE31211@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> <6218.1214840092@sa.vix.com> <20080630155443.GB51849@commandprompt.com> <8896.1214844393@sa.vix.com> <20080630171101.GE31211@outpost.ds9a.nl> Date: Mon, 30 Jun 2008 11:42:39 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: Intended status (Was: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Given that we have cleared up the status, I reiterate my objection to: Resolver implementations MUST have the ability to: That is too weak. There has been no arguments showing why using the three mechanisms listed would be harmful, nor that they are impossible. Why have this document on standards track if we are just suggesting that nice resolvers might do something? --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-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 Jun 30 11:57:47 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAFEE3A6932; Mon, 30 Jun 2008 11:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.892 X-Spam-Level: X-Spam-Status: No, score=-100.892 tagged_above=-999 required=5 tests=[AWL=1.357, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bz2zu4XBJbO; Mon, 30 Jun 2008 11:57:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E63853A6896; Mon, 30 Jun 2008 11:57:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDOU4-0000Ur-It for namedroppers-data@psg.com; Mon, 30 Jun 2008 18:52:16 +0000 Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDOTz-0000Sw-QG for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 18:52:14 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1KDOTs-0002MN-BC; Mon, 30 Jun 2008 20:52:04 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1KDOTr-00015s-RX; Mon, 30 Jun 2008 20:52:03 +0200 From: Florian Weimer To: Paul Vixie Cc: bert hubert , Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: Intended status References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> <6218.1214840092@sa.vix.com> <20080630155443.GB51849@commandprompt.com> <8896.1214844393@sa.vix.com> <20080630171101.GE31211@outpost.ds9a.nl> <12278.1214850153@sa.vix.com> Date: Mon, 30 Jun 2008 20:52:03 +0200 In-Reply-To: <12278.1214850153@sa.vix.com> (Paul Vixie's message of "Mon, 30 Jun 2008 18:22:33 +0000") Message-ID: <87od5ioiwc.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Vixie: > strike this, unless you can cite chapter and verse of what's being changed. > (just because it's on the standards track doesn't mean it automatically > updates 1034, you have to say what changes you're making, which i don't see.) For interoperability reasons, TCP fallback when a potential blind spoofing situation is detected requires an update RFC 1123, but this is subject to interpretation (as was discussed before). (TCP fallback with TC=0 is certainly a change from an operational perspective, irrespective what you think the RFCs say.) -- to unsubscribe send a message to namedroppers-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 Jun 30 12:02:47 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5226A3A6AD9; Mon, 30 Jun 2008 12:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2mcNFIYpKiD; Mon, 30 Jun 2008 12:02:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD3A33A6AEF; Mon, 30 Jun 2008 12:02:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDOYc-0001Km-F0 for namedroppers-data@psg.com; Mon, 30 Jun 2008 18:56:58 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDOYX-0001Gv-Oc for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 18:56:55 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 72D9F1143A; Mon, 30 Jun 2008 18:56:53 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Federico Lucifredi cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: new draft of Forgery Resilience posted - summary of changes In-Reply-To: Your message of "Mon, 30 Jun 2008 14:45:01 -0400." <486929AD.5050905@ximian.com> References: <20080623175938.GA9771@outpost.ds9a.nl> <20080626144644.GD19608@outpost.ds9a.nl> <4868F721.1050809@ximian.com> <6454.1214840528@sa.vix.com> <4869224A.2070209@post.harvard.edu> <12518.1214850470@sa.vix.com> <486929AD.5050905@ximian.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 30 Jun 2008 18:56:53 +0000 Message-ID: <13536.1214852213@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Oops. I think I tried to condense my thinking too much. sort of. > But if we are keeping a _single_ counter, per each outstanding query we > expect a response for, indicating the number of discarded responses to this > query we have seen, the load is O(n) - one integer per query we have > outstanding. by forcing you to make queries to domains i control, and then by delaying the response to your queries, i can make you have as many outstanding queries as i want. if your quota is N then i'll get you to N+1 whenever it suits me. > I imagine a resolver needs to keep a few hundred bytes of state about each > query it is expecting responses for, adding 1 integer to each seems little > harm - and it would allow the responder to switch to TCP behavior once a > certain threshold is exceeded. if your "plan B" is expensive, then i will make you do it all the time. -- to unsubscribe send a message to namedroppers-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 Jun 30 12:13:07 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411E83A6AE5; Mon, 30 Jun 2008 12:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3G2PSiCq7uc; Mon, 30 Jun 2008 12:13:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C3ED3A6ADE; Mon, 30 Jun 2008 12:13:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDOjR-0003PI-E8 for namedroppers-data@psg.com; Mon, 30 Jun 2008 19:08:09 +0000 Received: from [69.17.117.8] (helo=mail6.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDOjG-0003Nq-Ef for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 19:08:04 +0000 Received: (qmail 32748 invoked from network); 30 Jun 2008 19:07:56 -0000 Received: from unknown (HELO [164.99.130.39]) (federico@[130.57.22.201]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 30 Jun 2008 19:07:56 -0000 Message-ID: <48692FAB.3060507@ximian.com> Date: Mon, 30 Jun 2008 15:10:35 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Paul Vixie CC: bert hubert , namedroppers@ops.ietf.org Subject: Re: new draft of Forgery Resilience posted - summary of changes References: <20080623175938.GA9771@outpost.ds9a.nl> <20080626144644.GD19608@outpost.ds9a.nl> <4868F721.1050809@ximian.com> <6454.1214840528@sa.vix.com> <4869224A.2070209@post.harvard.edu> <12518.1214850470@sa.vix.com> <486929AD.5050905@ximian.com> <13536.1214852213@sa.vix.com> In-Reply-To: <13536.1214852213@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Got it. Thanks Paul! -F Paul Vixie wrote: >> Oops. I think I tried to condense my thinking too much. > > sort of. > >> But if we are keeping a _single_ counter, per each outstanding query we >> expect a response for, indicating the number of discarded responses to this >> query we have seen, the load is O(n) - one integer per query we have >> outstanding. > > by forcing you to make queries to domains i control, and then by delaying the > response to your queries, i can make you have as many outstanding queries as i > want. if your quota is N then i'll get you to N+1 whenever it suits me. > >> I imagine a resolver needs to keep a few hundred bytes of state about each >> query it is expecting responses for, adding 1 integer to each seems little >> harm - and it would allow the responder to switch to TCP behavior once a >> certain threshold is exceeded. > > if your "plan B" is expensive, then i will make you do it all the time. -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - flucifredi@ximian.com -- to unsubscribe send a message to namedroppers-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 Jun 30 13:09:15 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45F53A6832; Mon, 30 Jun 2008 13:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.571 X-Spam-Level: X-Spam-Status: No, score=-101.571 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFhsr2bZLqo2; Mon, 30 Jun 2008 13:09:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 00F153A6812; Mon, 30 Jun 2008 13:09:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDPad-000BKy-7F for namedroppers-data@psg.com; Mon, 30 Jun 2008 20:03:07 +0000 Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDPaY-000BIl-NF for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 20:03:04 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1KDPaS-0003kP-5C; Mon, 30 Jun 2008 22:02:56 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1KDPaR-0001ex-IE; Mon, 30 Jun 2008 22:02:55 +0200 From: Florian Weimer To: Paul Vixie Cc: bert hubert , Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: Intended status References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> <6218.1214840092@sa.vix.com> <20080630155443.GB51849@commandprompt.com> <8896.1214844393@sa.vix.com> <20080630171101.GE31211@outpost.ds9a.nl> <12278.1214850153@sa.vix.com> Date: Mon, 30 Jun 2008 22:02:55 +0200 In-Reply-To: <12278.1214850153@sa.vix.com> (Paul Vixie's message of "Mon, 30 Jun 2008 18:22:33 +0000") Message-ID: <87fxquofm8.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > | If a resolver detects that an attempt is being made to spoof it, > | perhaps by discovering that many packets fail the criteria as > | outlined above, it MAY abandon the UDP query and re-issue it over > | TCP. TCP, by the nature of its use of sequence numbers, is far more > | resilient against forgery by third parties. > +--- Last sentence should read: | The sequence numbers used by TCP provide a straightforward way to add | a significant amount of additional randomness, provided that the TCP | stack used by the resolver uses properly unpredictable initial | sequence numbers. (Not sure if one party is enough, or both server and client need proper randomness.) Perhaps the draft should mention that good query IDs should be used over TCP, too. -- to unsubscribe send a message to namedroppers-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 Jun 30 13:13:53 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96ADE3A6A43; Mon, 30 Jun 2008 13:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADHbJjOgLa2C; Mon, 30 Jun 2008 13:13:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B9C573A6812; Mon, 30 Jun 2008 13:13:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDPav-000BOf-PI for namedroppers-data@psg.com; Mon, 30 Jun 2008 20:03:25 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDPar-000BNb-Bn for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 20:03:23 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C5E2111437; Mon, 30 Jun 2008 20:03:15 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Florian Weimer cc: bert hubert , Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: Intended status In-Reply-To: Your message of "Mon, 30 Jun 2008 20:52:03 +0200." <87od5ioiwc.fsf@mid.deneb.enyo.de> References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> <6218.1214840092@sa.vix.com> <20080630155443.GB51849@commandprompt.com> <8896.1214844393@sa.vix.com> <20080630171101.GE31211@outpost.ds9a.nl> <12278.1214850153@sa.vix.com> <87od5ioiwc.fsf@mid.deneb.enyo.de> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 30 Jun 2008 20:03:15 +0000 Message-ID: <15808.1214856195@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > For interoperability reasons, TCP fallback when a potential blind spoofing > situation is detected requires an update RFC 1123, but this is subject to > interpretation (as was discussed before). detecting these is questionable. all you know is that the did not match any of your outstanding upstream queries. if you can find a match for a shorter tuple, like: < cliaddr,cliport,qid,qname,qclass,qtype> then you might be able to guess that it was a spoof, but it could also be a stupid 4.2BSD-era (incl. SunOS or Ultrix) multihomed machine, or a NAT box that thinks its smarter than you, or a late response to a previous query, or a response to some other query you sent to the same server. i don't think there's a "detect spoofing" here. if you get a response that doesn't match a query you've got outstanding, then you just drop it and keep doing what you were doing (which means waiting for the next spoof attempt or perhaps for the real answer.) -- to unsubscribe send a message to namedroppers-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 Jun 30 13:51:06 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD55D3A68FC; Mon, 30 Jun 2008 13:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.797 X-Spam-Level: X-Spam-Status: No, score=-101.797 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPjhxLhKdJzs; Mon, 30 Jun 2008 13:51:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C787F3A67CE; Mon, 30 Jun 2008 13:51:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDQDl-000HsQ-15 for namedroppers-data@psg.com; Mon, 30 Jun 2008 20:43:33 +0000 Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDQDd-000Hql-0c for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 20:43:30 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1KDQDX-0005mh-PM; Mon, 30 Jun 2008 22:43:19 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1KDQDX-0001tl-Dj; Mon, 30 Jun 2008 22:43:19 +0200 From: Florian Weimer To: Paul Vixie Cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: Intended status References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> <6218.1214840092@sa.vix.com> Date: Mon, 30 Jun 2008 22:43:19 +0200 In-Reply-To: <6218.1214840092@sa.vix.com> (Paul Vixie's message of "Mon, 30 Jun 2008 15:34:52 +0000") Message-ID: <871w2eodqw.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Vixie: > if someone wants to randomize the IP destination (rather than using > RTT sorting or any other semi-deterministic selection criteria) Randomizing IP destination is difficult to implemented effectively because timing differences may reveal the destination actually chosen with high probability, while it is still possible to send a spoofed response. There's probably an optimum distribution of IP destinations, at least after fixing certain parameters of an attack scenario (bandwidth, network delays, and so on). In some cases it's a uniform distribution, in others, always using the smallest RTT seems preferable. -- to unsubscribe send a message to namedroppers-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 Jun 30 13:51:22 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B621F3A68FC; Mon, 30 Jun 2008 13:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.624 X-Spam-Level: X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGG2ct3RLLP4; Mon, 30 Jun 2008 13:51:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C86F93A68DA; Mon, 30 Jun 2008 13:51:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDQGe-000IQK-7Z for namedroppers-data@psg.com; Mon, 30 Jun 2008 20:46:32 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDQGW-000IOm-C5 for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 20:46:26 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KDQGU-0005Vy-Ed for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 22:46:22 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 92EC744FA; Mon, 30 Jun 2008 22:46:35 +0200 (CEST) Date: Mon, 30 Jun 2008 22:46:35 +0200 From: bert hubert To: Florian Weimer Cc: namedroppers@ops.ietf.org Subject: Re: Intended status Message-ID: <20080630204635.GJ31211@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> <6218.1214840092@sa.vix.com> <20080630155443.GB51849@commandprompt.com> <8896.1214844393@sa.vix.com> <20080630171101.GE31211@outpost.ds9a.nl> <12278.1214850153@sa.vix.com> <87fxquofm8.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fxquofm8.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 30, 2008 at 10:02:55PM +0200, Florian Weimer wrote: > | The sequence numbers used by TCP provide a straightforward way to add > | a significant amount of additional randomness, provided that the TCP > | stack used by the resolver uses properly unpredictable initial > | sequence numbers. > > (Not sure if one party is enough, or both server and client need proper > randomness.) I'm not sure either - I copped out by adding: "The sequence numbers used by TCP provide a straightforward way to add a significant amount of additional randomness, provided that the TCP stacks used employ properly unpredictable initial sequence numbers." Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source 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 Jun 30 19:42:15 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9523A69C0; Mon, 30 Jun 2008 19:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjNxAFLuEp4n; Mon, 30 Jun 2008 19:42:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E2533A6782; Mon, 30 Jun 2008 19:42:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDVhK-000Gpk-FL for namedroppers-data@psg.com; Tue, 01 Jul 2008 02:34:26 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDVhG-000GpF-6K for namedroppers@ops.ietf.org; Tue, 01 Jul 2008 02:34:24 +0000 Received: from Puki.ogud.com (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m612YFP2071414; Mon, 30 Jun 2008 22:34:16 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200807010234.m612YFP2071414@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 30 Jun 2008 22:31:59 -0400 To: Paul Vixie , bert hubert From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Re: Intended status (Was: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") Cc: namedroppers@ops.ietf.org In-Reply-To: <12278.1214850153@sa.vix.com> References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> <6218.1214840092@sa.vix.com> <20080630155443.GB51849@commandprompt.com> <8896.1214844393@sa.vix.com> <20080630171101.GE31211@outpost.ds9a.nl> <12278.1214850153@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 14:22 30/06/2008, Paul Vixie wrote: > > > can i first see the current text, since there have been a lot of > > > proposed edits here in the last few days since a draft was pub'd. > > > > I've put the up to the minute text version on > > http://ds9a.nl/tmp/draft-ietf-dnsext-forgery-resilience.txt > >+--- >| Updates: 1034 (if approved) >+--- > >strike this, unless you can cite chapter and verse of what's being changed. >(just because it's on the standards track doesn't mean it automatically >updates 1034, you have to say what changes you're making, which i don't see.) >merely amending the specification with new rules does not automatically >update 1034 or 1035. (some day there will be an RFC which is automatically >updated by any DNS protocol amendment, but right now there isn't one.) People arguing for BCP need to answer the following questions to the satisfaction of the chairs: Why should this document be treated differently from RFC2181? Why is RFC2119 language not needed to beat up bad implementors/operators ? In addition Paul needs to instruct us on: How to "cite chapter and verse" of an omission in an RFC? History: Before DJBDNS no implementation used more than one port for outgoing DNS questions, after that some implementation started using ports OTHER than 53 for outgoing questions. Early implementations of recursive resolvers only used one and frequently predictable port for outgoing queries. Unless the document is listed as one of the many ones that updates RFC103x implementors that do not follow what happens in the IETF will not pay attention to this document. Lets spend less hot air on the status of the document and more effort on improving it, this is an important document. 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 Mon Jun 30 19:42:27 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFBF83A6B54; Mon, 30 Jun 2008 19:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bc8sbjAFohZq; Mon, 30 Jun 2008 19:42:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B93A33A6782; Mon, 30 Jun 2008 19:42:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDVhz-000Gtq-PC for namedroppers-data@psg.com; Tue, 01 Jul 2008 02:35:07 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDVht-000GsN-Hl for namedroppers@ops.ietf.org; Tue, 01 Jul 2008 02:35:05 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id m612YvxM071420 for ; Mon, 30 Jun 2008 22:34:57 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id m612Yvbv071419 for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 22:34:57 -0400 (EDT) (envelope-from namedroppers) Received: from [69.17.117.7] (helo=mail5.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDNq1-000JGb-UQ for namedroppers@ops.ietf.org; Mon, 30 Jun 2008 18:10:56 +0000 Received: (qmail 9609 invoked from network); 30 Jun 2008 18:10:51 -0000 Received: from unknown (HELO [164.99.130.39]) (federico@[130.57.22.201]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 30 Jun 2008 18:10:51 -0000 Message-ID: <4869224A.2070209@post.harvard.edu> Date: Mon, 30 Jun 2008 14:13:30 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Paul Vixie CC: bert hubert , namedroppers@ops.ietf.org Subject: Re: new draft of Forgery Resilience posted - summary of changes References: <20080623175938.GA9771@outpost.ds9a.nl> <20080626144644.GD19608@outpost.ds9a.nl> <4868F721.1050809@ximian.com> <6454.1214840528@sa.vix.com> In-Reply-To: <6454.1214840528@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] Paul Vixie wrote: >> In 8, where it is noted that spoofing can be noticed by a watchful >> operator, I would think the resolver should watch as well. Maybe keeping >> track of all the IPs the resolver is getting messages from is too serious >> overhead, but noticing repeated discarded responses (thousands of them) to >> the same query, should only require a single integer... or am I missing >> something ? > > how many single integers would we keep, as a quota matter? if it's 10000 > then we can expect attackers to spoof us in a way that churns through all > 10000 buckets rapidly enough that no bucket ever gets old enough to count > the real attacks. (i don't know if this means you're missing something, > but this approach has already been considered and found unacceptable by > several of us here.) > One integer per outstanding query that we are expecting a response for ? >> It looks like 9 is going there where it says "if a resolver detects an >> attempt is being made to spoof it...", but then the dropping UPD for a TCP >> query is only under MAY. I can see reasons for this not being a MUST, but >> how about a SHOULD? Is there a reason to have that option so weakly worded? > > this document should make observations, propose some alternatives, and maybe > recommend things, but if at all possible, not extend the DNS protocol by > requiring certain specific actions when certain on-wire patterns are seen. > ok - that's fair. Although given the success we are having at deploying SEC, that maybe should be considered :/ >> At the risk of sounding like a DJB fan, has it been considered to give a >> requirement level to source port randomization (SHOULD) ? > > even those of us who are not DJB fans know that UDP source port randomization > is a good idea, and i for one wish that i had listened to DJB about this when > he first proposed it. :) Best -F -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - lucifred@fas.harvard.edu -- to unsubscribe send a message to namedroppers-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 Jun 30 19:45:47 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B873A6B5F; Mon, 30 Jun 2008 19:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+vCiaqCItoX; Mon, 30 Jun 2008 19:45:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E3463A69C0; Mon, 30 Jun 2008 19:45:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDVoI-000Hr6-OL for namedroppers-data@psg.com; Tue, 01 Jul 2008 02:41:38 +0000 Received: from [2001:4f8:3:bb::1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDVoE-000HqB-BW for namedroppers@ops.ietf.org; Tue, 01 Jul 2008 02:41:36 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E013811429; Tue, 1 Jul 2008 02:41:23 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: Intended status (Was: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") In-Reply-To: Your message of "Mon, 30 Jun 2008 22:31:59 -0400." <200807010234.m612YFP2071414@ogud.com> References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> <6218.1214840092@sa.vix.com> <20080630155443.GB51849@commandprompt.com> <8896.1214844393@sa.vix.com> <20080630171101.GE31211@outpost.ds9a.nl> <12278.1214850153@sa.vix.com> <200807010234.m612YFP2071414@ogud.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 01 Jul 2008 02:41:23 +0000 Message-ID: <29644.1214880083@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > In addition Paul needs to instruct us on: > How to "cite chapter and verse" of an omission in an RFC? good question. let's get george's document finished so we have something we can update when we want to tell implementors that the protocol is changed. > History: Before DJBDNS no implementation used more than one port for > outgoing DNS questions, after that some implementation started using > ports OTHER than 53 for outgoing questions. Early implementations of > recursive resolvers only used one and frequently predictable port for > outgoing queries. that's not, by itself, a protocol issue. complete interoperability does not depend on the use of multiple ports. from an ietf terminology point of view, the use of multiple ports is a recommended solution to a security problem which might also have other solutions. > > Unless the document is listed as one of the many ones that updates > RFC103x implementors that do not follow what happens in the IETF > will not pay attention to this document. > the hotel rooms and coffee houses and corporate firewalls who intercept my UDP/53 packets and send me back self-serving gibberish aren't following RFC 1034 and i'm betting that a proscriptive "must carry clear channel DNS" RFC which was on the standards track and which explicitly updated RFC 1034 would have no effect on the sales of the underlying devices. > Lets spend less hot air on the status of the document and more effort on > improving it, this is an important document. with the language i proposed as a mostly-replacement for section 9, this document could be on the standards track. and if you want to say that it updates RFC 1034 even though it doesn't really, then that's fine by 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 Mon Jun 30 20:49:37 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C8C3A6A42; Mon, 30 Jun 2008 20:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU1fRc0lYMmq; Mon, 30 Jun 2008 20:49:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5989F3A695B; Mon, 30 Jun 2008 20:49:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDWl1-0000ue-TK for namedroppers-data@psg.com; Tue, 01 Jul 2008 03:42:19 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDWki-0000ob-K1 for namedroppers@ops.ietf.org; Tue, 01 Jul 2008 03:42:09 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m613fhS5009103; Tue, 1 Jul 2008 13:41:44 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807010341.m613fhS5009103@drugs.dv.isc.org> To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Cc: Paul Vixie , bert hubert , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Intended status (Was: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") In-reply-to: Your message of "Mon, 30 Jun 2008 22:31:59 -0400." <200807010234.m612YFP2071414@ogud.com> Date: Tue, 01 Jul 2008 13:41:43 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > At 14:22 30/06/2008, Paul Vixie wrote: > > > > can i first see the current text, since there have been a lot of > > > > proposed edits here in the last few days since a draft was pub'd. > > > > > > I've put the up to the minute text version on > > > http://ds9a.nl/tmp/draft-ietf-dnsext-forgery-resilience.txt > > > >+--- > >| Updates: 1034 (if approved) > >+--- > > > >strike this, unless you can cite chapter and verse of what's being changed. > >(just because it's on the standards track doesn't mean it automatically > >updates 1034, you have to say what changes you're making, which i don't see. > ) > >merely amending the specification with new rules does not automatically > >update 1034 or 1035. (some day there will be an RFC which is automatically > >updated by any DNS protocol amendment, but right now there isn't one.) > > People arguing for BCP need to answer the following questions to the > satisfaction of the chairs: > Why should this document be treated differently from RFC2181? > Why is RFC2119 language not needed to beat up bad implementors/operators ? > > In addition Paul needs to instruct us on: > How to "cite chapter and verse" of an omission in an RFC? > > History: Before DJBDNS no implementation used more than one port for > outgoing DNS questions, after that some implementation started using > ports OTHER than 53 for outgoing questions. Early implementations of > recursive resolvers only used one and frequently predictable port for > outgoing queries. BIND 8. 8.1 (vixie 08-Jan-99): {"query-source", T_QUERY_SOURCE}, >From djbdns-1.05/CHANGES 19991129 version: dnscache 0.50, alpha. not released yet. 19991223 version: dnscache 0.60, alpha. > > Unless the document is listed as one of the many ones that updates > RFC103x implementors that do not follow what happens in the IETF > will not pay attention to this document. > > > Lets spend less hot air on the status of the document and more effort on > improving it, this is an important document. > > 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: -- 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 Jul 1 01:38:32 2008 Return-Path: X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1049D3A69CF; Tue, 1 Jul 2008 01:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6bQxN4OKQfY; Tue, 1 Jul 2008 01:38:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E12743A68C6; Tue, 1 Jul 2008 01:38:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDbGc-000JTj-GA for namedroppers-data@psg.com; Tue, 01 Jul 2008 08:31:14 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDbGQ-000JRA-JP for namedroppers@ops.ietf.org; Tue, 01 Jul 2008 08:31:11 +0000 Received: from mirre.nlnetlabs.nl (mirre.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:fe0b:89f4]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m618Ut1F067620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Jul 2008 10:30:56 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl) Message-ID: <4869EB3F.6070002@NLnetLabs.nl> Date: Tue, 01 Jul 2008 10:30:55 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.12 (X11/20080414) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Intended status (Was: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") References: <200806262033.m5QKXJxA036876@ogud.com> <20080630145430.GG35169@commandprompt.com> <6218.1214840092@sa.vix.com> <20080630155443.GB51849@commandprompt.com> <8896.1214844393@sa.vix.com> <20080630171101.GE31211@outpost.ds9a.nl> <12278.1214850153@sa.vix.com> <200807010234.m612YFP2071414@ogud.com> In-Reply-To: <200807010234.m612YFP2071414@ogud.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 01 Jul 2008 10:30:56 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > People arguing for BCP need to answer the following questions to the > satisfaction of the chairs: > Why should this document be treated differently from RFC2181? 2181 had actual interoperability changes. > Why is RFC2119 language not needed to beat up bad implementors/operators ? > Because it is not necessary for you to implement this to make it work with my software. "You don't HAVE TO implement it, you're just really really stupid if you don't." This document somehow reminds me more of BCP38 than RFC2181, but apparently i'm the only one :) > > > Unless the document is listed as one of the many ones that updates > RFC103x implementors that do not follow what happens in the IETF > will not pay attention to this document. > > Hmm. One would almost like to ask, why have BCP's in the first place? (hurray for generalization ;) ) If you are an implementor, and want to be a good boy, but are only using the 'updates' links to see what you should do you are going to be missing out on more than just forgery resilience. That mechanism shouldn't be used just to get attention to the doc. > Lets spend less hot air on the status of the document and more effort on > improving it, this is an important document. > We do agree there Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhp6z8ACgkQ4nZCKsdOncUz8wCeL+sS4tvFwrtHHYUC1YOajHws cjMAoMBhwJd7doFtcn4uS8uFJD4f69nM =P4Ns -----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: